ERC-3009: x402 결제를 가능하게 하는 프로토콜

Source: Dev.to

Introduction

x402의 결제 메커니즘 핵심에는 ERC‑3009가 있습니다. 이 표준은 암호화 서명을 통해 가스 없이 토큰 전송을 가능하게 합니다. 이 프로토콜을 이해하면 x402이 사용자가 가스용 네이티브 토큰을 보유하지 않아도 마찰 없는 결제를 구현하는 방식을 파악할 수 있습니다.

UX Problems with the ERC‑20 Approve/TransferFrom Pattern

• 두 개의 트랜잭션 필요: 먼저 approve, 그 다음 transferFrom.
• 두 번의 가스 비용: 사용자가 두 번 지불.
• 네이티브 토큰 의존: USDC를 이동하려면 반드시 ETH를 보유해야 함.
• 순차적인 논스: 트랜잭션 순서가 필요해 병목이 발생.

How ERC‑3009 Solves These Issues

온체인 승인이 아니라, 지불자는 오프체인 인증 메시지에 서명하고 이를 누구든지 제출할 수 있게 합니다.

function transferWithAuthorization(
    address from,
    address to,
    uint256 value,
    uint256 validAfter,
    uint256 validBefore,
    bytes32 nonce,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

function receiveWithAuthorization(
    address from,
    address to,
    uint256 value,
    uint256 validAfter,
    uint256 validBefore,
    bytes32 nonce,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

Workflow

1. 지불자는 EIP‑712 타입 데이터에 맞는 메시지에 서명합니다.
2. 메시지는 릴레이어나 퍼실리테이터에게(오프체인) 전달됩니다.
3. 릴레이어가 서명을 온체인에 제출합니다.
4. 계약이 서명을 검증하고 전송을 실행합니다.
5. 가스 비용은 지불자가 아닌 릴레이어가 부담합니다.

Random Nonces vs. Sequential Nonces

x402와 AI 에이전트에게는 큰 변화를 의미합니다: 에이전트가 충돌 없이 수천 개의 동시 결제 인증을 생성할 수 있습니다.

x402 Protocol Flow Using ERC‑3009

1. 클라이언트가 보호된 리소스를 요청합니다.
2. 서버가 결제 요구 사항을 담은 402 응답을 반환합니다.
3. 클라이언트가 ERC‑3009 인증 메시지를 만들고 지갑으로 서명합니다.
4. 클라이언트가 서명된 메시지를 포함한 X-PAYMENT 헤더와 함께 요청을 재시도합니다.
5. 퍼실리테이터가 서명을 검증합니다.
6. 서버가 요청한 콘텐츠를 반환합니다.
7. 퍼실리테이터가 transferWithAuthorization을 호출해 결제를 정산합니다.

Token Support

이 때문에 x402가 USDT보다 USDC에 집중하는 것입니다.

Feature Comparison: ERC‑2612 vs. ERC‑3009

Further Reading

• x402 Developer’s Guide – Build your first paid API
• x402 Facilitators – Understanding the settlement infrastructure
• Why x402 Doesn’t Support USDT – Token compatibility explained
• Solana’s Authorization Mechanism – The non‑EVM equivalent
• EIP‑3009 Specification
• EIP‑712: Typed Data Signing
• Circle’s USDC Implementation

ERC‑3009는 토큰 전송 방식을 혁신합니다. 인증을 오프체인으로 옮김으로써, x402가 가능하게 만든 가스 없는 마찰 없는 결제를 실현합니다.