Bifrost Bridge and Cross-Chain Observability

Bifrost is the component responsible for making THORChain aware of activity on external blockchains.

It is both a design concept and an operational surface. The design explains how nodes observe chains and coordinate inbound/outbound activity; live route availability still depends on current chain sync, Mimir controls, inbound-address state, signing state, and source freshness.

What Bifrost Does

Bifrost is the observer-and-signer service run by each THORNode. Its per-chain clients connect to the operator's external-chain nodes and handle relevant events such as:

• Inbound transactions (users sending assets into vaults)
• Outbound transaction confirmations
• Chain reorganizations and finality
• Chain-specific gas, confirmation, and broadcast conditions

The official stack documentation says THORNode operators run connected-chain clients for the network's supported chains. That is an operator architecture requirement, not proof that every current client is synced, healthy, or accepting a particular route.

How Observation Works

1. Per-chain observers independently scan new external-chain blocks for transactions involving THORChain vaults. Most ordinary mempool transactions are not treated as final observations.
2. Transactions involving Active and Retiring vaults are observed and gossiped for consensus; Inactive-vault handling has stricter recovery limits.
3. A transaction observation reaches THORChain consensus when at least 67% of active nodes attest to the same event.
4. Delayed-finality chains require a later finalised observation after chain-specific confirmation rules are satisfied.

This multi-observer model reduces reliance on any single node's report, while final safety still depends on the active validator set, chain finality, and current protocol controls.

Observation is not the same thing as execution. A transaction can be observed while the relevant route is still constrained by halted trading, halted signing, chain-specific controls, dust or fee thresholds, memo validity, pool status, or outbound delivery conditions.

Chain Clients And Finality

Bifrost is implemented through chain clients that understand the behavior of each connected chain. The source chain's block time, reorg risk, finality model, gas rules, memo support, and transaction format all matter. Confirmation counts can depend on transaction value, block reward, chain-specific multipliers, and maximum-confirmation controls, so one fixed count is not safe to reuse across chains.

That is why "Bifrost observed it" is an incomplete user-facing answer. For an inbound, outbound, or refund investigation, pair observation evidence with:

• the exact transaction hash and source chain,
• the current inbound-address and router data for that chain,
• current network diagnostics for trading, signing, and chain halt controls,
• quote or memo evidence for the intended action,
• any chain-specific confirmation or gas behavior that affects timing.

Why It Matters

Without reliable cross-chain observability, THORChain could not process inbound deposits or confirm outbound withdrawals with source-backed confidence. Bifrost is the subsystem that lets the protocol coordinate cross-chain activity rather than only internal pool accounting.

Vault status matters to this flow. Active vaults receive new assignments, Retiring vaults remain monitored while funds migrate, and Inactive vaults are no longer normal inbound or signing targets. Never send funds to a retired or inactive vault address; retrieve the current chain address and router from inbound_addresses immediately before constructing an action.

Current Bifrost claims need the matching network diagnostics, inbound_addresses, vault state, quote/transaction evidence, and source freshness. Design alone does not prove that a route is live, a transaction settled, or every chain behaves the same way.

Observation failures can lead to node penalties. See the Slashing deep dive for how missed or incorrect observations accumulate slash points and affect node standing.

Common Misreadings

• "Bifrost observed it = transaction is complete." Observation is reporting, not confirmation. A transaction can be observed while the relevant route is still constrained by halted trading, halted signing, chain-specific controls, dust or fee thresholds, memo validity, pool status, or outbound delivery conditions.
• "Bifrost only watches one chain." Each node runs Bifrost per-chain clients for every supported chain. The official stack documentation says THORNode operators run connected-chain clients for the network's supported chains, so a single node participates in observing all active chains.