Layerswap bridges and swaps assets across supported routes while transaction records show whether delivery finished

Layerswap supports network swaps, exchange connections, and application deposit flows

One request may move an asset between supported networks, connect a blockchain leg with a centralized exchange, or supply a deposit flow inside another application. In each case, live route data identifies the supported source, destination, assets, and amount limits, while the swap request records the delivery address. Availability belongs to that exact combination and can change with liquidity or service conditions.

Network-to-network swaps

A network-to-network route starts with the asset and chain holding the funds. It ends with a supported asset, network, and receiving address. The token symbol alone isn’t enough to establish a match because the same symbol may represent different contracts or formats across networks. Route data resolves that compatibility before any source transaction is sent.

Centralized exchange connections

Layerswap accepts transfer requests between blockchain networks and centralized exchanges when the requested connection is available. An exchange endpoint adds its own withdrawal or deposit rules to the route. Its selected network must match the Layerswap instructions, and any fee charged by the exchange remains separate from the bridge quote.

Deposit flows inside applications

An application can request available sources, obtain a quote, create a swap, and receive a deposit address for the selected route. Layerswap then watches for the payment and sends the output to the configured destination. This flow can accept a compatible manual transfer without requiring the sender to keep a browser-wallet session open.

What should be recorded before funds move?

Record the route and its identifiers before authorizing the source transfer. These details establish the intended state, reveal whether a later transaction matched it, and provide the minimum context needed to investigate a delay.

• The exact source network and source asset
• The destination network, asset, and receiving address
• The transfer amount and live route limits
• The quoted output, disclosed fees, and timing estimate
• The swap ID and assigned deposit instructions

The route and quote

A current quote shows whether the selected combination is offered and whether the amount falls within its limits. Limits, fees, and availability are live conditions, so changing the network, asset, amount, or destination calls for another quote. A quote estimates the outcome for a specific amount, so follow the funding amount and instructions returned for the created swap.

The destination and starting record

The destination address deserves a character-by-character check before commitment because the outgoing leg uses that value. Save the swap ID, deposit address, intended route, quote, and any displayed time limit as text or a durable export. A screenshot can help with context, though searchable identifiers are more useful during reconciliation. None of this requires recording a seed phrase or private key.

Before initiating the source transfer, you can leave a pending request without moving funds. Once a blockchain transaction has been submitted, leaving the request doesn’t reverse that source-chain transaction. That point separates a reversible request from a committed payment.

The transaction lifecycle from request to delivery

Status labels summarize which side is expected to act and which transaction evidence should exist. Reading them in sequence prevents a pending request from being mistaken for a completed transfer.

Waiting for the source payment

A newly created swap begins with the user_transfer_pending status. Layerswap is waiting for an incoming transaction that matches the assigned deposit instructions. If no deposit arrives within six hours, the swap expires. In that case, obtain current route data and create a fresh request rather than sending against the expired record.

Matching the input and initiating the output

After the deposit has enough confirmations, the swap changes to ls_transfer_pending while Layerswap processes it. The attached input transaction identifies the payment that funded the swap. The next material change is the creation of the destination-side transaction, which supplies separate evidence for the delivered result.

Completed, failed, expired, and refunded records

Completed means funds reached the destination address, while failed means the deposited amount fell below the route minimum. Other execution problems are retried. With a refund address, exhausted retries move the swap to pending_refund, and a confirmed refund changes it to refunded. Without a refund address, the swap remains ls_transfer_pending while retries continue. Expired and refunded records remain useful as history, but they aren’t instructions for a new payment. No terminal label should be stretched beyond its meaning: a failed status doesn’t prove that a refund occurred, and completed still merits a destination-chain check.

How can a completed transfer be verified?

Verify it by reconciling the original request, source transaction, and destination transaction. A swap record can attach input, output, and refuel transaction objects that contain transaction hashes and confirmation fields. Confirm the source payment on its network, then inspect the output on the destination network. The receiving address and asset should match the swap, and the delivered amount should be checked against the quote’s estimated and minimum receive amounts. For an exchange endpoint, retain its withdrawal or deposit reference as additional evidence.

View full-size image

---

A compatibility check before commitment

Every changing input in this worked example is hypothetical: the source network, source asset, transfer amount, destination network, destination asset, receiving address, live route availability, and quoted output. For this hypothetical case, the exact combination must be supported, and the final output must reach the selected address with matching transaction evidence.

View full-size image

First, live route data shows that the hypothetical source and asset can reach the hypothetical destination and asset. A fresh quote then confirms that the amount fits the available limits. Compatibility is a live condition, while the durable rule is that the source payment must follow the deposit instructions attached to the created swap. If the route disappears before payment, don’t send funds; request live route data again before creating another swap.

With the fit confirmed, the swap is created, its starting record is saved, and the hypothetical source transfer is submitted. The successful input is detected and matched, which changes the swap state and leads to the outgoing leg. The transfer is complete when the record contains an output hash, the destination transaction succeeds, and its address and asset match the saved terms. Check the delivered amount against the saved quote’s estimated and minimum receive amounts.

Resolving mismatches and closing the record

If an input transaction reaches the required confirmation count but the swap remains user_transfer_pending, investigate a matching problem instead of sending again. Compare the source network, asset, assigned deposit address, transaction hash, and swap ID. If the deposited amount is below the route minimum, the swap moves to failed, so include the actual input amount in the reconciliation record.

If the swap reports failed or the expected output is absent, preserve the swap ID and any attached transaction records before seeking support. Don’t infer a refund, retry, or destination delivery from the status name alone. Likewise, don’t send against an expired request; obtain current route data and create a fresh one.

Applications may poll the swap record or receive webhook status updates. A notification is useful for timing, while the retrieved record and destination transaction provide the evidence needed to close the transfer. Archive the record when the evidence matches; otherwise, escalate the unresolved mismatch with every identifier intact.