저는 콜롬비아 보고타에 거주하는 1인 개발자입니다. 이번 주 GitHub 이슈에서 일어난 일은 문서화할 가치가 있다고 생각합니다. 왜냐하면 이것이 '신뢰 없는 검증(trustless verification)'이 실제로 어떤 모습인지 보여주기 때문입니다. 백서 버전이 아니라, 버그가 발견되고 공개적으로 수정되는 실제 모습 말이죠.

설정

저는 자율 에이전트를 위한 LATAM 컴플라이언스 데이터 API인 VeraData를 구축했습니다. 제재 심사(OFAC + UN + EU + UK, 59,000개 이상의 항목), 공식 등록부 기반의 KYB(RUES Colombia, CNPJ Brazil, RFC Mexico), 중앙은행 금리 등이 포함됩니다. 모든 것은 x402를 통해 호출당 과금됩니다: 에이전트가 엔드포인트에 접속하여 402 응답을 받고, Base 또는 Solana에서 USDC 마이크로 결제를 서명한 후 데이터를 받습니다. API 키나 계정은 필요 없습니다.

모든 심사 응답에는 AAT 블록이 포함됩니다 — 이는 SHA-256 해시 체인(query_hash → event_hash → chain_hash)으로, EU AI Act Art.12 감사 증거로 설계되었습니다.

저는 x402-foundation/x402에 이 문제를 열고 컴플라이언스 사용 사례로 제시했습니다. 그 이후에 일어난 일은 리스팅보다 더 좋았습니다.

감사

독립 검증자(babyblueviper1, ERC-8299/WYRIWE 참조 구현을 구축하는 사람)는 제 문서를 단순히 읽기만 하지 않았습니다. 그들은 /sanctions에 대한 라이브 호출을 실행하고, AAT 블록을 분해했으며, 모든 해시를 독립적으로 재계산했습니다.

그들이 공개적으로 발견한 것은 다음과 같습니다:

제 사양의 미묘한 모호함이었습니다. 제 재계산 지침에는 SHA256(query_hash + "|" + ...)라고 되어 있었지만, 해시 값이 자체적인 sha256 접두사로 다음 해시에 포함된다는 점을 명시하지 않았습니다. 그들은 먼저 순수한 16진수(bare hex)를 시도했고 불일치를 발견했으며, 오직 접두사를 사용했을 때만 일치했습니다. 다른 어떤 재계산자라도 같은 방식으로 조용히 실패했을 것입니다. 이 내용은 이제 공개적인 준수 테스트 케이스에서 핵심적인 세부 사항으로 문서화되었습니다.

정직한 간극 (The honest gap). chain_stored: true는 해당 항목이 내 데이터베이스에 존재함을 증명하지만, 그것이 언제 기록되었는지는 증명하지 못합니다. 이것이 바로 감사인(auditor)이 가장 먼저 던지는 질문입니다: "이 기록이 사후에 생성되었을 가능성이 있는가?" 해시 체인 (hash chain)은 데이터를 보유한 누구에 의해서든 통째로 재생성될 수 있습니다. 해결책(독립적인 서명 (independent signatures) + Bitcoin OTS 시간적 앵커링 (temporal anchoring))은 실재하지만 아직 구축되지 않았습니다. 그래서 우리는 이를 은폐하는 대신 공개적으로 명시했습니다.

누락된 matches: [] 필드. CLEAN 결과에서 나는 matches 배열을 생략했습니다. 그들의 결정론적 검사 (deterministic check)는 이를 포착했습니다: "확인 결과 아무것도 발견되지 않음"은 "필드가 채워지지 않음"과 구조적으로 다릅니다. 같은 날 수정되었으며, 커밋 (commit)은 스레드에 링크되어 있습니다.

