Skip to main content
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

External chain
Intention
Bridge contractholds custody · verifies signatures before releasing anythingthe piece a user’s funds actually depend on
Validatorsobserve the external chain and sign what they see
Finalizera relay, not an authority — it cannot create a withdrawal validators did not sign
Governorvalidator set and parameters — what cannot be automated safely
A withdrawal is only actionable once enough validator signatures are aggregated — the same trust assumption as consensus, applied across a chain boundary.
deposit events
aggregated signatures
withdrawal transactions
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 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 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.
Requested on Intention
Signed by validators, registered on the contractit does not pay out
Dispute perioda configured window must elapse
Finalizedfunds released
Invalidatedcancelled before anything moves
Why it waitsEvery 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.
elapsed
disputed
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.
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.

​
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 — 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.
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 and Withdraw.

​
Where to go next

Deposit funds

The user-facing path in, with current chains and timings.

Non-trading fees

What a withdrawal costs, and why deposits are free.

Clearinghouse

What a deposit does to margin the moment it lands.

Risk disclosures

Bridge trust assumptions stated as risks.