Credit a cross-chain payout only after the destination asset is final and reconciled. A source-chain transaction can succeed while the bridge or swap is still processing, so a sent amount is not yet a received payment.
What counts as a completed cross-chain payout?
A payout is complete when the intended asset has arrived at the correct destination address in the required amount, and the destination chain reports it as finalized. Treat the route as a sequence of separate events: the source transaction settles, the cross-chain service processes the transfer or swap, and a destination transaction delivers the output.
That sequence matters when treasury sends ETH for a recipient who needs SOL. how quickswap routes Ethereum to Solana explains the routing context; operationally, the payout still needs destination-side verification before the recipient is credited. quickswap moves and swaps crypto across chains in one flow, which can help when the sender and recipient need different networks or assets.
For a business ledger, record the recipient address, destination network, expected token, approved minimum output, and a unique payout ID before sending. Keep the source and destination transaction references together under that ID. A source transaction hash proves what was submitted; by itself, it does not prove that the recipient received the output.
How long should the team wait?
Wait for the destination transaction to reach the finality level your policy requires, then confirm its token and amount. On Solana, “processed” can still be rolled back; “confirmed” means a supermajority of stake has voted, while “finalized” is the strongest confirmation state. Ethereum uses 12-second slots and 32-slot epochs; finality depends on validator votes, so a fixed number of blocks is not a universal substitute for checking finality.
Set a threshold by chain and transaction value, rather than using one timer for every route. For routine, low-value payouts, a team may accept a destination status such as confirmed if its risk policy allows it; for payroll, supplier payments, or larger transfers, I would wait for finalized status. If the route service reports completion before the destination transaction is final, treat that as a progress update, not the ledger’s settlement event.
For example, say a treasury expects at least $4,900 of destination value from a $5,000 equivalent transfer. If the final transaction delivers $4,918 to the specified address and meets the policy’s finality threshold, reconcile that received amount and close the payout. If it delivers $4,880, do not mark the invoice fully paid just because the route completed; flag the shortfall for review under the team’s tolerance rules.
What should reconciliation check?
Match the destination transaction to the payout record using the address, token, amount, and route reference. Verify that the transaction succeeded, reached the agreed finality level, and credited the intended account; an explorer display or provider status can help locate evidence, but the on-chain destination result is what supports the credit.
Keep a small exception path for delayed or mismatched transfers. If no destination transaction appears within the team’s route-specific service window, leave the payout pending and investigate using the saved references; do not resend automatically, since the original route may still complete. If the destination arrives below the minimum, at the wrong address, or in an unexpected token, hold reconciliation and resolve the variance before posting it as paid.
The answer changes when the recipient explicitly accepts a lower confirmation level or the amount is small enough for the business to absorb a reversal or variance. Otherwise, use destination finality and the agreed net amount as the crediting rule.