Track LayerSwap Settlement

swidge() returns after the source deposit has been submitted. Keep the provider swap ID and source hash separately. A completed source transaction does not prove that the destination recipient has received the payout.

Persist the result

Store id, hash, transactions, source/destination network names, selected token identifiers, recipient and refund address with the application's transfer record. Persist the accepted input and limits so a later status view can explain the same operation.

Use id with getSwidgeStatus(). Use hash with getTransactionStatus() for the source-deposit assessment and read the returned object's status field, including TON's message tracing.

Read settlement once

export async function readLayerswapSettlement(protocol, record) {
  return protocol.getSwidgeStatus(record.id, {
    fromChain: record.sourceNetwork,
    toChain: record.destinationNetwork
  })
}

The chain hints constrain lookup rather than select a new route. They accept a provider network name or chain ID; an incorrect hint can produce NoSuchElementError even for an existing swap.

Interpret status and transactions

The mapper selects the first output transaction and gives it precedence when it is completed. Otherwise the first refund transaction determines refund status, and a non-completed first output yields pending before the swap-level status is consulted. A status fallback is not a guarantee that the operation is progressing.

Returned transactions contain entries with a hash and optional chain and type. The mapper uses source, destination, refund or other; transactions without hashes are omitted. Keep the full list rather than assuming one transaction for each stage or a fixed event sequence.

These are provider observations. An application that needs destination-chain verification must check the reported destination transaction and intended token/recipient separately.

Poll and handle failures

Choose a bounded polling interval and a stopping or escalation policy appropriate to your application. The SDK does not run a background settlement poller or retry loop.

• NoSuchElementError from transaction lookup can be indexing delay or incorrect identifiers. Verify the saved network and hash rather than treating every not-found result as a safe retry.
• ProviderError can indicate credentials, rate limiting, timeout, network failure or a malformed response. Preserve the transfer record while recovering access.
• An execution error can occur after a provider swap exists, before its ID is returned. A source broadcast can also succeed despite a transport error observed by the application.

If no swap ID was returned, getSwidgeStatus() cannot identify the swap. Preserve the original intent and any known source hash, reconcile the source wallet and chain, and seek LayerSwap assistance if you cannot identify the existing swap. The SDK has no hash-based swap recovery method.

Provider notification after broadcasting is best effort. Its failure does not undo the source send. Likewise, a failure to save local state after a successful call does not undo the returned submission.

Next Steps

Need Help?