Link3 Swap States Determine What You Can Do Next
Link3 embeds token swaps in Web3 profiles. On Ethereum-style routes, a quote, wallet request, submission and onchain confirmation are separate states. Each state supports a different next action. A displayed quote does not authorize spending, an open prompt does not prove submission and a transaction hash does not prove success. Continue only after the wallet or chain record shows the condition required by the next step, then compare the completed transaction with the resulting balance.
Table of contents
Bottom line: A quote frames the request, a wallet authorizes it and an onchain receipt shows whether the swap actually executed.
Profile actions before an onchain change
Before execution, an embedded swap has several jobs: present proposed terms, request any necessary permission and prepare a state-changing transaction. The interface may group these steps in one profile block, but each produces different evidence. Leaving the flow at each point also has a different consequence.
Proposed terms
The interface can show the selected input and output assets, the amount entered and an estimated return. These values describe a proposed trade at that moment. They do not reserve liquidity or guarantee that the wallet will receive identical terms later. If the quote refreshes before confirmation, compare the new values with the intended exchange instead of relying on the earlier screen.
Wallet access and token permission
Connecting a wallet establishes a session with a selected public address. It does not by itself transfer tokens or execute a contract call. A route involving a token may also require permission for a contract to spend that token. The permission can be an onchain approval or a signature-based authorization, depending on the route and wallet. Neither step proves that the swap itself was submitted.
Network execution
The swap becomes a network action only after the wallet authorizes the state-changing request and the transaction is broadcast. A returned hash identifies that submission. Inclusion in a block supplies a receipt, while its status records whether execution succeeded or failed. The resulting token balance still needs to match the intended outcome before another action depends on it.
Evidence required before commitment
The wallet prompt lets you review a state-changing request before you authorize it. Read it as a transaction proposal rather than as a continuation of the profile screen.
Account and network context
An Ethereum transaction is a cryptographically signed instruction that can update network state. Before approval, match the sending account and network to those intended for the quote. A wallet may decode the token movement or contract method, but undecoded data reduces what can be verified from the prompt. If the target or action cannot be reconciled with the proposed swap, reject the request and exit.
Amounts, fees and permissions
The review should separate the swap amount from the network fee and any spending limit. A fee estimate is not the amount received, and an allowance does not prove that tokens were exchanged. Where a permission request appears first, confirm its asset, spender and scope. Then expect a separate swap state unless the wallet clearly presents a batched action.
Rejecting the swap prompt prevents that request from being signed or submitted. It does not erase an approval granted during an earlier step. The proposed swap stops, but a separate permission may remain until it expires, is consumed or is revoked under its own rules.
State evidence from quote to reconciliation
The table compares the minimum evidence available at each checkpoint. The normal path advances only after the listed proof appears. An edge case remains at the same checkpoint until the evidence is recovered or the request is abandoned.
| Checkpoint | Evidence available | Next valid action |
|---|---|---|
| Quote shown | Proposed inputs and an estimated output are visible. | Review the latest terms; no network change exists. |
| Wallet connected | The profile can read the selected public address. | Match the account and network to the intended action. |
| Permission requested | The wallet presents a request to grant a contract token-spending authority when required. | Inspect the asset, spender and limit; reject any mismatch. |
| Swap awaiting confirmation | The wallet presents the state-changing call before broadcast. | Compare the request with the intended swap, then confirm or exit. |
| Transaction hash returned | The submitted transaction has a unique identifier. | Preserve the hash and check whether the network includes it. |
| Transaction pending | The transaction is known, but no receipt is available yet. | Investigate its status before attempting another submission. |
| Receipt reconciled | A receipt reports execution status and balances show the consequence. | Proceed only when the status and observed balance agree. |
On the normal path, the wallet details, transaction hash, receipt and balance describe one consistent action. Each item answers a different question. The quote explains the proposal, the signature records authorization, the hash tracks submission, the receipt reports execution and the balance shows the observed outcome.
Stop and investigate when the records diverge. A rejected or unsigned request was not authorized. A hash without a receipt remains unresolved. A failed receipt ends the original attempt without the intended swap, while a successful receipt with a stale display calls for a fresh balance query rather than an immediate second transaction.
Pending, completed and reconciled outcomes
Submission changes the proof that matters. Before submission, the wallet request is primary. After submission, the chain record carries more weight than the profile progress indicator. To confirm completion, check both execution status and the observed account state.
Pending without a receipt
For Ethereum-style transactions, a pending item has no receipt, while an included receipt records whether execution succeeded or failed. A spinning interface or transaction hash therefore cannot stand in for receipt status.
Delay alone does not identify the cause. Before retrying, check the original hash and wallet history. If the wallet reports that another transaction replaced or cancelled the request, follow the replacement record rather than the superseded identifier. Until one record reaches a clear outcome, another submission adds uncertainty.
Completed execution and balance reconciliation
A failed receipt means the call did not perform its intended state change, although the network fee may still have been spent. A successful receipt confirms execution, yet a wallet interface may still show cached balance data. The two states answer different questions and should not be treated as interchangeable.
Reconciliation compares the selected account, network, output token and balance after a successful receipt. Refresh balance data and inspect the transaction record before taking another action if the display differs. A receiving application may also wait for additional confirmations before crediting funds, so its confirmation rule governs any dependent step.
Permissions after the swap ends
Token permission can remain active after the visible swap flow ends. Where the embedded route requests a separate approval, exiting before the swap or receiving a failed swap receipt does not automatically revoke the earlier allowance. Inspect that allowance as its own state. Its scope is determined by the asset, spender, amount and any expiry that the authorization carries. An unwanted permission must be reduced or revoked through a supported wallet or contract interface.
Evidence that supports the next action
A next action is justified by the narrowest evidence that proves its prerequisite. Use the quote for review, the wallet for authorization state, the hash for tracking, the receipt for execution and balances for reconciliation. If any link is missing, stop at that boundary. Continue only after a successful receipt agrees with the updated balance. A profile-level success label alone does not prove either result.
Link3: the short answers
Does rejecting a Link3 swap prompt spend network fees?
Rejecting a wallet request before it is signed and broadcast does not create an onchain transaction, so that rejected request does not consume a network fee. A separate approval may already have been submitted and can have its own fee. Check the wallet history for a hash tied to the approval or swap before deciding that nothing reached the network.
How can I distinguish a Link3 token approval from the swap itself?
A token approval changes spending permission; it does not exchange the input token for the output token. Inspect the transaction record for the called action and receipt, then compare balances. If only an approval completed, the allowance may exist while the expected output balance remains unchanged. If the approval was separate, the swap still needs its own request. If the wallet presented a batch, verify the batch receipt and resulting balances.
Is every Link3 wallet signature an onchain transaction?
No. A wallet can sign an offchain message, including a permit, without broadcasting a transaction. A state-changing swap submission produces a transaction hash after broadcast. Read the prompt type and look for that hash. The absence of a network fee does not make a signature harmless because a signed permission can still authorize later token spending within its stated scope.
Can I resubmit a Link3 swap while the first transaction is pending?
Do not resubmit solely because Link3 still shows a pending state. Check the original hash for a receipt or replacement and review the wallet history first. A second request may become a separate transaction or replace an earlier one, depending on its nonce and wallet behavior. Retry only after identifying which request, if any, can still be included.
Can I close the Link3 page after a transaction hash appears?
Closing the page after a transaction was broadcast does not cancel the network request. Keep the transaction hash and use the wallet or chain record to check inclusion and receipt status when you return. If the request never produced a hash, do not assume it was submitted; reopen the flow and confirm its current state before preparing another swap.