Keep your place. Recover clearly.
How pending liquidity steps are tracked, how replacements are checked, and which records matter most.
What is stored, and where
| Location | Contents |
|---|---|
| Neon database | The private plan, bounded evidence, transaction lineage, receipts, and provisional, finalized, or orphaned states. |
| Initiating browser | A local pending journal and a random recovery capability. One full pending journal is kept per wallet. |
| Server capability record | Only the hash of the random recovery capability, not the capability itself. |
| Canonical chain 4663 | Public receipts, block hashes, NFT ownership, and position state. These take priority. |
A provisional state is still awaiting finality. A finalized state has met the required confirmation checks. An orphaned state records evidence that no longer belongs to the canonical chain, such as after a reorganization.
The local journal is a recovery copy; the Neon record is operational. Neither can override canonical chain receipts, block hashes, NFT ownership, or position state.
Your private recovery access
The random capability grants access to private recovery information. It cannot sign transactions or move assets, but you should not share it.
A finalized approval keeps its capability until a fresh mint plan or authenticated cleanup atomically replaces it. This preserves an allowance-cleanup path even after a tab closes or the release is paused.
Completed handoffs leave bounded local pointers. They expire after 30 days on the next use of the app. Recovery export and pointer-deletion controls are available.
If a transaction is still pending
- Once a hash exists, follow it. Track that transaction and any wallet replacement. Do not blindly resubmit the action.
- For a prepared liquidity action, the nonce barrier remains if the tab closes before its hash is saved. The server can verify a transaction hash copied from your wallet or an explorer.
- Wait for canonical evidence. A stale or missing local record does not establish that a transaction failed or that another submission is safe.
For swaps, the current session keeps an unresolved hash visible and offers Check transaction. Retain the hash before leaving the page and verify its receipt in your wallet or explorer before attempting another swap. API integrations must provide their own durable hash storage and duplicate-submission protection across tabs and refreshes.
How replacements are classified
| Classification | Meaning |
|---|---|
| Exact replacement | A replacement for the intended transaction. |
| Self-cancellation | A wallet-signed cancellation at the reserved nonce. |
| Unrelated transaction | Another transaction from the same wallet at that nonce. It is never labeled as an LP action. |
An unrelated transaction remains evidence for review. Allowance cleanup may proceed only after finality.
A zero-value self-cancellation is available only when both the wallet transport and the canonical RPC report that the exact reserved nonce is unused. Every cancellation still requires a wallet signature, costs gas, is receipt-verified, and is marked for review.
Public chain data and privacy
After broadcast, wallet addresses, calldata, approvals, NFT transfers, receipts, and logs are public. Private off-chain records have their own access, retention, and deletion rules.