Before booking a cross-chain transfer, verify source finality, destination execution and the amount actually received. For a recurring payout, these are separate states: a source transaction can be confirmed while its message is still pending, and a delivered amount can differ from the amount your ledger expected.
1. Wait for the source state your route requires
First, establish what counts as final for the source chain and the route you selected. A transaction hash or block inclusion proves that a transaction appeared in a block; it does not always mean the bridge or swap executor will treat it as irreversible.
For example, Ethereum proof-of-stake finality typically takes around 13–15 minutes when the chain is healthy, because finality depends on validator votes across two epochs. Other chains and rollups use different rules: a sequencer’s confirmation, an L1 data posting, and an L1 challenge period are not interchangeable milestones. Use the route’s stated source-finality condition in your treasury policy, rather than one fixed confirmation count for every network.
For a $50,000 monthly USDC payout from Ethereum to a Solana wallet, record the source transaction hash, chain, token contract, amount and block. Check that the event belongs to the intended sender and route, then wait until the relevant finality condition is met. A delayed or reorganized source event should remain pending; do not submit a second transfer just because the destination has not updated yet.
2. Confirm delivery and reconcile the net amount
Second, book the transfer only after you can verify the destination-side result. A cross-chain system may lock or burn the source asset, prove or attest to that event, then mint or release an asset on the destination; a liquidity route may instead pay from destination-side inventory and settle its source leg separately. In both cases, source completion and destination execution are distinct.
For a messaging route, the source event is observed and verified under that route’s security configuration before a destination call can execute; Axelar and LayerZero are examples of systems with their own verification and execution models. A destination call can fail after the source transaction succeeds, leaving a message pending for retry or manual resolution. Treat a source transaction as “in flight” until the destination transaction or receipt confirms the expected recipient, token and amount.
quickswap lets your team move and swap assets across chains in one flow, so the treasury can start from the source asset and target the payout asset without treating the exchange as a separate manual leg. For accounting, compare the destination’s actual received amount with the quote’s minimum output, where applicable, and with the source debit; include network gas and any route-level deductions in the reconciliation record. A quoted output is not a settled balance.
Set an approval tolerance around the business obligation, not around a convenient interface default. If the payout requires exactly $50,000 of value, define a minimum acceptable output and a price source or valuation timestamp; if the route’s realized output falls below that threshold, hold the item for review instead of marking the payable complete. Slippage limits, deadlines and minimum-output checks constrain execution, but they do not remove market or execution risk.
3. Use an exception state for mismatches and delays
Third, keep unresolved transfers out of both the “paid” and “failed” buckets until you can identify their state. Match records by source transaction hash and destination transaction or message identifier, not by amount alone; repeated payouts can share the same amount, while token decimals and wrapped representations can make raw quantities look different.
If the source is final but there is no destination execution, check the route’s message status and destination transaction history before retrying. A retry may be appropriate for a failed destination call, but blindly resubmitting the original source transfer can create a duplicate payout if the first message later executes. Escalate when the route reports a terminal failure, the recipient or token differs, or the received amount breaches your tolerance.
For recurring transfers, retain the expected source debit, expected destination token, recipient, minimum output, source and destination hashes, finality timestamps, and reconciliation result. Your next step is to run one low-value transfer through this control record, then use the same states and thresholds for the scheduled payout batch.
Should a treasury wait for full finality every time?
Use the source-finality standard required by the specific route and the value at risk. A smaller operational transfer may use a route’s defined faster acceptance condition if your policy permits it; a high-value payout should generally wait for the stronger finality condition. Record which condition was used so later reconciliation does not mistake speed for certainty.
What if the source is confirmed but the destination is still pending?
Keep the transfer in an in-flight state and identify its message or route status using the recorded transaction identifiers. Check whether destination execution is pending, reverted or awaiting a retry. Do not resend the source transfer until you know whether the original can still execute, since that can produce duplicate settlement.
How should we handle a destination amount below the quote?
Compare the actual receipt with the minimum output or tolerance fixed before execution, and value it using the treasury’s agreed price source and timestamp. If it falls short of the payout obligation, leave the payable open and investigate the route deductions or market movement. Record any top-up as a separate, linked transfer.
Top comments (0)