01요약

x402로 에이전트가 스스로 결제하는 경로는 이미 열렸다. 막힌 것은 권한을 넘기는 방법이다. 지금 선택지는 개인키를 통째로 주거나(한도·수취인·기한을 걸 수 없다) 수탁 서비스를 믿는 것 둘뿐이다.

마패는 세 번째 길이다. 위임 메커니즘 자체는 발명하지 않았다 — ERC-7710/7715와 x402를 채택하고, 어디에도 없던 조건 하나를 기여한다: 위임자의 신원.

02문제

에이전트에게 결제를 맡기는 현재의 방법은 둘 다 같은 결함을 공유한다. 범위가 없다. 개인키를 넘기면 에이전트가 곧 지갑이 되고, 수탁에 맡기면 온체인 결제를 하려고 다시 중개인을 세우는 셈이다.

그리고 한도만으로는 부족하다. 사고가 났을 때 누가 이 권한을 줬는지가 남지 않으면 책임 주체를 특정할 수 없고, 가맹점은 에이전트 결제를 받을 이유가 없다. 이 마지막 조각이 기와에만 있다 — 다른 체인에는 조건으로 걸 신원 자체가 없다.

03아키텍처

04신원과 자금의 분리

도장은 컨트랙트에 붙지 않는다. 거래소는 KYC를 통과한 사람의 지갑 주소에 발급하지, 방금 배포된 컨트랙트에 발급하지 않는다. 그래서 위임자 주소를 그대로 검증하도록 설계하면 프로덕션에서 도장이 없고, 데모는 자기 발급 attestation으로만 통과한다 — 논지가 무너진다.

그래서 주소를 둘로 나눴다. 자금과 위임 상태는 계정이, 신원은 그 계정의 소유자인 사람이 가진다. 조건은 계정이 아니라 owner를 평가한다.

이 분리는 위조 경로를 하나 연다. 아무나 컨트랙트를 배포해 owner()가 남의 검증된 주소를 가리키게 만들 수 있다 — 훔치는 것은 없지만 책임 사슬을 위조하는 것이며, 그 사슬이 이 시스템이 보증하는 전부다. 두 겹으로 막는다.

부수 효과로 리스크 하나가 소멸한다 — 소유자 EOA가 도장을 직접 발급받으므로 "컨트랙트가 attestation을 받을 수 있는가"라는 가정 자체가 불필요해진다.

05결제가 지나는 경로

06조건 — 무엇을 서명하나

조건은 {enforcer, terms, args}다. terms는 위임자가 서명하고, args는 사용 시점에 사용자가 낸다. 위임 해시는 signature와 args를 제외하고 계산되므로, 사용자가 낸 값이 서명을 바꿀 수 없다.

terms는 전부 고정 오프셋으로 tightly-pack되며, 길이가 틀리면 잘라내는 게 아니라 revert한다. 조건들은 논리곱이다 — 한도의 마지막 1원까지 쓸 수 있고, 1원도 넘을 수 없다.

07기여물 — 신원 조건

배포된 위임 프레임워크들은 거의 모든 지출 조건을 이미 표현한다. 금액·기간·스트리밍· 타겟·메서드·calldata·시간 범위·호출 횟수. MetaMask 프레임워크 하나만 해도 감사된 조건이 38종이다.

그중 위임을 신원에 걸리게 하는 것은 없다 — 어떤 배포된 프레임워크에도, 어떤 체인에도. 조건으로 걸 온체인 신원이 없었기 때문이다.

설계 결정 넷

이 컨트랙트는 무상태이고 실행 calldata를 파싱하지 않는다. 그래서 어떤 호출 형태와도 조합되고, 훅을 직접 불러 오염시킬 회계도 없다.

두 번째 빈칸 — 수취인 조건

작업 중에 격차가 하나 더 드러났다. 타겟 allowlist는 토큰 컨트랙트를 검사하는데, ERC-20 결제의 실제 수취인은 calldata 바이트 [4:36]에 있고 배포된 것 중 이걸 보는 게 없다. AllowedPayeeEnforcer가 "이 가맹점들에만 지불 가능"을 표현 가능하게 만든다.

08킬스위치 — 2×2 직교

두 개의 독립적인 스위치가 있고, 각각 되돌릴 수 있다.

각 축을 다른 축이 온전한 상태에서 시험했다. 도장이 살아 있는 채로 위임만 끄고, 위임이 켜진 채로 도장만 취소한다. 그래서 결과가 매니저의 체크 순서라는 가정에 의존하지 않는다. 되돌리는 것도 각각 증명했다 — 다시 켜면 쓰던 한도 그대로 재개되지, 리셋되지 않는다.

