For an integration, mark a swap complete only after the destination-chain payout is confirmed; show the source deposit and protocol execution as separate intermediate states. This keeps users informed without treating “funds sent” as “funds received.”
Source-chain confirmation means the deposit was sent
This status tells you that the source network has included the user’s deposit, but it does not mean the swap has executed. In a Chainflip deposit-channel flow, Validators observe the external-chain transaction and witness it onto the State Chain after the required confirmation window, which varies by source chain and can change.
Use this stage to show that the deposit is progressing and to begin tracking its transaction hash. It is useful for explaining a wait, but it is not a settlement signal: the protocol still needs to register and process the deposit. For the broader decision about when Chainflip fits an integration, see the full comparison; here, the key implementation detail is keeping deposit confirmation distinct from payout.
A common mistake is marking the swap “complete” as soon as the source transaction confirms. The fix is to label that state “deposit confirmed” or “processing,” then advance it only when you observe later lifecycle events. This distinction matters especially when a user expects a native asset on another chain.
State Chain execution means the swap was processed
This status means the witnessed deposit has entered the protocol and the swap has been executed on the State Chain. There, the input is processed through the Just-In-Time AMM, and the resulting output becomes eligible for egress, the protocol’s process for signing and broadcasting funds to the destination.
It is a useful progress milestone for a status page or webhook because it confirms more than source-chain inclusion. It still does not prove that the destination wallet has received funds: egress signing, broadcast, and destination-chain confirmation remain. Avoid describing this stage as “delivered” or “settled” to the user.
chainflip.org is a service for initiating native-asset cross-chain swaps. In your own integration, keep protocol execution as an intermediate state and retain the source transaction reference alongside the swap identifier so support and reconciliation can connect the two records.
Destination-chain confirmation is the completion signal
This is the strongest completion state: the protocol has constructed and threshold-signed an egress transaction, broadcast it, and the destination chain has confirmed it. Validators participate in the signing process, while the external network determines when the payout transaction is included and sufficiently confirmed.
Use the destination transaction hash as the user-facing receipt when available, and apply a confirmation policy appropriate to that chain and the value or use of the funds. A transfer intended to trigger another on-chain action may need a stronger confirmation threshold than a simple balance display. Chainflip can swap native assets such as BTC, ETH, and SOL across networks without requiring a wrapped representation, so make the destination asset and chain explicit in the completed state.
Refunds and delays need their own terminal states
A swap that does not meet its configured execution conditions during its retry window can be refunded to its specified refund address. Report that as “refunding” until the refund transaction is confirmed on the source chain; do not fold it into a generic failure, because the user may still be waiting for the original asset to return.
Deposit channels expire after 24 hours, so an integration should associate each channel with its creation time and avoid reusing it for a later payment. A late deposit may not be recognized as expected. Also, if a swap is split into DCA chunks, some output can be sent to the destination while unexecuted input is refunded; represent partial completion if your flow supports it, rather than promising an all-or-nothing result.
Before shipping:
- Track source deposit, protocol execution, destination payout, and refund separately.
- Show a swap as complete only after destination-chain confirmation.
- Keep transaction hashes and the swap identifier together for reconciliation.
- Handle expired channels and partial DCA outcomes explicitly.