Copy English

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:

1. Optimistic verification (Across style): Repaid if nobody disputes within a challenge window.
2. Light client: Cryptographic proof of the origin block header verified on the destination.
3. 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.

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

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

Filler Economics: Short-Term Lending & Spread Formation

A filler is fundamentally a short-term lending desk:

1. Fronting liquidity on the destination chain is extending a credit line to the user.
2. 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) and l1-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.

1 diagram(s) on the live page.

Where it lands in Jayverse

• Verex: name the settlement model before calling anything "7683 compatible." If Verex ever uses an intent/filler model across chains, write down which of the three settlement models (optimistic, light client, bridge committee) it uses and price the filler spread from the actual capital-lockup time, not from the label.
• Bridge/Token: run the general-call test on the relayer. Check whether the JYVE lock-and-mint relayer's mint path exposes a general call(target, calldata) reachable through any privileged role; if it does, narrow it to a pre-registered whitelist of functions and addresses, the same mitigation that would have stopped the Term Labs pattern.
• Auditor: add "does settlement expose a general call" as a standing yes/no check. Apply it to every cross-chain or privileged-role contract (Bridge, Verex filler, OFA solver) before sign-off, since the answer decides whether security is a property of the code or of whoever holds the permission.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

ERC-7683 정산 보안 — 표준이 일부러 비워둔 그 층

ERC-7683은 주문 봉투만 표준화하고 정산 증명은 비워뒀습니다. 세 정산 모델(낙관적, 라이트클라이언트, 위원회 브릿지)이 브릿지 리스크를 누가 실제로 지는지와 필러 스프레드가 벌어지는 이유를 결정합니다.

아직 범위 미정 — 세 정산 계층의 필러 자본 회수 시간(수십 분~시간), 분쟁 실패 시 피해 반경, 스프레드 가격 결정을 비교 분석하는 것부터. 출처: ERC-7683 스펙(erc7683.org), Across 프로토콜 문서, EIP-7683.

왜

인텐트는 브릿지 리스크를 없앤 게 아니라 사용자에게서 필러로 옮겼습니다. 사용자가 서명하면 출발 체인에 입력 토큰이 에스크로되고, 필러가 목적지 체인에서 자기 돈으로 먼저 지급합니다. 사용자는 즉시 자금을 받고, 브릿지 대기 리스크는 에스크로 회수를 기다리는 필러가 집니다.

카드가 될 값어치는 ERC-7683이 일부러 비워둔 자리에 있습니다. 표준이 정한 것은:

• 크로스체인 주문 구조체(GaslessCrossChainOrder, OnchainCrossChainOrder)
• 두 표준 인터페이스(IOriginSettler.open(), IDestinationSettler.fill())

즉 봉투 규격까지입니다. 필러가 무엇을 근거로 에스크로를 회수해 가는지는 전혀 정하지 않았습니다. ERC-7683은 정산 검증 방식에 의도적으로 불가지론적(agnostic)이며, 정산 컨트랙트의 보안 평가 책임을 필러와 앱에 명시적으로 위임합니다.

그래서 같은 "ERC-7683 호환"이라는 간판 아래 완전히 다른 세 가지 신뢰 모델이 들어갑니다:

1. 낙관적 검증 (Across류): 챌린지 기간 동안 이의 제기가 없으면 참으로 간주.
2. 라이트클라이언트: 출발 체인의 블록 헤더를 목적지에서 암호학적으로 검증.
3. 범용 브릿지 메시징: 위원회(멀티시그)가 체결되었다고 서명.

핵심은 셋의 실패 모드가 서로 다른 사람을 다치게 한다는 것입니다. 낙관적 검증이 실패하면 필러가 잃지만, 라이트클라이언트 구현 버그나 위원회 침해가 발생하면 에스크로에 잠긴 모든 사용자의 자금이 털립니다. "7683 호환"이라는 라벨은 이 구분을 전혀 담지 않습니다.

동작 방식

돈이 실제로 어떻게 흐르는가 — t=0, t=1, t=2

