Tracking In-Flight Cross-Chain Bridge Transfers
Track source and destination bridge evidence as separate stages, preserve message identity, and avoid treating a source-chain lock as destination delivery.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A bridge transfer spans at least two execution contexts. A source-chain transaction can complete while destination delivery remains pending, delayed or unsuccessful. One boolean success field cannot describe that lifecycle.
Model each evidence stage
Record source acceptance, message identity, destination execution and final recipient movement where applicable. Bridge mechanisms differ: lock-and-mint, burn-and-mint and liquidity-based flows are not interchangeable. Keep chain-specific finality and retry rules attached to each stage rather than borrowing the source transaction’s status.
Worked example: source complete, destination pending
A source transaction locks ten units and emits a bridge message. No accepted destination receipt has yet been observed. The correct status is source complete with destination unresolved, not ten units delivered. An exposure report can represent the in-flight claim under a declared policy without inventing a destination token balance.
Match by protocol identity
Use the bridge’s message or transfer identifiers and validate network, asset and recipient mappings. Test replayed notifications, delayed relays and failed destination execution. Store attempts separately from the eventual accepted result. A timeout should initiate investigation under the protocol’s recovery process, not silently trigger another transfer.
A practical acceptance test
Provide a successful source event and no destination execution. Assert an in-flight or unresolved destination state. Later deliver the destination event twice and verify one logical completion. Include a destination failure attempt followed by success, retaining both attempts rather than changing the source record into a universal success that hides the intermediate uncertainty.
Questions about the topic
Frequently asked questions
Does source success prove destination delivery?
No. They are separate execution stages.
Can every bridge use the same status model?
Use common stages cautiously while preserving mechanism-specific details.
Standards & technical documentation
