첫째, verify가 nonce 소비나 자금 예약 없는 stateless 검사, 사실상 prediction에 그친다는 점
- 카드 결제의 authorization이 자금을 실제로 묶는 상태 변경인 반면, x402의 verify는 "settle 시점에도 유효할 것"이라는 예측일 뿐 보증이 아니므로 취약점 생길 가능성 농후
둘째, 소비자와 머천트를 동시에 보호하려다 보니 verify - execute - settle이라는 분리 구조가 나옴.
- 온체인 정산은 되돌릴 수 없으므로 business logic이 성공한 뒤에만 정산해야 하는데, 이 순서가 verify와 settle 사이에 어느 당사자도 책임지지 않는 상태 구간을 만든다.
셋째, gas와 rent 부담을 facilitator에게 이전함.
- 지갑에 native token이 없는 에이전트도 결제하게 하려는 선택인데, 그 순간 공격자 통제 입력이 facilitator 비용으로 직결
낙관적으로 보면, Cloudflare Monetization Gateway처럼 검증된 빅테크의 수직 통합 모델에서는 이 문제들이 그렇게 큰 문제를 야기하지는 않는데:
- 게이트웨이가 reverse proxy로 앉아 있어 origin이 리소스를 만들어놓아도 정산이 확정될 때까지 응답을 반출하지 않으면 되고(release를 settle 뒤로 미루는 것)
- gas와 rent도 자신이 fee payer라 통제 가능
다만 이건 취약점을 제거한 것이 아니라 다수의 분산된 구현 버그를 소수의 집중된 신뢰 가정으로 치환한 것에 가깝기 때문에...