인텐트와 솔버 정산 모델

도입

Intent는 사용자가 실행 방법이 아니라 원하는 결과를 서명하는 방식이다. "Base에서 merchant에게 100 USDC를 지급하고 싶다"는 결과와 제약 조건을 표현하면 solver가 route, bridge, swap, gas를 선택할 수 있다. UX는 단순해지지만 위험이 사라지는 것은 아니다. 위험은 solver 선택, deadline, refund, settlement proof로 이동한다.

ERC-7683 같은 cross-chain intent 표준화 논의는 중요한 학습 재료지만, 강의에서는 status를 항상 확인해야 한다. 표준이 draft라면 "이미 확정된 표준"이라고 쓰지 않는다. 대신 mechanism을 배우고, adoption이나 volume은 날짜와 출처를 붙이는 대상으로 둔다.

학습 목표

• intent를 사용자가 원하는 결과와 제약 조건을 서명한 주문으로 설명한다.
• solver, filler, escrow, deadline, replay protection이 settlement risk를 어떻게 나누는지 이해한다.
• ERC-7683을 확정 표준이 아니라 draft mechanism으로 보수적으로 다룬다.

개념 설명

코드로 확인하기

01export type IntentOrder = {02  maker: `0x${string}`;03  inputToken: `0x${string}`;04  outputToken: `0x${string}`;05  amountIn: bigint;06  minAmountOut: bigint;07  destinationChainId: number;08  receiver: `0x${string}`;09  deadline: number;10  nonce: `0x${string}`;11};

01export function validateIntent(order: IntentOrder, now: number) {02  if (now > order.deadline) throw new Error("intent expired");03  if (order.minAmountOut <= 0n) throw new Error("missing output constraint");04  if (order.destinationChainId <= 0) throw new Error("invalid destination");05  return { ok: true, settlementKey: `${order.maker}:${order.nonce}` };06}

코드는 intent를 swap instruction이 아니라 settlement contract가 검증할 수 있는 typed data로 본다. 실제 구현에서는 EIP-712 domain, chain binding, permit, escrow, proof verification이 추가된다.

강의 포인트

실무 예시

백엔드[CONTRACT] cross-chain checkout에서 사용자는 "어느 bridge를 쓸지"를 모를 수 있다. intent model은 이 복잡성을 solver에게 넘긴다. 그러나 solver가 destination에서 merchant에게 먼저 지급하고 origin settlement가 실패하면 누가 손실을 부담하는지 정해야 한다.

좋은 product state는 "결제 중" 하나가 아니다. Signed, Filled, ProofSubmitted, Settled, Refunded가 분리되어야 support와 reconciliation이 같은 증거를 볼 수 있다.

흔한 오해와 실패 시나리오

실습 과제

1. Intent order 타입 정의하기: maker, inputToken, outputToken, minAmountOut, destination, deadline, nonce를 가진 typed order를 정의한다.
2. Solver 실패 상태표 만들기: fill, timeout, refund, dispute, settlement failure 상태와 사용자 문구를 작성한다.

완료 기준

1. intent order의 maker, input, output, deadline, nonce, settlement proof 필드를 정의했다.
2. solver가 destination에서 먼저 지급하고 origin에서 나중에 정산받는 실패 상태를 작성했다.

근거 자료

• 08 Trends 2026
• ERC-7683
• UniswapX Overview