Skip to main content
Intention connects to other chains through a bridge that is mediated by the protocol’s own validator set, under the same fault model as every other operation. There is no separate bridge committee, no independent trust anchor, and no multisig with a different threshold. Cross-chain deposits and withdrawals are Intention transactions like any other.

​
Role of the bridge

A bridge is the interface through which external value enters and leaves the financial state machine. On Intention, that interface has to preserve two properties:
  • Custody integrity. An asset that entered the bridge on the origin chain must be recoverable on the origin chain (or its Intention representation, with a bounded withdrawal path back). The bridge cannot silently rehypothecate or lose assets.
  • Protocol-native attribution. A deposit on Intention must be bound to the originating cross-chain event with cryptographic provenance, so that downstream consumers — exchanges, risk systems, auditors, compliance tools — can trace every balance change back to its origin event without trusting an intermediary.
Both properties follow from running the bridge as a protocol-level function rather than as an application-layer contract set.

​
Validator-mediated settlement

Cross-chain deposits and withdrawals are mediated by Intention’s validator set under the same 2f+12f+1 fault model as all other protocol operations. Validators observe events on the origin chain (deposits locked, burns finalized, messages emitted), and a 2f+12f+1 stake-weighted quorum is required to mint a corresponding credit on Intention. Symmetrically, a withdrawal from Intention is a protocol operation that burns an Intention-side balance and emits a message consumed on the destination chain, again under the 2f+12f+1 threshold. Withdrawal latency is bounded by the destination chain’s finality time plus attestation propagation. The attestation is just a 2f+12f+1 stake-weighted signature over the withdrawal event — the same signature primitive IntentionBFT uses for every other consensus-layer commitment.
Because the bridge runs under the same fault threshold as consensus, the security of cross-chain flows is not lower than the security of on-chain matching. There is no separate committee whose compromise would cost less than compromising the validator set.

​
What this looks like on Intention

A deposit from another chain becomes a protocol-native transaction of the transfer category. Its state effect — crediting the user’s subaccount on Intention — is attributed to that deposit in the Verifiable Execution Stream exactly as any other write would be. A withdrawal is the mirror: a user’s Intention-side transaction debits their subaccount, the protocol emits a cross-chain withdrawal message, validators collectively attest to it, and the destination chain’s bridge contract (or equivalent) releases funds once the attestation is present. Because cross-chain operations are part of the closed instruction set, the protocol knows the meaning of every bridge transaction. An auditor can enumerate exactly which flows are possible and which are not.

​
Security

Bridge-specific failure modes — operator key theft, oracle-committee compromise, relay censorship, replay — are part of the protocol’s threat model and are addressed inside the validator trust framework. The same 2f+12f+1 stake-weighted attestation that secures every other consensus-layer commitment also secures cross-chain messages, with no separate trust anchor introduced for the bridge.
Bridges have historically been the highest-loss surface in public blockchain history. Intention’s design deliberately avoids introducing a separate trust anchor for the bridge, but that does not make bridges safe by construction. The bridge is in scope for the bug bounty program; security researchers are encouraged to look at it specifically.

​
Supported chains and assets

The set of supported origin chains, bridgeable assets, and withdrawal paths is a governance decision within protocol-defined envelopes. Adding a new supported chain follows the same protocol-upgrade or parameter-update path as adding any other protocol-tracked external connection.
TBD. The concrete set of supported chains and assets at mainnet launch is not yet finalized and will be published alongside the mainnet release notes. The API-level integration surface is described in the API Integration → Bridge reference.

​
How the bridge relates to the four guarantees

  • OTD. Bridge transactions execute in canonical order within their blocks, like any other transaction, and produce byte-identical outputs across honest nodes.
  • PTA. If a bridge operation consults a price (for example, to value a deposit in a collateral context), it consults the same certified price vector as every other transaction in the block.
  • RNS. Bridge flows interact with risk state through the same atomic context as matching — a deposit that restores margin on a position at risk of liquidation is visible to the risk engine in the same execution step.
  • PTAD. Every bridge-driven state change and event is bound to the originating bridge transaction in the per-transaction output array, so downstream consumers see the full causal trail on the Verifiable Execution Stream.
The bridge does not introduce a second semantic regime. It is the same protocol, operating on transactions whose source happens to be cross-chain.