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.

What To Verify Before Claiming

Before making a current Bifrost or route-health claim, verify:

1. /network#network-diagnostics for current chain, trading, signing, and source-warning state.
2. The relevant THORNode inbound_addresses entry for the chain being discussed.
3. Whether the observed vault was Active, Retiring, or Inactive at the relevant time.
4. The current quote or transaction evidence when the claim is about one swap, deposit, outbound, or refund.
5. Whether the issue is observation, finality, memo/intent validation, pool execution, signing, gas, outbound delivery, or interface behavior.
6. Whether an incident or upgrade source is dated historical context rather than proof of current safety.

Non-Claims

This page does not prove:

• A chain, route, inbound address, router, or outbound path is currently available.
• A specific transaction was observed, executed, refunded, or delayed for one cause.
• That all connected chains have identical finality, gas, or memo behavior.
• That an observation has reached both consensus and chain-specific finality merely because one provider reports it.
• That current chain-client health is clean across providers.
• That Bifrost design alone proves current vault, signing, or route safety.