A payout is complete when the intended recipient has the intended asset on the destination chain. For treasury, that is a different checkpoint from source-chain confirmation, a relayer fill, or a bridge protocol’s later reimbursement. Track those states separately so accounting can distinguish funds delivered from infrastructure fully settled.
Which event proves the recipient was paid?
Use the destination-chain transaction and token transfer as the payment evidence. A successful transaction receipt alone is insufficient: verify the expected recipient, token contract, and received amount in the logs or balance delta, then match them to the payout instruction.
Consider a treasury sending an illustrative 25,000 USDC from Ethereum to a supplier on Base through an aggregated route that uses Across. The origin transaction escrows the input; a relayer may front USDC on Base and emit a fill event. The supplier can be paid before the relayer receives its later reimbursement. Across documentation describes these as initiation, fill, and settlement phases; they are distinct accounting states.
Store a transfer record keyed by origin chain ID and transaction hash, with the destination chain ID, recipient, input token and amount, expected output token and minimum amount, and route or protocol identifier. Link the destination transaction hash and observed transfer log when available. If the route swaps assets, reconcile against the actual output token and amount, not the source amount as though the transfer were one-to-one.
How should a team set its release and reconciliation gates?
Set policy by chain and payout value. A sequencer’s quick inclusion is useful for operations, but it is not the same as a rollup block derived from finalized Layer 1 data: Base’s protocol documentation distinguishes unsafe, safe, and finalized blocks. Ethereum proof-of-stake finality typically takes about two epochs, roughly 13 minutes, while an optimistic bridge’s reimbursement can take hours. Choose the gate that matches your loss tolerance; don’t treat any one timer as universal.
- Record the instruction. Save approved destination, recipient, token, amount, and a minimum acceptable output before signing.
- Confirm the origin deposit. Require a successful receipt and the expected deposit event; a submitted hash or wallet balance decrease alone does not prove the bridge contract accepted the transfer.
- Track destination delivery. Wait for a successful destination receipt, then verify the fill or transfer log against recipient, token, and amount. Keep the item pending if the route is still relaying or reports a slow fill.
- Apply the chain’s finality policy. Mark delivery provisional until the destination block reaches the confirmation state your policy requires. For high-value payments, use the chain’s finalized state where available; record the block number and hash.
- Reconcile protocol settlement separately. Match the fill to the origin deposit and retain reimbursement status for operational monitoring. Do not hold a supplier payment open solely because a relayer’s later refund bundle has not settled.
For an aggregator-selected route, preserve the route and protocol identifiers with each transfer; a bungee bridge can help find routes for moving or swapping assets across chains, but your ledger should reconcile the on-chain events. The key question before acting is: which state—delivery, chain finality, or relayer reimbursement—does this payout policy require?
What edge cases change the decision?
A source transaction can succeed while the destination transfer remains pending, expires, or needs a protocol-specific recovery path. A reorg can also remove a transaction that appeared included, which is why high-value reconciliation should use block identity and a finality policy rather than a fixed short delay. The Ethereum documentation describes finality as a consensus property, not a synonym for inclusion.
Should we wait for relayer reimbursement?
Usually not to recognize the recipient’s payment. Reimbursement settles the relayer’s position with the protocol; it does not normally represent a second transfer to your supplier. Track it in bridge operations, and investigate if it remains outstanding beyond your route’s expected settlement window or the protocol reports an exception.
What if the route swaps tokens?
Define the destination asset and minimum acceptable output in the payment instruction. Reconcile the received amount in that asset, accounting separately for any swap price impact or protocol fee reflected in the output. If the actual transfer falls below the approved minimum, flag it for review instead of silently booking the source amount as paid.
What if the destination transaction is delayed?
Keep the payout pending and monitor the route’s protocol state. A confirmed origin deposit does not prove destination delivery; depending on the bridge design, funds may be escrowed while a relayer fills, or remain eligible for recovery after a deadline. Follow the protocol’s documented recovery conditions and avoid submitting a duplicate transfer while the first intent may still fill.
Can one confirmation threshold cover every chain?
No. Sequencer inclusion, safe status, and finalized status mean different things on rollups, and finality behavior varies across chains and bridge designs. Set thresholds by route, asset value, and payout urgency; document the chosen state in policy, then have monitoring report the underlying chain status rather than a generic “complete” label.