Layerswap
Layerswap cancellation can end an unfunded request but cannot reverse a submitted source transfer
Layerswap cancellation applies to an unfunded swap request, not to a source-network transaction. While the record is user_transfer_pending and no transfer has been submitted, you can stop, use Cancel when the active interface provides it, or leave the request unfunded until it expires. Once a wallet or exchange submits the source funds, closing the page or cancelling a stale request won’t reverse that separate action. The reliable next step is to follow the swap status and its transaction entries through processing, completion, failure, or refund. This checklist ties each choice to observable evidence so you can back out without sending funds into a retired request.
Last updated ·
The swap path from setup to recovery
A normal swap moves from reviewing the live route and destination to executing the supplied deposit actions. Before that step, you can leave the request unfunded or cancel it where supported. No on-chain reversal is needed because the source funds haven’t moved.
Before the source submission
Keep the swap ID, confirm that the record remains user_transfer_pending, and inspect the source account for any submitted transfer. A displayed quote or deposit address isn’t proof that funds moved.
In the current v2 lifecycle, an unfunded user_transfer_pending request changes to expired after six hours.
An available Cancel control can retire the request sooner, but its presence depends on the interface or integration.
After the source submission
A transaction hash, an accepted withdrawal record, or an input transaction attached to the swap changes the response. Stop treating cancellation as the exit. The source action may still be pending, yet it has crossed the boundary that the swap’s Cancel control governs. Preserve the transaction evidence and watch for matching rather than opening overlapping attempts.
When execution cannot finish
Recovery after funding belongs to the execution and refund path. Layerswap may retry when a route, liquidity source, price tolerance, blockchain connection, or provider prevents delivery. If the swap was created with a valid refund address and retries are exhausted, its state can move to pending_refund. That process is separate from cancelling an unfunded request.
Cancellation ends an unfunded request, while refund handling responds to funds that were already submitted.
When can you leave a Layerswap request without sending funds?
You can leave a request without sending funds only when both the swap record and the source side remain uncommitted. The strongest pass condition combines user_transfer_pending with no source transaction hash, no accepted withdrawal, and no input transaction in the swap record. A status label alone isn’t enough because matching can lag behind submission.
Check the source account as well as the swap. An exchange may accept a withdrawal before displaying an on-chain hash, and a wallet can broadcast immediately after confirmation. Either event defeats the assumption that nothing was sent, even if the browser still shows an earlier screen.
The source transaction sets the commitment boundary
The decisive change occurs at the source, not when a quote appears or a page opens. Three observable states help separate preparation from execution.
Prepared but not submitted
The route, amount, destination, and deposit instructions may exist while the assets remain under the sender’s control. No transaction hash or accepted withdrawal is present. Cancelling, abandoning, or allowing this request to expire doesn’t require funds to be returned because none entered the swap.
Submitted but not yet matched
The source system has accepted the transfer, but Layerswap may still be waiting for enough confirmations or for the transaction to match the request. The transaction hash or withdrawal record is the better evidence here. Starting another attempt can create two live transfers rather than replace the first.
Matched and processing
An input transaction in the swap details connects the source payment to the request. The swap can then show ls_transfer_pending while execution continues. At this stage, wait for a destination transaction, a failure reason, or refund evidence. A local Cancel control can’t erase the recorded input.
A pass or fail checklist before backing out
Use the same evidence on both sides of the decision. A pass means the request can be left without committing funds; a fail means the record needs tracking or recovery instead.
-
Swap status: a provisional pass on
user_transfer_pending; cancellation or expiry also passes only when the source and transaction checks show no deposit; fail on processing, failed, completed, or refund-related states. - Source account: pass when no transfer was submitted or a source exchange confirms cancellation before broadcast; fail while an accepted withdrawal remains active or a submitted transaction hash exists.
- Swap transactions: pass when there is no input entry; fail when the source payment appears in the transaction list.
- Exit record: pass when cancellation or expiry is recorded with no deposit; fail when only the page or wallet window was closed.
- Next attempt: pass with a fresh quote and new request; fail if old deposit instructions are reused after cancellation or expiry.
Conflicting evidence should be treated as a fail. For example, user_transfer_pending beside a new source transaction hash calls for tracking, not another cancellation attempt. The hash records the submitted source transaction more directly than a screen that hasn’t refreshed.
What evidence survives after cancellation?
The swap ID and historical state can remain after explicit cancellation in an interface that records a cancelled state, while an untouched v2 request may later appear as expired. Neither label moves assets. Look for that final request state, an empty input-transaction record, and source-account history showing no submitted payment. Keep the swap ID even when nothing moved because it distinguishes the retired request from any later attempt.
Status records track the swap lifecycle
user_transfer_pending means Layerswap is waiting for the source deposit. expired means that waiting window ended without a matched deposit. Expiry isn’t permission to send using the old instructions, and it doesn’t settle a source transfer that may have been submitted near the boundary.
ls_transfer_pending means the deposit was matched and the swap is being processed. completed means funds were delivered to the destination address. For stronger completion evidence, pair the swap-level status with the output transaction rather than relying on a browser message alone.
A failure reason describes an execution problem, while pending_refund shows that a refund is in progress.
The refunded status means the refund transaction has been confirmed on the source network.
Transaction entries can separately identify the input, output, refuel, and refund operations, so their states shouldn’t be confused with the overall swap state.
Can closing the page cancel a sent transfer?
No. Closing a tab, disconnecting a wallet, or losing the visible progress screen doesn’t cancel a submitted source transaction. Recover the swap with its ID or, after submission, look it up using the source transaction hash when that facility is available. A source exchange may have its own withdrawal-cancellation window before broadcast, but that control belongs to the exchange and isn’t created by Layerswap.
Refunds after funding are separate from cancellation
Once a funded swap can’t complete, cancellation no longer governs the outcome. Any refund depends on the refund address and refundable amount recorded for that attempt.
With a refund address
The refund address must be valid on the source network. Routes that involve a swap provider require it. Layerswap retries execution before initiating a refund; after those retries are exhausted, the swap can move from pending_refund to refunded. The refund transaction then supplies the on-chain evidence.
Without a refund address
When no refund address is available, an execution problem can leave the swap in ls_transfer_pending while retries continue. That pending state isn’t a completed cancellation and doesn’t prove that funds were lost or returned. Retain the input hash, swap ID, destination, and displayed failure details for reconciliation.
Refund amount and source-chain costs
A refund is sent on the source network in the source token, with the refund transaction’s gas fee deducted. If the refundable amount is lower than that gas fee, no refund is issued. Check the refund address before sending, but don’t treat cancellation as a post-deposit remedy.
Keep records until swap and transaction evidence agree
Consider the request resolved only when its status and the relevant transaction records tell the same story. An unfunded cancellation or expiry should have no source payment. A completed swap should have destination evidence, while a refunded swap should include a confirmed refund transaction on the source network.
If those records disagree, preserve the swap ID and source transaction hash rather than replacing the attempt. Waiting on a traceable committed swap is different from creating a fresh request after a clearly unfunded cancellation, and only the latter is a clean restart.
Details worth knowing about Layerswap
Does an expired unfunded request move any assets?
No. Expiry changes the state of a request that was waiting for a source deposit; it doesn’t create a source transaction. Confirm that no transaction hash, accepted withdrawal, or input transaction exists. If funds were submitted near the expiry boundary, track that transfer instead of assuming the expired label settles it.
Can I reuse deposit instructions from a cancelled or expired request?
Don’t reuse deposit instructions from a retired request. Create a fresh swap and follow the deposit actions tied to its current quote, route, and identifier. Sending to old instructions can leave the payment outside the state that the new request tracks, even when the source asset and destination appear unchanged.
Do I need a refund address before committing funds?
A valid source-network refund address is required when the route involves a swap provider, and it enables a refund after execution retries are exhausted. Without one, other execution failures can remain in ls_transfer_pending while retries continue. Record the address before sending because cancellation can’t add a post-deposit exit to the source transaction.
When can a refund be smaller than the original deposit?
A refund can be smaller because the source-network gas fee for the refund transaction is deducted from the returned amount. It is sent in the source token on the source network. If the refund amount is below the required gas fee, no refund is issued, so failed alone shouldn’t be read as proof of repayment.
Does signing in a wallet prove the transaction was broadcast?
A signature alone doesn’t always prove broadcast, because signing and network submission can be separate actions. Look for the wallet’s submitted state and a source-network transaction hash. Some wallet flows broadcast immediately after confirmation, so the absence of an extra send screen isn’t evidence that the request remains reversible.
Can a source exchange withdrawal remain cancellable after the swap request exists?
It may remain cancellable only under the source exchange’s own withdrawal rules and before that exchange commits or broadcasts it. Cancelling the Layerswap request doesn’t cancel an exchange withdrawal. Treat an accepted or processing withdrawal as committed until the exchange explicitly confirms cancellation, even if an on-chain hash hasn’t appeared yet.