> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Bridge

> How collateral moves between Intention and external chains — deposits, two-phase withdrawals with a dispute period, and the roles that can stop it.

The bridge is where the network touches assets it did not create. Everything else in this architecture is a closed system whose correctness anyone can check by replaying blocks. A bridge cannot be, because half of it is on another chain with its own validators, its own finality, and its own failure modes.

That asymmetry drives the design. Deposits and withdrawals are not symmetric operations, and withdrawals are deliberately slower than they technically need to be.

## Roles

<div className="dg" data-dg="bridge-roles">
  <div className="dg-c" style={{aspectRatio:"720 / 330"}}>
    <svg className="dg-w" viewBox="0 0 720 330" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 289.00 86.00 L 364.60 86.00" />

      <path className="dg-head dg--blue" d="M 371.00 86.00 L 364.60 90.40 L 364.60 81.60 Z" />

      <path className="dg-wire dg--blue" d="M 540.00 112.00 L 540.00 125.60" />

      <path className="dg-head dg--blue" d="M 540.00 132.00 L 535.60 125.60 L 544.40 125.60 Z" />

      <path className="dg-wire dg--sky" d="M 371.00 166.00 L 295.40 166.00" />

      <path className="dg-head dg--sky" d="M 289.00 166.00 L 295.40 161.60 L 295.40 170.40 Z" />

      <path className="dg-wire dg--yellow dg-dash" d="M 371.00 246.00 L 330.00 246.00 L 330.00 196.00 L 295.40 196.00" />

      <path className="dg-head dg--yellow" d="M 289.00 196.00 L 295.40 191.60 L 295.40 200.40 Z" />
    </svg>

    <div className="dg-band" style={{left:"0.0000%",top:"7.8788%",width:"41.6667%",height:"63.6364%"}}><span className="dg-cap">External chain</span></div>
    <div className="dg-band" style={{left:"50.0000%",top:"7.8788%",width:"50.0000%",height:"78.7879%"}}><span className="dg-cap">Intention</span></div>
    <div className="dg-b dg--orange" style={{left:"2.2222%",top:"18.1818%",width:"37.2222%",height:"45.4545%"}}><span className="dg-t">Bridge contract</span><span className="dg-s">holds custody · verifies signatures before releasing anything</span><span className="dg-n">the piece a user's funds actually depend on</span></div>
    <div className="dg-b dg--blue" style={{left:"52.2222%",top:"14.5455%",width:"45.5556%",height:"18.1818%"}}><span className="dg-t">Validators</span><span className="dg-s">observe the external chain and sign what they see</span></div>
    <div className="dg-b dg--sky" style={{left:"52.2222%",top:"41.2121%",width:"45.5556%",height:"18.1818%"}}><span className="dg-t">Finalizer</span><span className="dg-s">a relay, not an authority — it cannot create a withdrawal validators did not sign</span></div>
    <div className="dg-b dg--yellow" style={{left:"52.2222%",top:"65.4545%",width:"45.5556%",height:"18.1818%"}}><span className="dg-t">Governor</span><span className="dg-s">validator set and parameters — what cannot be automated safely</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"89.0909%",width:"100.0000%"}}><div className="dg-n">A withdrawal is only actionable once enough validator signatures are aggregated — the same trust assumption as consensus, applied across a chain boundary.</div></div>
    <div className="dg-lbl" style={{left:"45.8333%",top:"21.2121%",width:"12.2222%",whiteSpace:"normal"}}>deposit events</div>
    <div className="dg-lbl" style={{left:"87.2222%",top:"36.9697%",width:"19.4444%",whiteSpace:"normal"}}>aggregated signatures</div>
    <div className="dg-lbl" style={{left:"45.8333%",top:"45.4545%",width:"12.2222%",whiteSpace:"normal"}}>withdrawal transactions</div>
  </div>
</div>

**Validators** observe the external chain and sign what they see. A withdrawal is only actionable once enough validator signatures have been aggregated — the same trust assumption as consensus, applied across a chain boundary.

**The finalizer** submits transactions on the external side. It is a relay, not an authority: it can choose *when* to submit and can fail to submit, but it cannot create a withdrawal the validators did not sign.

**The governor** performs administrative operations — validator set changes, parameter updates. Its powers are the ones that cannot be automated safely.

**The bridge contract** holds custody on the external side and verifies signatures before releasing anything. It is the piece a user's funds actually depend on.

## Deposits

A deposit is the easy direction. Funds are locked in the external contract, which emits a deposit event; validators observe it, and the credit becomes a protocol-native transaction on Intention.

Because that credit is an ordinary transaction, it inherits everything the [kernel](/protocol/architecture/kernel) guarantees. It executes in canonical order, its effect on the account is attributed to it, and it is visible in the same output as any other state change. A deposit that restores margin on a position near liquidation is visible to the [Clearinghouse](/protocol/architecture/clearinghouse) in the same execution step — not in a later reconciliation.

The waiting is on the external chain's finality, not on Intention. A deposit is credited when the source chain's confirmation requirement is met.

## Withdrawals

A withdrawal is the dangerous direction, and it runs in two phases with a **dispute period** between them.