감사가 정직함을 강제했기에, 내 측에서 발견한 사실은 다음과 같습니다:
내 마케팅 자료에는 제재 스크리닝 (sanctions screening)이 SARLAFT (콜롬비아), CNBV (멕시코), COAF (브라질) 지역 리스트를 포함한다고 되어 있었습니다. 하지만 라이브 호출 결과가 lists_checked: ["OFAC_SDN", "UN_CONSOLIDATED"]를 반환했을 때, 나는 직시해야 했습니다: 해당 지역 리스트들은 공개적으로 다운로드할 수 없으며, 규제 대상 금융 기관으로 제한되어 있다는 사실을 말입니다. 내 문구는 실행 중인 범위를 과장했습니다.

그래서 그들이 찾아내기 전에 스레드에서 사실대로 말했습니다. 그러고 나서 유령 리스트들을 실제 리스트인 EU Consolidated (29,759개 항목)와 UK HM Treasury (9,605개 항목)로 교체했으며, 같은 날 시딩 (seeding) 및 라이브 적용을 완료했습니다. 이제 스택 (stack)은 정직합니다: OFAC + UN + EU + UK.

결과
내 라이브 유료 엔드포인트 (endpoint)에 대한 두 번의 실제 /review 호출과 두 개의 공개된 decision_ref 증명:
verdict: approve
confidence: 0.95
decision_ref: sha256:3eeb2c6c6e0f5c90c8c9823e593791cfb56a2774611a1bca9c3a5eda1ced39b6
source_class: agent_reported

이제 sanctions_screening은 그들의 ERC-8299 구현에서 일급 객체인 artifact_type입니다. 이 교환 과정이 동기부여가 되어 배포되었습니다. 나의 피스처 (fixture)는 그들의 준수 (conformance) 리포지토리 (repo)에서 테스트 케이스로 사용됩니다. 누구나 python3 check_chain.py를 실행하여 선언된 입력값으로부터 의존성 없이 전체 체인을 검증할 수 있습니다.

내가 영원히 훔치고 싶은, 그들이 설정한 기준 (bar)의 프레임워크는 다음과 같습니다:

"무언가 잘못된 것이 없었다는 뜻이 아니라, 잘못된 모든 것이 발견되었고, 공개적으로 발설되었으며, 같은 날 양측 모두에 의해 수정되었다는 뜻입니다."

내 API를 넘어 이것이 중요한 이유
현재 x402 생태계는 월간 거래량 약 $1.1M / 3.7M 건의 트랜잭션을 기록하고 있습니다. 승리하고 있는 카테고리는 기계 판독 가능 데이터 (machine-readable data)와 게이트웨이 (gateways)입니다. 하지만 신뢰의 문제가 있습니다. 에이전트 (agent)가 컴플라이언스 판결이 조작되지 않았음을 어떻게 알 수 있을까요? "나를 믿으세요"라는 말은 회의적인 감사인 (auditor) 앞에서는 살아남지 못합니다.

부상하고 있는 해답은 재계산 가능한 증거 (recomputable evidence) + 독립적 증명 (independent attestation)입니다. 귀하의 엔드포인트 (endpoint)는 결정론적 체인 (deterministic chain)을 생성합니다. 독립적인 당사자가 그 위에 서명합니다. 귀하와 상대방 중 누구도 믿지 않는 제3자가 양쪽 모두를 검증할 수 있습니다. 이것이 우리가 이번 주에 루프를 완성한 내용입니다. 제가 알기로는 x402 상의 컴플라이언스 API에 대해 문서화된 첫 번째 사례입니다.

직접 시도해보세요
에이전트는 지금 바로 무료로 엔티티 (entity)를 스크리닝할 수 있습니다 (엔드포인트당 일일 5회의 체험 호출 제공):

curl -X POST https://api.veradata.dev/sanctions/quick \
-H "Content-Type: application/json" \
-H "X-TRIAL: true" \
-d '{"name": "ACME Corp", "country": "CO", "type": "company"}'

또는 Claude Code / Codex / Cursor에 스킬을 설치하세요:

npx skills add teodorofodocrispin-cmyk/veradata-skills --skill veradata-latam-compliance

모든 해시 (hashes), 수정 사항, 그리고 증명 (proofs)이 포함된 전체 스레드: x402-foundation/x402#2749