For recurring treasury transfers, define settlement as a verified destination credit after the source chain meets your finality policy, and release the downstream payout only then. Track each transfer as a state machine—submitted, source-final, verified, executed, reconciled—because a wallet’s success status can cover only one transaction in a multi-chain obligation.
What does “settled” mean across two chains?
A bridge transfer is settled for treasury purposes when the source debit is durable, the bridge’s message or proof has been accepted, and the intended destination asset is available at the expected address. Source inclusion alone is not settlement: the destination credit may still be waiting on verification, execution, or a destination transaction.
Model those stages separately in your ledger. Record the source transaction hash and amount, source and destination chain IDs, token contract addresses, recipient, bridge message ID or nonce where available, destination transaction hash, delivered amount, and timestamps. Keep the raw token units as well as the displayed decimal amount; token decimals and representations can differ across chains.
Where does the transfer spend time?
Time accumulates at several independent checkpoints: source-chain confirmation, bridge verification, destination execution, and destination-chain confirmation. In LayerZero V2, for example, the application’s pathway config sets a source confirmation count and a DVN quorum; required DVNs must verify, while optional DVNs can be governed by a threshold. An executor then submits the destination transaction.
That design means a transfer can be source-final but not yet verified, or verified but not yet executed. Ethereum.org describes Ethereum proof-of-stake finality through checkpoint votes; under normal conditions, finality takes roughly two epochs, or about 13 minutes. A bridge may act on a configured confirmation threshold before full finality, so the pathway’s setting—not a generic “wait five minutes” rule—determines its risk and latency.
How should a treasury set its release policy?
Set the policy per route and value band. For low-value routine flows, an organization may accept a pathway’s configured confirmation threshold and wait for destination execution; for a large payout, require stronger source finality, independent confirmation of the destination credit, and an exception review if the route stalls. The right threshold depends on chain reorganization risk, verifier design, bridge exposure, and how quickly the business must pay.
For a Mantle bridge transfer, apply the same controls: verify the exact source and destination networks, asset representation, recipient, and delivered amount before treating funds as available. If the treasury also needs an asset conversion, a Mantle bridge swap service can move and swap assets across chains in one flow; reconcile the final output asset and amount, not only the source debit. Combining actions reduces operational handoffs, but it adds a destination swap whose execution can fail independently.
How do you reconcile a real transfer?
Say the treasury sends 10,000 USDC and receives 9,985 USDC after a destination swap. Reconcile the source debit of 10,000 against the destination receipt of 9,985, then classify the 15 USDC difference using the actual route’s swap execution and transaction records. Do not book the difference as a bridge fee by assumption.
Maintain one transfer record with explicit status transitions. If source finality is reached but no destination transaction appears, check verification and execution status before retrying; resubmitting can create a second payment. If the destination transaction reverts, follow the route’s documented recovery behavior and keep the item in transit or exception status until assets are actually recoverable or credited.
Can we release a payout after the source transaction confirms?
Only if your written risk policy explicitly accepts that exposure. A source confirmation means the debit appeared on that chain; it does not prove that the bridge has verified the message or that the destination asset is spendable. For routine payouts, use destination credit as the release trigger and retain the source status as a separate control.
What if the destination amount differs from the source amount?
Compare like with like: token contract, chain, decimal units, and the route’s expected conversion. A swap changes the asset amount, and fees or execution price can affect output. Reconcile against the destination transaction and quote or route record, then assign any variance to the correct accounting category rather than forcing the two token amounts to match.
What is the most useful operational control?
Set a maximum time in each transfer state and alert when it expires; the right interval depends on the chains and route. Include the transfer ID, source hash, last confirmed state, and expected destination in the alert. As a practical rule, never retry from a stale dashboard status alone—first establish whether the original message already reached destination execution.
Top comments (0)