Reconcile each bridge transfer as two chain events joined by one instruction ID. Track the source debit, the destination settlement, and any conversion or fees separately; close the transfer only after the destination meets your settlement policy. This handles asynchronous execution and makes delayed or partially completed routes visible in the ledger.
One transfer needs a linked pair of records
A source transaction hash proves that a transaction was submitted or included; it does not prove that the recipient received funds on the destination chain. Keep a transfer record that links the business instruction to every source and destination transaction, plus any protocol message identifier or route-hop transactions the execution exposes.
For the full Rango Bridge transfer integration flow, see the end-to-end implementation guide. This article focuses on the treasury control that follows submission: matching evidence across chains and deciding when to recognize settlement. Rango Bridge can be one route for cross-chain transfers, but the accounting record should remain independent of the route provider.
Use a stable internal transfer ID as the idempotency key for your own ledger and event processing. A practical record includes:
- Instruction ID, created time, business purpose, and approval reference.
- Source chain, asset contract or denomination, amount, sender, and transaction hash.
- Destination chain, asset, recipient, minimum acceptable receipt, and expected route.
- Observed destination amount, transaction hash, event or message ID, and settlement status.
- Network fees and conversion differences, each recorded in its actual asset.
Settlement requires source finality and destination evidence
Mark a transfer settled only when the source event passes your chain-specific finality threshold and the destination event is confirmed at the intended recipient. Match on the strongest available identifiers—message ID or protocol event when available, then recipient, asset, amount range, and execution window—rather than assuming source and destination hashes share a common format.
Set the threshold per chain and risk tier; there is no universal safe confirmation count. Ethereum uses proof-of-stake finality through justified and finalized checkpoints, with finality typically taking about 15 minutes. Bitcoin has probabilistic finality: its Developer Guide describes six confirmations as a common policy for high-value payments, while stressing that the acceptable wait depends on risk.
For an illustrative policy, a business might require Ethereum finalization for routine transfers and six Bitcoin confirmations for high-value receipts. If an upstream bridge or messaging protocol applies its own verification threshold, treat that as an additional execution condition, not a substitute for your treasury’s settlement policy.
Reconcile amounts as a three-part bridge
Compare the source debit, destination credit, and fees or conversion difference; do not expect the two principal amounts to be equal when the route swaps assets. Define the expected destination amount from the instruction’s minimum receipt and route quote, then investigate any shortfall against that tolerance.
For example, an illustrative instruction debits 10,000 USDC and specifies a minimum receipt of 9,850 USDC on the destination chain. If the destination event credits 9,872 USDC and source and destination evidence both meet policy, record 9,872 received and 128 as the aggregate difference; break that difference into explicit network fees, swap impact, and other known charges where evidence supports the split. If only 9,820 arrives, leave the transfer open for investigation instead of silently treating the minimum as met.
Store token amounts in integer base units, alongside the token’s decimals and contract address or native denomination. This prevents rounding errors and symbol collisions; value fees in a reporting currency using a documented rate source and timestamp, rather than folding them into the token amount.
Exceptions should preserve the open balance
Keep the transfer pending when the source is final but destination evidence is absent, the destination amount is below its minimum, or a destination transaction fails. A source reorganization can invalidate an apparently included event before finality, while retries can create duplicate destination events if your reconciliation worker treats a timeout as proof of failure.
Process chain events idempotently: store each event’s chain, transaction hash, and log index (or the chain’s equivalent), and update one instruction record when evidence arrives. If several destination events correspond to a multi-hop route, reconcile the route’s terminal receipt and retain intermediate events as execution evidence. In practice, I’d pilot this ledger and its exception queue with small transfers across each chain pair before assigning larger treasury limits.