6. 검증 상태와 로드맵

무엇이 어느 수준까지 검증되었는지를 증거 수준과 함께 기록한다. §2 증거표와 같은 규칙으로, 채굴된 것·fork에서 완주한 것·시뮬레이션으로 확인한 것을 같은 문장에 섞지 않는다.

• 위임 결제 파이프라인 — GIWA 채굴 — Framework 배포, owner account 배포, root 위임 서명(ERC-1271 검증), 정상 정산까지 GIWA에 채굴됨. 한도·만료 거절은 GIWA 현재 상태를 상대로 한 시뮬레이션이며 채굴된 트랜잭션이 아니다(§2 증거표)
• 에이전트 자동화 — GIWA 채굴 — MCP tool 한 번으로 사람 개입 없이 정산한 0x533c…9964c가 block 31634935에 채굴됐고 payer 가스 지출은 0이다
• 스폰서드 온보딩 — GIWA 채굴 — 배포 전 서명에서 복원한 owner로 계정 0x15286FE9…3301이 대납 배포되고(0xed21ac71…9902), 3 mUSDC가 민팅됐으며(0x9d14588b…baa0), 라이브 ERC-1271이 그 사전 서명에 0x1626ba7e를 답했다. 새 사용자의 가스 지출은 0. 서비스 자체의 검증은 GIWA fork 16케이스(test:e2e:bootstrap)
• negative-path 수트 — 일회용 체인·GIWA fork — negative-path-suite.ts가 동일한 케이스 집합(정상·주기 cap·주기 reset·만료·wrong-redeemer·수취인 불일치·replay·facilitator 변조 6종 + 대조군·payer mismatch·root 취소·회수 UserOp 4종·제출 엔드포인트 2종·manager 합산)을 일회용 체인과 GIWA fork 양쪽에서 체인 파라미터화로 실행하며, 각 케이스의 온체인 revert 사유까지 대조한다. 케이스 수는 수트가 스스로 세어 출력한다
• 회수 제출 엔드포인트 — GIWA fork + 라이브 1건 — 실제 GIWA 상태·배포 바이트코드를 고정한 fork에서 브라우저 CORS leg를 포함해 제출기 E2E와 EntryPoint 회수를 완주했고, 2026-08-04에는 공개 스폰서드 경로로 첫 라이브 회수가 GIWA에 채굴됐다 — 지갑(MetaMask) 승인 화면을 실제 사람이 통과한 건이기도 하다. 자력(핀 모드) 경로의 선예치는 여전히 소유자 몫으로 남아 있다
• 상시 게이트 — 로컬 + GIWA 읽기 전용 — 타입·테스트·문서·의존성 게이트를 묶은 bun run check 전체 통과. Framework는 실행 bytecode·결정 주소 38/38 재검증. 익스플로러 소스 검증은 39개(38유닛 + MockUSDC) 중 38이며, 유일한 미검증 유닛은 MetaMask SDK artifact/source 리비전 차이로 현재 소스와 일치하지 않고 Mapae 정책 경로에서 사용되지 않는다(세부 근거는 배포 컨트랙트)
• 공개 웹의 수치 규율 — 공개 웹(apps/web)이 표시하는 수치의 출처는 세 가지로 제한한다: 체인 직접 읽기, 채굴된 해시, negative-path 수트가 대조한 revert 사유

정산 원장·일일 가스 예산·동일 결제의 거래 해시 복구는 SQLite에 구현되어 있다. 거래 해시는 전송 전에 기록하며, 재시작 뒤 원래 영수증을 조회하고 성공은 한 번만 집계한다. 이는 로컬 회귀 테스트로 검증한 코드 상태이며 운영 배포 증거와는 별개다. 서명자 하나의 nonce·예산 처리를 위해 facilitator는 단일 프로세스로 운영한다.

정산 자동화의 트리거·스케줄러·실행 이력·재시도 정책은 apps/payment-scheduler에 구현되어 있다(§1): 간격 슬롯과 nextAt, payment_runs 이력과 runs 조회, maxAttempts·retryDelayMs, 그리고 자동 재시도하는 두 실패까지. 그 둘의 이유는 서로 다르다: TRANSPORT_ERROR는 결제 헤더가 프로세스를 떠나기 전에 끝난 연결 실패이고, SELLER_UNAVAILABLE은 헤더는 갔지만 판매자가 503으로 "아무것도 청구하지 않았다"고 답한 일시 불가다. 헤더가 나간 뒤에도 재시도가 안전한 것은 후자의 근거가 전송이 아니라 판매자의 답이기 때문이다. 결과가 미확정인 슬롯은 예약을 유지한 채 멈추고 자동 재개하지 않는다.

앞으로 만들 것:

• 작업 단위 복합 위임 — 여러 판매자·여러 리소스로 이루어진 한 작업을 위임 하나로 묶는 것. 지금은 결제마다 root 기간 위임에서 leaf를 하나씩 새로 서명하므로, 작업의 경계는 위임에 적혀 있지 않고 스케줄 작업 행에만 있다
• KYC·증명 검증 경로 — Dojang KYC 게이트 + EAS 계약/영수증 스키마 + 리졸버
• 이행검증 — optimistic 구조(기본 통과·이의제기 창·본드). 최종 판정자가 재실행이 아닌 중재이므로 trustless가 아님을 전제로 설계