Cross-chain Intents와 ERC-7683

도입

cross-chain intent는 사용자가 "어느 bridge를 눌러야 하는가"를 직접 고르는 방식에서 벗어나, 원하는 결과를 주문으로 표현하고 solver가 여러 chain의 실행과 정산을 맡는 모델이다. 예를 들어 사용자는 "Ethereum의 USDC를 써서 Base의 merchant에게 100 USDC를 지급"이라는 결과만 승인하고, solver가 destination 지급과 source 정산을 연결할 수 있다.

이 모델은 UX를 단순하게 만들지만 위험을 없애지는 않는다. bridge 선택 위험이 solver 선택, resolver 신뢰, payment 조건, timeout/refund, settlement dispute로 이동한다. 이 강의에서는 intent를 "마법 같은 사용자 경험"이 아니라 새로운 리스크 분배 방식으로 읽는다.

학습 목표

• transaction 직접 실행과 intent/order 기반 실행의 차이를 설명한다.
• ERC-7683의 order, solver, payload, resolver 개념을 checkout 설계에 연결한다.
• solver가 destination에서 지급했지만 origin settlement가 실패하는 시나리오를 다룬다.
• resolver vetting, assumption validation, timeout/refund 정책을 만든다.

개념 설명

1. Intent는 실행 방법이 아니라 원하는 결과를 표현한다

intent 모델은 사용자의 행동을 줄인다. 대신 제품은 solver가 실제로 무엇을 했는지, 어떤 조건에서 결제가 완료되는지, solver가 손실을 감수하는 구간이 어디인지 기록해야 한다.

2. ERC-7683은 solver-facing interface를 표준화하려는 draft ERC다

2026년 5월 14일 확인 기준 ERC-7683은 draft 상태다. 이 ERC는 intent protocol 자체를 하나로 통일하기보다, solver가 protocol-specific payload를 공통 order representation으로 해석할 수 있게 resolver를 중심에 둔다.

draft 표준을 production SLA의 근거로 쓰면 안 된다. 표준화 방향을 이해하되, 실제 채택은 구현체, audit, resolver whitelist, solver market, monitoring을 따로 본다.

3. Intent 결제 시퀀스

제품 DB는 최소한 OrderCreated, Resolved, DestinationFilled, FillProofObserved, OriginSettled, TimedOut, Refunded, Disputed를 분리해야 한다. 사용자에게는 "결제 완료"로 보이더라도 solver settlement가 뒤에서 실패할 수 있기 때문이다.

4. CCTP, bridge, intent의 차이

intent는 CCTP나 bridge를 대체하는 단일 기술이 아니다. solver가 내부적으로 CCTP, bridge, DEX, inventory를 조합할 수 있다. 따라서 app은 "어떤 route를 썼는가"보다 "사용자에게 약속한 결과가 증명되었는가"를 기준으로 상태를 관리해야 한다.

코드로 확인하기

위 신뢰 모델을 코드와 운영 규칙으로 확인한다. 메시지 상태, 최종성, 재시도, 관측 지점이 어디서 분리되는지 보는 것이 목적이다.

컨트랙트ERC-7683 GaslessCrossChainOrder 구조와 IOriginSettler

ERC-7683은 cross-chain order의 직렬화·서명·resolve를 표준화한다. 핵심은 사용자가 서명한 order를 resolver가 해석해 fill 가능한 형태로 풀고, settler가 사용자 자금을 escrow한 뒤 solver가 destination을 채우는 흐름이다.

