Why
Intents did not eliminate bridge risk — they moved it from users to fillers. A user signs on the origin chain, escrows input tokens, and the filler advances their own funds on the destination chain immediately. The user gets instant finality, while the filler waits to reclaim the origin escrow.
The part worth a card is what ERC-7683 deliberately left out. The standard specifies:
- The cross-chain order struct (
GaslessCrossChainOrder,OnchainCrossChainOrder) - Two standard interfaces (
IOriginSettler.open(),IDestinationSettler.fill())
That defines the envelope. It says nothing about what proof allows the filler to unlock the escrow. ERC-7683 is settlement-agnostic by design, explicitly delegating settlement contract security evaluation to fillers and applications.
So the same "ERC-7683 compatible" label encompasses three completely different trust architectures:
- Optimistic verification (Across style): Repaid if nobody disputes within a challenge window.
- Light client: Cryptographic proof of the origin block header verified on the destination.
- Generic bridge messaging: A multisig committee attests that the fill occurred.
What matters is that their failure modes hurt different participants. If optimistic verification fails (e.g. lazy disputers), the filler loses. If a light-client verification bug occurs or a bridge committee is compromised, everyone with funds in escrow loses. The label "7683 compatible" conveys none of this critical distinction.
How it works
How the money actually moves — t=0, t=1, t=2
Intents changed what the user specifies, not what has to happen. The old way named a route — bridge here, swap there — and the user carried the failure of every step. An intent names only the outcome: 100 USDC on Arbitrum, want at least 99 on Base. One signature, and fillers compete over the route. The user no longer needs to know what a bridge is, which is why it sold.
But the money moves in three beats, and this whole card lives in the gap between two of them.
| what happens | who is exposed | |
|---|---|---|
| t=0 | User locks 100 USDC in origin escrow and signs the order — IOriginSettler.open() |
nobody yet |
| t=1 | Filler pays the user 99 USDC of their own money on the destination chain — IDestinationSettler.fill() |
the user is finished here — instant finality |
| t=2 | Filler submits proof of having paid and reclaims the 100 USDC escrow. Profit: 1 USDC | the filler, for the entire t=1 → t=2 gap |
So intents did not remove bridge risk. They moved it, at t=1, from the user to the filler. And this card is about exactly one question: what counts as proof at t=2?
What the standard fixes, and what it leaves blank
fixed: GaslessCrossChainOrder / OnchainCrossChainOrder
IOriginSettler.open() <- t=0
IDestinationSettler.fill() <- t=1
blank: what releases the escrow <- t=2
The envelope is specified. What opens the envelope is not.
Why the blank is not laziness
Had ERC-7683 picked one settlement model it would not have been adopted — the optimal choice differs per chain pair, and the field is still moving. Staying agnostic is why it spread. That generalises into something close to a law of standards:
> A standard's adoption speed and the amount it guarantees move in opposite directions.
ERC-20 is the same case, one generation earlier: the interface was fixed and the behaviour was not. Fee-on-transfer and rebasing tokens followed, and integrations written against "ERC-20 compatible" still break on them today. A token where transfer(100) delivers 97 is not violating the standard.
"7683 compatible" is a promise of the same size — smaller than it sounds.
What the three models actually do at t=2
| what the filler presents | how it is checked | |
|---|---|---|
| Optimistic | a claim to have paid, plus a bond | treated as true if nobody objects |
| Light client | a header proof from the destination chain | verified cryptographically on the origin chain |
| Bridge messaging | a committee signature | the committee is trusted |
The third reduces t=2 to "someone said so" — which is why a compromised committee drains the escrow, not one filler's principal but everyone's. The table below re-sorts the same three by who absorbs that loss.
And the gap is the spread. t=1 → t=2 is the filler's capital lockup, and the settlement model sets its length — which is precisely what the formula further down prices. So "the cheapest intent protocol" means "the settlement layer that locks capital for the shortest time," and that is usually risk placed differently, not risk removed. The advertising quotes only the first half.
The Three Settlement Models Aligned by Risk
| Model | Filler Retrieval Basis | Capital Turnaround | Filler's Risk Exposure | Failure Mode & Blast Radius |
|---|---|---|---|---|
| Optimistic | No valid challenge within dispute window | Tens of minutes to hours | Capital lockup + challenger liveness risk | Filler loses principal if false claim slips through |
| Light Client | Destination verifier checks origin header proofs | Block finality (~12s to 15m) | Protocol/verifier implementation bugs | Complete drain of all escrowed funds |
| Bridge Messaging | Multi-sig / oracle committee signs attestation | Message propagation delay | Bridge committee compromise | Complete drain of all escrowed funds |
Filler Economics: Short-Term Lending & Spread Formation
A filler is fundamentally a short-term lending desk:
- Fronting liquidity on the destination chain is extending a credit line to the user.
- The settlement layer dictates the duration of that loan.
Under optimistic verification, capital remains locked for the entire challenge window (e.g. 1–2 hours). That reduces capital velocity (turnover), requiring a thicker spread to clear hurdle rates. Under a light-client model, capital turns over with block finality, allowing tighter spreads at the cost of absorbing implementation risk.
$$\text{Minimum Spread} \ge (\text{Cost of Capital} \times \text{Lockup Time}) + \text{Default / Bug Risk}$$
When protocol marketing advertises "cheapest cross-chain intent execution," it is usually advertising a settlement layer that minimizes capital lockup time while silently trading off audit perimeter and blast radius.
Prediction Market & Verex Implications
In a cross-chain prediction market (e.g. Verex), a user on Chain B wanting to bet on a market on Chain A relies on this exact filler model:
- Verex or the filler must open the position instantly on Chain A while accepting escrow on Chain B.
- If the settlement layer has long latency or high dispute risk, the filler's quotation spread degrades the user's betting odds.
- This connects directly to
governance-capture-cost(audit perimeter ending at the interface while economic risk lives in the settlement substrate) andl1-zkevm-optional-proofs(trust assumptions resting on economic incentives rather than uniform cryptographic guarantees).
Update 2026-08-25 — the same blank, one layer over
The Term Labs incident ($8.5M, no line of code broken) has the identical shape. ERC-7683 specifies the order envelope and leaves settlement verification blank; Yearn v3 specifies vault logic and privileged roles and leaves the holder of those roles blank. In both, the integrating team fills the blank and no auditor reviews it, so "built on audited components" is true and insufficient — the gap between components belongs to nobody's audit scope.
The mitigation transfers too. The decisive step in the Term attack was registering an attacker-controlled contract as a strategy, possible only because a general call(target, calldata) was reachable through governance. Narrowing a settlement path to a pre-registered whitelist of functions and addresses binds the blast radius in code, whichever trust model the settlement layer uses — and unlike a timelock, a whitelist works with nobody watching the queue.
So the cheapest first measurement is not the challenge-window number but a single yes/no: does our settlement path expose a general call? If it does, the security of that path is not a property of the code but the market price of whoever holds the permission.