09재위임 — 좁히기만 가능

재위임은 ERC-7710의 일급 연산이다. 에이전트가 자기 권한의 일부를 다른 에이전트에게 넘길 수 있다. 사슬의 모든 링크의 조건이 평가되므로, 자식은 받은 것을 좁힐 수만 있고 넓힐 수 없다.

뿌리를 비활성화하면 상위에서 존재를 모르는 하위 에이전트까지 함께 정지한다. 이 성질을 지키는 것이 사슬 테스트 스위트의 존재 이유다.

10x402 정산

x402 v2의 exact 스킴은 EVM에서 세 가지 자산 이전 방식을 정의한다. 그중 둘은 토큰 레이어에서 승인하며, 그 승인은 nonce 한 번으로 소진된다. 세 번째 erc7710은 위임 매니저를 시뮬레이션해서 검증하며, 하나의 승인으로 여러 번 정산할 수 있는 유일한 방식이다.

마패는 이 세 번째 방식을 구현한다. 정산자는 정책도 자금도 갖지 않는다 — 모든 한도·수취인·기한·신원 검사가 온체인에서 돌고, 정산자의 키는 가스만 낸다. 이것은 우회가 아니라 설계 목표다. 정책 판정이 전부 온체인에 있으므로 정산자는 정책을 알 필요가 없고, 알 수도 없다.

GIWA에는 EIP-3009 토큰이 없어 다른 두 방식은 애초에 불가능하다. 라이브 증명에서는 같은 서명 payload로 정산이 두 번 일어나고, 세 번째는 브로드캐스트 전에 거부된다.

11에이전트 연동

npx mapae-mcp. MCP는 AI 에이전트에 외부 도구를 꽂는 표준 규격이고, 마패는 이 규격의 서버로 npm에 배포되어 있다. 클로드 코드·코덱스 같은 에이전트에 설치 한 줄이면 붙고, 그다음부터는 전부 자연어다.

12제품

익스플로러는 정적 SPA다. 서버가 없다 — 브라우저가 GIWA를 직접 읽는다. 세 화면이 있다.

블록 익스플로러와 다른 점 둘. 거부가 일급이다 — 거부된 결제에는 로그가 없으므로 위임을 calldata에서 복원하고, 블록 직전 상태에 재생해 거부 사유를 되살린다. 그리고 시제가 정직하다 — 당시엔 유효했던 결제는 두 사실을 다 보여준다. 게이트 이벤트가 증명하는 그때의 유효함과, 라이브 조회가 말하는 지금의 취소됨.

13검증

테스트 153개 전부 통과. 층위별로 무엇을 증명하는지가 개수보다 중요하다.

검증이 실제로 잡은 버그

• 모드워드 패킹 오류가 실행 형태 가드 둘을 조용히 무력화하고 있었다. all-zero 테스트가 공허하게 통과하는 동안 숨어 있다가 비-zero 왕복에 걸렸다.
• 빌드 설정 하나가 아무것도 브로드캐스트하지 않으면서 배포 성공을 보고했다. 체인에서 코드를 되읽어 발견했다.
• 계정 생성 서명이 잘 만들어졌는데 온체인에서 거부됐다. 팩토리의 EIP-712 다이제스트가 아니라 EIP-191로 서명하고 있었다.

14만들지 않은 것

15신뢰 가정과 위협 모델

이 시스템이 무엇을 신뢰하고 무엇을 신뢰하지 않는지를 명시한다. 신뢰 경계를 적지 않은 보안 주장은 검증할 수 없다.

신뢰하는 것

신뢰하지 않는 것

알려진 한계

• 발급 시점의 신원은 보증하지 않는다. 조건은 결제 순간의 liveness를 읽을 뿐, 거래소가 잘못 발급한 attestation을 걸러내지 못한다. 이는 도장 계층의 책임이다.
• 가스는 에이전트가 낸다. 잔액이 떨어지면 결제가 실패한다. 대납(paymaster)은 기와에 번들러 인프라가 서면 검토한다.
• 공개 RPC의 읽기 일관성. 로드밸런싱된 엔드포인트가 서로 다른 높이의 상태를 반환할 수 있다. 강제는 온체인이라 안전에는 영향이 없지만, 조회 UI는 재시도로 대응한다.

16배포 주소

GIWA Sepolia (91342). 전부 소스 검증되어 있다.

17다음

18참고 표준