How to Reconcile Cross-Chain Treasury Transfers

Reconcile a cross-chain treasury transfer by matching the debit on the sending chain with the credit on the receiving chain, then accounting for fees and any unresolved status. The transfer crosses two separate ledgers. A bridge or messaging system carries the instruction between them, but it does not make the two chains share one transaction record.

Start with the treasury’s instruction: asset, amount, source chain, destination chain and recipient address. The source-chain transaction may lock tokens in a contract or burn them. A bridge validator or other verification process confirms that event. The destination side then releases or mints the corresponding asset. Each step creates its own transaction hash, and the bridge may assign a message or transfer identifier that connects them.

In a lock-and-mint route, the original tokens are held on one chain while a representation is minted on another. The fermi swap lock-and-mint route explainer walks through that sequence in more detail. For reconciliation, the key is to link the source event to the destination event, rather than treating either transaction hash as the whole transfer.

Which records should you match?

Match the transfer using its shared message ID where available, then verify the details against both chain records. A useful reconciliation row keeps the instruction, source event and destination outcome together. Record at least:

• The intended asset, amount, chains and recipient.
• The source transaction hash and the amount locked or burned.
• The bridge message ID, route and current status.
• The destination transaction hash, amount received and any fee or shortfall.

Asset names alone are not enough. A token on the destination chain may be a wrapped representation of the source asset, with a different contract address and ticker. Maintain an approved mapping between the treasury’s accounting asset and each chain’s token contract. Also distinguish the requested amount from the amount delivered: bridge fees, network fees or route terms can change what arrives.

When is a transfer complete?

Mark a transfer complete only when the source event is sufficiently final and the destination action has succeeded. A submitted source transaction is not yet proof of a settled transfer. The bridge may still be waiting for confirmations, validators, or a destination transaction. Use the route’s documented finality rules to decide when the source event can be treated as settled.

Until both sides are confirmed, keep the amount in a transfer-clearing account or equivalent pending status. This makes the timing gap visible without recording the same funds as available in both wallets. Once the destination credit is confirmed, clear the pending entry against the receiving wallet. Record fees separately if your accounting policy tracks them as an expense.

How should you handle delays or failures?

Keep an unmatched transfer open and classify it by its last confirmed step. If the source transaction failed, there may be no funds to recover. If tokens were locked but the destination mint or release failed, the transfer remains in flight until the bridge completes it or its recovery process returns the funds. Do not create a destination credit based only on the original instruction.

Review exceptions against the bridge status and both chain records. A delayed transfer needs follow-up; a refunded transfer needs its return transaction matched; and a partial receipt needs its difference explained. The practical rule is simple: reconcile the instruction, the source movement and the destination outcome as one linked record, while keeping pending value distinct from settled treasury funds.