ERC-8004 에이전트 활성 상태

실제 ERC-8004 "Trustless Agents" 신원 레지스트리(Base Sepolia 테스트넷)에 등록된 에이전트가 단순히 한 번 등록된 것에 그치지 않고 지금 이 순간 실제로 살아 있는지 확인합니다. NEXUS 후보 #10 -- 수동 빌드, FORGE 생성 아님, 후보 #3/#4/#6/#8/#9/#13/#16과 동일한 수동-Cloud-Run-자산 패턴을 따릅니다.

• POST /verify-registered-agent {"agent_id": 3} -- 회당 $0.10.

• /mcp의 MCP 도구 verify_registered_agent, 동일 파라미터 -- 현재 무료, "Known limitations" 참조.

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json(x-payment-info 포함), GET /.well-known/402index-verify.txt(402index 클레임 검증 파일).

이것이 무엇인가 (그리고 등록만으로는 충분하지 않은 이유)

ERC-8004는 온체인 에이전트 신원을 위한 실제 운용 중인 Ethereum 표준입니다. 에이전트는 IdentityRegistry에서 ERC-721 토큰을 발행하며, 그 tokenURI는 오프체인 등록 파일(JSON: name, description, 선언된 엔드포인트, active 플래그, 지원되는 신뢰 방식)을 가리킵니다. 이 표준은 2026-01-29에 Ethereum 메인넷에 라이브되었으며, Base 메인넷과 Base/Ethereum/Linea Sepolia 테스트넷에 참조 배포가 있습니다. 등록은 일회성 온체인 작업입니다. -- 실제 등록된 에이전트가 완전히 잠적해도(프로세스 종료, 도메인 만료, 엔드포인트 변경) 온체인 레코드는 영원히 변경되지 않고 유지됩니다. 이 자산은 그 공극을 메웁니다. 즉, 실제 온체인 등록을 확인하면서 동시에 등록이 선언하는 엔드포인트에 대해 호출 시점에 실제 MCP initialize 핸드셰이크를 수행합니다. 도메인으로 주장된 신원에 대해 agent-verification-api(후보 #3)가 이미 적용하고 있는 활성 여부-대-등록 구분을, 여기서는 온체인 등록 신원에 적용한 것입니다.

Related MCP server: agent-verification-api

근거(이번 세션에서 라이브로 검증, 단일 출처에서 추정하지 않음)

• 컨트랙트 주소, 처음에는 제3자 요약에서 가져왔지만, 신뢰하기 전에 https://sepolia.base.org의 eth_getCode로 독립 검증함: IdentityRegistry (0x8004A818BFB912233c491871b3d84c89A494BD9e)와 ReputationRegistry (0x8004B663056A597Dffe9e2cC1965A193B7388713) 모두 실제로 비어 있지 않은 배포 바이트코드를 보유.

• ABI, 참조 구현(github.com/erc-8004/erc-8004-contracts/abis)에서 가져와, 이 자산에 신뢰하기 전에 실제 등록된 에이전트 3개(agentId 1~3)를 라이브로 테스트함:

  • 에이전트 1의 tokenURI는 data:application/json;base64,... URI로 해석됩니다.

  • 에이전트 2의 tokenURI는 ipfs://bafkreiff...로 해석됩니다.

  • 에이전트 3의 tokenURI는 실제 https://api.snack.money/agent/.../registration.json URL로 해석됩니다. ERC-8004의 실제 URI 체계 3가지 모두 사양 예제가 보여주는 하나가 아니라 전부 라이브로 작동하는 것을 확인했습니다.

• getSummary는 비어 있지 않은 clientAddresses 배열을 요구합니다 -- 라이브 확인됨(그렇지 않으면 "clientAddresses required"로 reverts 됨). 이 자산은 먼저 getClients(agentId)를 호출하고, 그 결과가 하나 이상의 주소를 반환하는 경우에만 getSummary를 호출합니다. 따라서 피드백이 0인 에이전트는 RPC 오류 없이 feedback_count: 0으로 올바르게 보고됩니다.

• agentId=999999(실제로 존재하지 않는 토큰) 은 커스텀 에러로 정상적으로 리버트됨, 라이브 확인 -- 크래시가 아니라 AGENT_NOT_FOUND로 매핑됩니다.

MCP 핸드셉엔진: 재사용, 재구현 아님

작업 브리핑의 명시적 지침에 따라 _nexus_validate_public_url, _nexus_no_redirect_mcp_http_client, _mcp_handshake_check는 manual_assets/agent-verification-api/main.py(후보 #3)에서 그대로 이식되었습니다. -- 동일한 SSRF 사전 점검, 동일한 no-redirect 자수 (2026-08-22 보안 검토에서 리디렉션 기반 SSRF 우회를 발견한 후 그곳에 적용했던 정확한 수정), 동일한 제한된 타임아웃. 자산 이름 상수 외에는 수정하지 않았습니다. 이 자산의 고유 기여는 그 앞 단계입니다. 즉 ERC-8004 등록 파일을 해석(3가지 URI 체계)하고 그 endpoints 배열에서 실제 엔드포인트를 골라 그 엔진에 넘기는 것입니다.

체인 범위, 의도적

Base Sepolia 테스트넷뿐 -- 이 코드베이스의 다른 모든 x402 결제가 이미 사용하는 것과 동일한 네트워크입니다. ERC-8004는 Base 메인넷과 Ethereum 메인넷에서도 라이브 중이지만(이번 세션에서 라이브 확인), 이 자산은 호출자가 체인을 선택할 수 없게 했습니다. 7일 준칙 후보에게 메인넷이 필요하다는 증거가 없기 때문입니다(CLAUDE.md SS3).

배포 대상: Cloud Run

후보 #4/#3/#6/#8/#9/#13/#16과 동일한 파이프라인 -- skills/infra-deploy-ops 참조.

# 1. First deploy -- PUBLIC_DOMAIN not known yet, every real request 421s until step 2.
./scripts/deploy_cloud_run.sh erc8004-agent-liveness manual_assets/erc8004-agent-liveness

# 2. Grab the printed *.run.app URL, then (only if it differs from env-vars.deploy.yaml's guess):
gcloud run services update erc8004-agent-liveness --region us-central1 --project nexus-505016 \
    --update-env-vars PUBLIC_DOMAIN=<the-real-domain>

알려진 제한 사항(의도적으로 수정하지 않음 -- CLAUDE.md SS3, 필요하다는 증거 없이 게이트를 걸지 않음)

• MCP 도구 호출은 과금되지 않습니다. 이 코드베이스의 다른 모든 수동 자산과 동일한 프로세스 내 호출 패턴입니다.

• active: false는 엔드포인트가 실제로 살아 있더라도 REGISTERED_INACTIVE로 단락 처리됩니다. 그 한 가지 경우에는 독립적인 활성 상태 점검보다 등록자가 직접 한 자기 선언을 신뢰합니다. -- 비활성이라고 거짓 선언하는(비정상적인 인센티), 에이전트는 잘못 보고될 수 있습니다. 수용: active는 스펙 설계상 등록자 자신의 신호이며, 이를 덮어쓰는 것은 표준 자체 필드에 의문을 제기하는 것이겠습니다. REGISTERED_UNREACHABLE(반대의 실패 모드 -- 활성으로 announced but 실제로는 도달 불가)은 이 자산의 실제 가치이며, 이와 같이 단맞는 처리를 하지 않습니다.

  • 엔드포인트 선택은 휴리스틱이지 스펙 요구사항이 아닙니다. ERC-8004의 endpoints 배열은 자유 형식(임의의 name)입니다. 이 자산은 mcp/x402/a2a/web 순서로 우선하며, 첫 번째 항목으로 폴백합니다. 실제 MCP 가능 유일한 엔드포인트에 목록에 없는 name을 사용한 등록도 선택됩니다(이름 대응이 유일한 경로는 아님 -- 선호 이름이 없을 때의 폴백이 이를 커버합). 그러나 여러 엔드포인트가 있는데 우선 이름 중 아무것도 실제 살아있는 엔드포인트를 가리키지 않으면 잘못된 엔드포인트를 기반으로 REGISTERED_UNREACHABLE을 보고할 수 있습니다.

• IPFS 해석은 단일 공용 게이트웨이(ipfs.io)를 사용합니다. 폴백 게이트웨이가 없습니다. 해당 특정 게이트웨이를 통해 CID가 고정/도달 불가하면, IPFS 일반적으로는 콘텐츠가 존재해도 REGISTRATION_FETCH_FAILED를 보고합니다.

• 호출자별 속도 제한이 없습니다. 7일 일회용 측정 창으로는 충분합니다.

• reputation은 자체 보고된, 게이트 없는, 스테이킹 없는 신호입니다. 모든 EVM 주소는 임의의 agentId에 대해 ReputationRegistry.giveFeedback을 호출할 수 있습니다. feedback_count/average_value는 실제 온체인 숫자이지만, 에이전트 소유자가 자신을 Sybil 공급하는 것을 막을 수는 없습니다. 신뢰 점수가 아닌 미검증 신호로 처리하세요(이 경고는 API 스키마의 reputation 필드 설명에도 있으며, 여기뿐만이 아닙니다).

품질 게이트 (2026-08-23, 소급이 아닌 설계부터)

후보 #3/#4/#6/#8/#9/#13/#16과 동일한 2인 검토 프로세스(보안 렌즈, 기능+품질+구매자 경험 렌즈)를 최초 배포 전에 실행했습니다. 실제 발견 사항이며, 라이브 전에 모두 수정했습니다:

• 보안(악용 가능 발견 0건): agent-verification-api/main.py에서 그대로 이식한 3개 함수(_nexus_validate_public_url, _nexus_no_redirect_mcp_http_client, _mcp_handshake_check)가 실제 SSRF-redirect 수정을 바이트 단위로 포함하고 있고, 새 https:///IPFS 등록-가져오기 경로가 엔드포인트를 추출하기 전에 동일한 방어를 한 단계 더 앞서 적용한다는 것을 확인했습니다. 즉, 해당 버그 클래스를 재발시하지 않음을 확인했습니다. 낮음/정보성 항목 2가지는 모두 확인된 익스플로잇은 아니었지만 심층 방어로 처리되었습니다: IPFS CID 연결(라이브 확인으로 ipfs.io 호스트를 벗어날 수 없었지만, 그래도 urllib.parse.quote를 사용해 단일 경로 세그먼트로 제한함), data: URI base64 디코딩(선형/비증폭 확인, 수정 불필요).

• 기능/구매자 경험(1건 수정 필수, 1건 중간, 반영됨): 상위 레벨 JSON이 객체가 아닌(배열/문자열/숫자 -- 등록자가 제어하는 콘텐츠) 등록 파일이 "ok": True로 통과되었고 registration이 dict가 아닌데도 모든 하위 소비자(_pick_liveness_endpoint, _classify_verdict, 응답 본문)가 dict라고 가정했습니다. 잡지 못한 AttributeError가 x402 결제가 이미 완료된 후 처리되지 않은 500이 되었습니다. 수정: _resolve_registration_file의 두 JSON-parse 위치가 이제 "ok": True를 반환하기 전에 dict가 아닌 결과를 registration_not_an_object로 거부합니다. 또한 평판 게임 가능성 사항을 추가했습니다(위 "알려진 제한 사항" 및 reputation 필드의 스키마 설명 참조). 낮음/바람직한 항목 2개(중복 name 엔드포인트 섀도잉, 선택적 등록 키 2개의 필드 대/소문자 미검증)는 그대로 두었습니다 -- 아직 실제 등록에 영향을 미친다는 증거가 없으며, 이는 CLAUDE.md SS3과 일치합니다.

• 수정 전후에 실제 프로덕션 데이터로 엔드 투 엔드 검증 완료: Base Sepolia의 실제 ERC-8004 에이전트 ID 4개(1, 2, 3, 그리고 실제 존재하지 않는 999999)가 각각 올바른 판결을 냈습니다. -- REGISTERED_UNREACHABLE(실제 등록, 엔드포인트가 MCP에 응답하지 않음), REGISTRATION_FETCH_FAILED x2(실제 IPFS 게이트웨이 타임아웃과 실제로 죽은 https:// 등록 URL -- 둘 다 정당함, 버그 아님), AGENT_NOT_FOUND(실제 온체인 리버트) -- 또한 실제 평판 데이터(에이전트 1에 대해 12개 구별 클라이언트의 피드백 74건)를 가져왔습니다.

측정 (후보 #10, 7일 주기)

2026-08-23(실제 배포일)부터 7일 -> 결정 지점 2026-08-30. 신뢰 소스: traffic_events/revenue_events/mcp_call_events (asset_name = 'erc8004-agent-liveness'), Cloud Run 로그가 아닙니다. 7일째: 실제 트래픽이 없는 경우(크롤러 필터링 후), Cloud Run 서비스를 일시 중지/삭제합니다 (gcloud run services delete erc8004-agent-liveness --region us-central1 --project nexus-505016).