Swap tracking follows a trade from deposit to payout

Swap tracking shows a cross-chain trade moving through three main stages: deposit confirmation, execution and payout. The tracker links the source transaction to the swap record and, eventually, the destination transaction, so a user can see where progress has paused.

What does a swap tracker show?

A tracker turns separate blockchain events into one timeline. Chainflip’s documentation describes the flow as Ingress, processing on its State Chain, then Egress; its explorer records swap activity as validators witness deposits and the protocol sends output to the destination address.

Look for the source and destination assets, amounts, status, timestamps and transaction IDs. A deposit address or swap ID can help locate the record; the destination transaction hash lets you check delivery on the destination chain’s explorer. For a comparison of the swap modes, read when Chainflip Standard, Boost or DCA fits; the choice affects how a trade proceeds, but the tracking stages still describe its progress.

What happens after a deposit is sent?

First, the source-chain transaction must reach the protocol’s confirmation threshold. Chainflip’s documentation says validators watch supported-chain deposits, wait through a chain-specific safety margin, then submit witness records to the State Chain. That wait is part of the process: chains differ in block time and finality, so a tracker can show no progress even while the source transaction is still confirming.

Once the deposit is registered, the tracker moves to execution. The State Chain processes the trade against available liquidity; a route through multiple pools may involve sequential swaps. A DCA order can remain in this stage while its chunks execute, so elapsed time alone does not show that something has failed.

What does payout pending mean?

After execution, the output enters Egress: validators prepare and sign a transaction for the destination chain. Chainflip’s documentation says the network coordinates signing, then a validator broadcasts the transaction. Until a destination transaction hash appears, the output may still be awaiting that work.

Once broadcast, the destination chain must include the transaction in a block before the wallet reflects the funds. A tracker may mark the broadcast complete before the destination chain has finished confirming it. Check the destination hash in that chain’s explorer to distinguish a sent transaction from one that has settled.

How can you use the stages to find a delay?

Match the status to the transaction that should exist at that point, then inspect that transaction on its own chain. The stages narrow the search:

• No deposit detected: Check whether the source transaction was broadcast and whether it used the requested deposit address.
• Deposit waiting: Check source-chain confirmations; the protocol cannot process an unfinalized deposit.
• Execution in progress: Check whether the trade uses DCA or a multi-pool route, which may take more than one processing step.
• Payout pending or sent: Look for a destination transaction hash, then check its status on the destination chain.

The useful takeaway is to treat tracking as a map of stages, not a single countdown. Find the last confirmed event, verify its transaction on the relevant chain, and use the next missing event to identify where the wait sits.