인텐트가 바꾼 것은 사용자가 무엇을 지정하는가이지 실제로 무슨 일이 일어나야 하는가가 아닙니다. 기존 방식은 경로를 지정했고 — 브릿지 A로 옮기고, DEX B에서 스왑하고 — 각 단계의 실패를 사용자가 떠안았습니다. 인텐트는 결과만 지정합니다: Arbitrum에 100 USDC 있음, Base에서 99 USDC 이상 받고 싶음. 서명 한 번이면 경로는 필러들이 경쟁해서 알아서 찾습니다. 사용자는 이제 브릿지가 뭔지 몰라도 되고, 그게 인텐트가 팔린 이유입니다.

그런데 돈은 세 박자로 움직이고, 이 카드 전체가 그중 두 박자 사이의 틈에 있습니다.

즉 인텐트는 브릿지 리스크를 없앤 게 아닙니다. t=1에서 사용자에게서 필러로 옮긴 것입니다. 그리고 이 카드의 주제는 질문 하나입니다 — t=2에서 무엇이 증명으로 인정되는가.

표준이 정한 것과 비워둔 것

정함:   GaslessCrossChainOrder / OnchainCrossChainOrder
        IOriginSettler.open()        <- t=0
        IDestinationSettler.fill()   <- t=1

비움:   무엇이 에스크로를 풀어주는가   <- t=2

봉투 규격은 정했고, 봉투를 열어주는 근거는 정하지 않았습니다.

그런데 이 빈칸은 게으름이 아닙니다

ERC-7683이 정산 모델 하나를 골랐다면 채택되지 않았을 겁니다 — 체인 쌍마다 최적이 다르고 이 분야는 아직 움직이는 중입니다. 불가지론으로 남긴 덕분에 빨리 퍼졌습니다. 이건 표준 일반의 법칙에 가깝습니다:

> 표준의 채택 속도와 그 표준이 보장하는 것의 양은 반대 방향으로 움직입니다.

ERC-20이 한 세대 앞선 같은 사례입니다. 인터페이스는 정하고 동작은 정하지 않았습니다. 그래서 수수료를 떼는 토큰과 리베이싱 토큰이 나왔고, "ERC-20 호환"만 믿고 짠 통합은 지금도 그 위에서 깨집니다. transfer(100)을 불렀는데 97이 도착하는 토큰은 표준을 어긴 것이 아닙니다.

"7683 호환"도 정확히 같은 크기의 약속입니다 — 들리는 것보다 작습니다.

세 모델이 t=2에서 실제로 하는 일

세 번째는 t=2를 사실상 *"누가 그렇다고 말했다"*로 줄입니다 — 그래서 위원회가 뚫리면 한 필러의 원금이 아니라 에스크로 전체가 나갑니다. 아래 표는 같은 셋을 그 손실을 누가 흡수하는가로 다시 정렬한 것입니다.

그리고 그 틈이 곧 스프레드입니다. t=1 → t=2가 바로 필러 자본의 구속 시간이고, 그 길이를 정하는 것이 정산 모델이며, 아래 수식이 가격을 매기는 대상이 정확히 그것입니다. 그래서 *"가장 싼 인텐트 프로토콜"*은 *"자본을 가장 덜 묶는 정산 층"*을 뜻하고, 그건 대개 리스크를 없앤 것이 아니라 다르게 배치한 것입니다. 광고는 앞의 절반만 인용합니다.

세 정산 모델을 리스크로 나란히 놓으면

필러 경제학: 단기 대출업과 스프레드 형성

필러의 본질은 단기 대출업입니다:

1. 목적지 체인에서 자기 자본으로 먼저 지급하는 것은 사용자에게 단기 신용을 제공하는 것과 같습니다.
2. 그 대출의 만기(기간)를 정하는 것이 바로 정산 계층입니다.

낙관적 검증에서는 챌린지 기간 내내 자본이 묶이므로, 자본 회전율이 떨어지고 스프레드가 두꺼워지며 사용자가 그 비용을 부담합니다. 반대로 라이트클라이언트는 자본 회전이 빠른 대신 스마트 컨트랙트 검증 버그 위험을 필러와 프로토콜이 떠안습니다.

$$\text{최소 스프레드} \ge (\text{자본비용} \times \text{구속 시간}) + \text{디폴트/버그 위험}$$