<div className="dg" data-dg="bridge-withdrawal">
  <div className="dg-c" style={{aspectRatio:"720 / 290"}}>
    <svg className="dg-w" viewBox="0 0 720 290" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 154.00 91.00 L 179.60 91.00" />

      <path className="dg-head dg--blue" d="M 186.00 91.00 L 179.60 95.40 L 179.60 86.60 Z" />

      <path className="dg-wire dg--sky" d="M 354.00 91.00 L 379.60 91.00" />

      <path className="dg-head dg--sky" d="M 386.00 91.00 L 379.60 95.40 L 379.60 86.60 Z" />

      <path className="dg-wire dg--green" d="M 554.00 91.00 L 582.40 49.29" />

      <path className="dg-head dg--green" d="M 586.00 44.00 L 586.04 51.77 L 578.76 46.81 Z" />

      <path className="dg-wire dg--orange" d="M 554.00 91.00 L 582.78 140.47" />

      <path className="dg-head dg--orange" d="M 586.00 146.00 L 578.98 142.68 L 586.58 138.26 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"15.1724%",width:"20.8333%",height:"32.4138%"}}><span className="dg-t">Requested on Intention</span></div>
    <div className="dg-b dg--sky" style={{left:"26.3889%",top:"15.1724%",width:"22.2222%",height:"32.4138%"}}><span className="dg-t">Signed by validators, registered on the contract</span><span className="dg-s">it does not pay out</span></div>
    <div className="dg-b dg--yellow" style={{left:"54.1667%",top:"15.1724%",width:"22.2222%",height:"32.4138%"}}><span className="dg-t">Dispute period</span><span className="dg-s">a configured window must elapse</span></div>
    <div className="dg-b dg--green" style={{left:"81.9444%",top:"5.5172%",width:"18.0556%",height:"19.3103%"}}><span className="dg-t">Finalized</span><span className="dg-s">funds released</span></div>
    <div className="dg-b dg--orange" style={{left:"81.9444%",top:"40.6897%",width:"18.0556%",height:"19.3103%"}}><span className="dg-t">Invalidated</span><span className="dg-s">cancelled before anything moves</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"67.5862%",width:"100.0000%",height:"26.2069%"}}><span className="dg-t">Why it waits</span><span className="dg-s">Every catastrophic bridge failure has the same structure: an attacker obtains the ability to authorize a withdrawal, and the funds are gone in the same block. A dispute period converts an instant, irreversible loss into a window in which monitoring and humans can act. The cost is that legitimate withdrawals wait too.</span></div>
    <div className="dg-lbl" style={{left:"79.1667%",top:"10.3448%"}}>elapsed</div>
    <div className="dg-lbl" style={{left:"79.1667%",top:"54.4828%"}}>disputed</div>
  </div>
</div>

A request is signed by validators and registered on the external contract. It does not pay out. A configured period must elapse first, during which the withdrawal can be **invalidated** — cancelled before any funds move.

This is not a performance oversight. Every catastrophic bridge failure has the same structure: an attacker obtains the ability to authorize a withdrawal, and the funds are gone in the same block. A dispute period converts an instant, irreversible loss into a window in which humans and monitoring can act. The cost is that legitimate withdrawals also wait.

Withdrawals are batched — requested and finalized in groups rather than one transaction each — which is why external-chain fees do not scale linearly with withdrawal count.

Failures are explicit. A withdrawal that cannot be finalized emits a failure with an error code rather than silently doing nothing, so the difference between *stuck* and *rejected* is observable rather than inferred from absence.

## Stopping it

Two mechanisms exist for when something is wrong.

**Invalidation** cancels a specific withdrawal inside its dispute period. It is the targeted response.

**Locking** is the blunt one: a designated role can lock the bridge, and the number of such parties required to act is itself a parameter. This is the mechanism for "something is wrong and we do not yet know what" — it stops the flow rather than adjudicating individual transactions.

<Warning>
  These controls are what make the dispute period useful, and they are also real trust assumptions. A party that can lock the bridge can stop legitimate withdrawals. This is a deliberate trade: bridges fail catastrophically and irreversibly, and the ability to halt one is worth more than the ability to guarantee it never pauses. See [Risk disclosures](/protocol/security/risks).
</Warning>

## Validator set changes

The external contract has to know who the validators are, which means validator set changes must propagate across the boundary. They are proposed and then finalized as a separate step, rather than taking effect the moment they are submitted — the same two-phase shape as withdrawals, for the same reason.

## Where the risk actually sits

Worth stating plainly, because bridges are where users lose money:

* **On Intention, the bridge is ordinary.** A credited deposit is a normal transaction with normal guarantees.
* **On the external chain, you depend on the contract and the signature threshold.** That is a different security model from consensus, and it is [audited separately](/protocol/security/audits) — the bridge is the component under third-party review.
* **In between, you depend on validators observing correctly** and on the finalizer submitting. Neither can fabricate a withdrawal; both can delay one.

<Note>
  Supported chains, assets, confirmation requirements, and the dispute period length are operational parameters that change with each release. The authoritative values are the ones shown in the deposit and withdrawal dialogs in the exchange at the moment you transfer — see [Deposit](/help/deposit) and [Withdraw](/help/withdraw).
</Note>

## Where to go next

<CardGroup cols={2}>
  <Card title="Deposit funds" href="/help/deposit">
    The user-facing path in, with current chains and timings.
  </Card>

  <Card title="Non-trading fees" href="/programs/other-fees">
    What a withdrawal costs, and why deposits are free.
  </Card>

  <Card title="Clearinghouse" href="/protocol/architecture/clearinghouse">
    What a deposit does to margin the moment it lands.
  </Card>

  <Card title="Risk disclosures" href="/protocol/security/risks">
    Bridge trust assumptions stated as risks.
  </Card>
</CardGroup>