Deposits & withdrawals

Deposits

You deposit USDC to the bridge contract on Base. Validators observe the deposit and sign an attestation; when a quorum of signatures lands on chain, your balance credits — immediately, with no maturation delay. A deposit is identified by its L1 log site (chain, contract, transaction, log index), which makes it recomputable by anyone from a Base receipt and replayable by no one. Global and per-account deposit caps exist as governed parameters.

Withdrawals — the three-state exit

A withdrawal is REQUESTED → FINALIZED or REQUESTED → CANCELLED; both ends are permanent, and a cancelled withdrawal can never finalize.

Request is yours alone — no validator signatures. It moves the amount from your available balance into pending, counts against a per-epoch outflow ceiling, and — for providers — is bounded by the challenge holdback: money a dispute might still need cannot enter the exit.

Large withdrawals wait. Amounts above a threshold become finalizable only after a delay window; smaller ones are finalizable immediately. The delay is the security design, in four words the spec itself uses: delay exposes, pause freezes, cancel voids — an anomalous exit becomes visible during the delay, the bridge can be paused (which blocks finalize too), and the pending withdrawal can be voided back to its owner. Then resume is safe.

Finalize requires a two-thirds quorum of validator signatures over the on-chain record — from a distinct set of bridge signing keys, kept separate from the always-hot data-availability keys, and failing closed if unset. A quorum signature can never move funds without a matching locked record, and signing an invalid withdrawal costs a validator its full bond. One more gate runs at finalize: the account's current challenge holdback must still be covered — a provider whose disputes grew during the delay cannot exit money restitution may need.

The solvency identity

The chain's mirror of bridge-locked USDC increases only on deposit credit and decreases only on finalize — and after every single bridge operation, the ledger must satisfy, exactly:

bridge_locked_usdc == Σ (available + locked_escrow + locked_bond + pending_withdrawal)

Not at audit time — at the end of every transition, as a rejection path: a transition that would break the identity does not happen.

The honest trust model