"어느 인텐트 프로토콜이 가장 싼가"는 결국 "어느 정산 층이 자본을 덜 묶는가"로 귀결되며, 사용자에게 보이는 가격 차이의 상당 부분이 여기서 발생합니다. 프로토콜 마케팅이 이를 자세히 설명하지 않는 이유는 비용을 설명하려면 숨겨진 신뢰·리스크 모델을 함께 공개해야 하기 때문입니다.

예측시장 및 Verex 함의

Verex 같은 크로스체인 예측시장에서 체인 B의 사용자가 체인 A의 마켓에 즉시 베팅하려 할 때 필러 모델이 그대로 작동합니다:

• 사용자는 체인 B에 증거금을 넣고, Verex/필러는 체인 A에서 즉시 포지션을 열어줘야 합니다.
• 정산 계층의 지연이 길거나 분쟁 위험이 크면 필러는 불리한 호가 스프레드를 제시하고, 사용자의 베팅 배당률이 깎입니다.
• 이는 governance-capture-cost(감사 경계는 주문 인터페이스에서 끝나지만 실제 돈이 걸린 곳은 정산 기저층인 구조) 및 l1-zkevm-optional-proofs(안전이 경제적 할인율 선택에 기대는 구조)와 정확히 같은 논리적 궤를 공유합니다.

2026-08-25 보강 — 같은 빈칸, 한 층 위

Term Labs 사건($8.5M, 코드는 한 줄도 안 깨짐)이 정확히 같은 모양입니다. ERC-7683은 주문 봉투를 정하고 정산 검증을 비워뒀고, Yearn v3는 금고 로직과 권한 역할을 정하고 그 역할을 누가 갖는지를 비워뒀습니다. 둘 다 빈칸을 채우는 것은 통합하는 팀이고 감사인은 보지 않으므로, "감사받은 컴포넌트로 지었다"는 참이면서 불충분합니다 — 컴포넌트 사이의 빈칸은 누구의 감사 범위도 아닙니다.

완화책도 그대로 옮겨옵니다. Term 공격의 결정적 단계는 공격자 컨트랙트를 전략으로 등록한 것이고, 그게 가능했던 이유는 거버넌스를 통해 범용 call(target, calldata)에 도달할 수 있었기 때문입니다. 정산 경로를 사전 등록된 함수·주소 화이트리스트로 좁히면 정산 층의 신뢰 모델이 무엇이든 피해 반경이 코드로 묶입니다. 그리고 타임락과 달리 화이트리스트는 큐를 지켜보는 사람이 없어도 작동합니다.

그래서 가장 싼 첫 측정은 챌린지 기간 숫자가 아니라 예/아니오 한 줄입니다 — 우리 정산 경로에 범용 call이 노출돼 있는가. 있다면 그 경로의 보안은 코드의 속성이 아니라 그 권한을 쥔 주체의 시장 가격입니다.

1 diagram(s) on the live page.

Jayverse에서의 위치

• Verex: "7683 호환"이라 부르기 전에 정산 모델부터 지정한다. Verex가 체인 간 인텐트/필러 모델을 쓰게 된다면 세 정산 모델(낙관적, 라이트 클라이언트, 브리지 위원회) 중 무엇을 쓰는지 적어두고, 라벨이 아니라 실제 자본 잠김 시간으로 필러 스프레드를 가격 책정한다.
• Bridge/Token: 릴레이어에 general call 테스트를 적용한다. JYVE lock-and-mint 릴레이어의 민팅 경로가 어떤 권한 있는 역할을 통해서든 general call(target, calldata)에 도달 가능한지 확인한다. 가능하다면 사전 등록된 함수·주소 화이트리스트로 좁힌다. Term Labs 패턴을 막았을 완화책과 같다.
• Auditor: "정산이 general call을 노출하는가"를 상시 체크 항목으로 추가한다. Bridge, Verex 필러, OFA 솔버 등 체인 간 또는 권한 역할이 있는 모든 컨트랙트에 승인 전 적용한다. 이 답이 보안을 코드의 속성으로 만들지, 권한 보유자의 시가로 만들지를 결정한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