01struct GaslessCrossChainOrder {02    address originSettler;03    address user;04    uint256 nonce;05    uint256 originChainId;06    uint32  openDeadline;07    uint32  fillDeadline;08    bytes32 orderDataType;09    bytes   orderData;            // resolver-specific payload10}1112struct ResolvedCrossChainOrder {13    address user;14    uint256 originChainId;15    uint32  openDeadline;16    uint32  fillDeadline;17    bytes32 orderId;18    Output[] maxSpent;            // 사용자가 지출 가능한 최대19    Output[] minReceived;         // 사용자가 받아야 할 최소20    FillInstruction[] fillInstructions;21}2223interface IOriginSettler {24    function openFor(GaslessCrossChainOrder calldata order, bytes calldata signature, bytes calldata originFillerData) external;25    function resolveFor(GaslessCrossChainOrder calldata order, bytes calldata originFillerData)26        external view returns (ResolvedCrossChainOrder memory);27}

백엔드Resolver vetting — order 의 minReceived 가드

resolver가 반환한 minReceived가 사용자 의도와 일치하는지 검증. 잘못된 resolver를 신뢰하면 자금이 잘못된 곳으로 흐를 수 있다.

01type UserIntent = {02  fromChainId: number;03  toChainId: number;04  tokenIn: `0x${string}`;05  amountIn: bigint;06  tokenOut: `0x${string}`;07  minOut: bigint;08  recipient: `0x${string}`;09  fillDeadline: number;10};1112export function verifyResolvedOrder(intent: UserIntent, resolved: any): { ok: boolean; reason?: string } {13  const minOnDest = resolved.minReceived.find(14    (o: any) => o.chainId === intent.toChainId && o.token.toLowerCase() === intent.tokenOut.toLowerCase()15  );16  if (!minOnDest) return { ok: false, reason: "no output on intended destination" };17  if (BigInt(minOnDest.amount) < intent.minOut) {18    return { ok: false, reason: `min received ${minOnDest.amount} < user expected ${intent.minOut}` };19  }20  if (minOnDest.recipient.toLowerCase() !== intent.recipient.toLowerCase()) {21    return { ok: false, reason: "recipient mismatch" };22  }23  if (resolved.fillDeadline < intent.fillDeadline) {24    return { ok: false, reason: "deadline tighter than requested" };25  }26  return { ok: true };27}

백엔드Intent payment 상태머신 — solver default 까지 표현

결제 상태는 escrow 잡힘부터 fill verification, settle 완료, 그리고 solver default 처리까지 분리한다.

01type IntentStatus =02  | "Opened"            // origin settler 가 사용자 자금 escrow03  | "FillPending"       // solver 가 destination 채우는 중04  | "Filled"            // destination 출고 확인05  | "Settled"           // origin escrow 가 solver 에게 정산06  | "Expired"           // fillDeadline 경과, solver 미실행07  | "Refunded"          // 사용자에게 자금 반환 완료08  | "Disputed";         // fill claim 과 실제 destination 상태가 불일치0910const ALLOWED: Record<IntentStatus, IntentStatus[]> = {11  Opened:      ["FillPending", "Expired"],12  FillPending: ["Filled", "Expired", "Disputed"],13  Filled:      ["Settled", "Disputed"],14  Settled:     [],15  Expired:     ["Refunded"],16  Refunded:    [],17  Disputed:    ["Settled", "Refunded"]18};1920export function assertIntentTransition(from: IntentStatus, to: IntentStatus) {21  if (!ALLOWED[from].includes(to)) throw new Error(`Forbidden ${from} -> ${to}`);22}

강의 포인트

실무 예시

백엔드[CONTRACT] USDC checkout intent 상태머신

Solver 위험 분배표

흔한 오해와 실패 시나리오

실습 과제

1. 컨트랙트Intent order risk sheet 작성: order payload, resolver, solver, payment, deadline, revert policy, assumption, refund/cancel 조건을 표로 정리한다.
2. 백엔드USDC checkout intent 상태머신 설계: source order opened, destination paid, proof observed, origin settled, timeout, refund, dispute 상태를 포함한 USDC checkout intent 상태머신을 작성한다.
3. 운영Resolver vetting policy 만들기: 어떤 resolver를 solver/app이 신뢰할 수 있는지 audit, address allowlist, assumption validation, simulation, monitoring 기준을 정한다.

완료 기준

1. transaction, CCTP/bridge flow, intent/order execution의 차이를 설명했다.
2. ERC-7683의 order, solver, payload, resolver, assumption 개념을 checkout 설계에 연결했다.
3. solver 실패와 settlement dispute의 책임 분배를 표로 만들었다.
4. timeout/refund/dispute 상태를 포함한 payment state machine을 작성했다.

근거 자료

• Cross chain Intents ERC7683: 03-크로스체인-L2/06-Cross-chain-Intents-ERC7683.md
• ERC-7683: Cross Chain Intents: https://eips.ethereum.org/EIPS/eip-7683
• ERC-7683 FAQ: https://www.erc7683.org/faq
• ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
• EIP-7702: https://eips.ethereum.org/EIPS/eip-7702