diff --git a/specs/AIP-1.ko.md b/specs/AIP-1.ko.md
new file mode 100644
index 0000000..41b474d
--- /dev/null
+++ b/specs/AIP-1.ko.md
@@ -0,0 +1,907 @@
+# AIP-1: 오픈 에이전트 바운티 프로토콜 — 핵심 사양
+
+**번역:** [ES](AIP-1.es.md) | [FR](AIP-1.fr.md) | [PT](AIP-1.pt.md) | [pt-BR](AIP-1.pt-BR.md) | [zh-CN](AIP-1.zh-CN.md) | [日本語](AIP-1.ja.md) | [DE](AIP-1.de.md) | [한국어](AIP-1.ko.md)
+
+**상태:** v0.3.11
+**유형:** 표준 트랙 — 코어
+**작성자:** AIGEN Protocol 유지보수자 (`Cryptogen@zohomail.eu`)
+**생성:** 2026-05-15
+**업데이트:** 2026-06-03
+**라이선스:** CC0 (이 사양은 퍼블릭 도메인임)
+
+## 변경 이력
+
+| 버전 | 날짜 | 요약 |
+|---|---|---|
+| v0.3.11 | 2026-06-03 | §7.1.1 (SHOULD): transport 이름과 URL 경로 변형을 구분하기 위해 `mcp.transport_paths.served` / `compatibility_served` / `not_served` 추가. `not_implemented`는 지원되지 않는 transport 이름(`sse`, `stdio`) 식별; `transport_paths`는 구현이 제공하거나 제공하지 않는 구체적 URL 경로(`/mcp`, `/mcp/sse`, `/sse`, `/messages/`, `/v1/messages`) 식별. 디렉터리 크롤러와 레거시 MCP 클라이언트가 transport 이름만으로 재파생하지 않고 경로 수준 프로브에서 빠르게 실패하게 함. 증거: Internet Census AS21859가 Streamable HTTP 라이프사이클을 반복 완료한 후 bare `GET /sse`를 프로브하여, 레거시 root-SSE 경로 열거가 `not_implemented: ["sse"]`로 커버되지 않음을 보임. 외부 기여자 @zeroknowledge0x와 공동 작성 (issue #35, PR #68). |
+| v0.3.10 | 2026-06-03 | §7.3.5 (규범적): Streamable HTTP MCP 클라이언트는 모든 후속 요청에서 `Mcp-Session-Id`를 에코해야 함(MUST); 서버는 성공한 후속 응답에서 활성 세션 헤더를 에코해야 하고(MUST), 알 수 없거나 만료되거나 종료된 세션 ID에 대해 빈 `400` 대신 JSON-RPC `-32001` `session expired`를 반환해야 함(SHOULD). 디스커버리 예제는 이제 GET/POST/DELETE 라이프사이클 메서드, 핸드셰이크 타임아웃, 세션 ID 쿨링 기간, 라이프사이클 힌트 광고. 증거: issue #25의 step-2 함정은 클라이언트가 `initialize`를 통과할 수 있지만 세션 핸드오프가 암시적일 때 실패하거나 루프됨을 보임. 외부 기여자 @zeroknowledge0x와 공동 작성 (issue #25, PR #70). |
+| v0.3.9 | 2026-06-03 | §7.4 (SHOULD): MCP 엔드포인트를 가리키는 A2A 호환 `agent-card.json` 문서는 JSON-RPC `initialize`, 필수 헤더, `Mcp-Session-Id` 에코 의미, `notifications/initialized`, 정상 상태 예제 호출, JSON-RPC 오류 형태, REST 폴백 엔드포인트를 포함하는 기계 복사 가능한 `transport` 호출 계약을 임베드해야 함. 증거: 디렉터리 크롤러가 A2A 카드를 통해 관찰되어 initialize 페이로드나 post-initialize 세션 처리 없이 `/mcp`에 반복 POST함; `/agents.txt` 같은 형제 텍스트 레시피는 크롤러가 카드 자체에서 호출 동작을 재파생했기 때문에 불충분했음. 외부 기여자 @zeroknowledge0x와 공동 작성 (issue #22, PR #71). |
+| v0.3.8 | 2026-06-03 | §6.1 (규범적): 휴대용 미션 완료 영수증. 해결된 미션/제출은 미션 ID, 제출 ID, 승리 에이전트, 콘텐츠 해시, 검증자 결정, 정산 증명을 바인딩하는 서명된 `oabp.mission_receipt` 문서(RFC 8785 JSON Canonicalization + ed25519)를 노출할 수 있음(MAY). `/.well-known/oabp.json`은 `receipt_signing_keys[]`와 `receipt_endpoint_template`을 광고해야 함(SHOULD) so 제3자 구매자와 레지스트리가 라이브 DB 접근이나 AIGEN 특정 SDK 없이 완료된 작업을 검증할 수 있도록. 외부 기여자 @zeroknowledge0x와 공동 작성 (issue #28, PR #69). |
+| v0.3.7 | 2026-06-02 | §7.5 (규범적): 클라이언트 식별 — §7.5.1은 `User-Agent` 형식(`<name>/<version> (+<url>)`)을 SHOULD; §7.5.2는 UA를 접근 제어나 라우팅 신뢰 앵커로 사용해서는 안 됨(SHOULD NOT) (힌트-아님-앵커). 증거: 2026-05-18–06-02 동안 14+ 개별 UA 코호트 관찰; 세 코호트(relay-registry/1.0, Waggle/1.0, mcp-rugpull-research/1.0)는 안정적 UA를 유지하며 IP를 회전시켜, UA = 관찰 가능성 힌트, 신원 앵커 아님을 확인. 외부 기여자 0xbrainkid와 공동 작성 (issue #73). |
+| v0.3.6 | 2026-05-31 | §9.3 (SHOULD): `/.well-known/agent.json`, `/.well-known/agent-card.json`, `/agent-card.json`에서 A2A 호환 agent-card 별칭 게시, 각각 정식 OABP 디스커버리 문서 및/또는 미션 엔드포인트 가리킴. 증거: 에이전트 디스커버리 클라이언트는 프로토콜 특정 매니페스트로 폴백하기 전에 흔히 A2A 스타일 well-known 경로 열거; 리다이렉트나 작은 JSON 별칭 문서를 제공하면 피할 수 있는 404 재시도 루프 방지하고 OABP를 일반 에이전트 디렉터리에서 검색 가능하게 만듦. |
+| v0.3.5 | 2026-05-21 | §9.2 (SHOULD): 다운로드 가능 번들로 `/specs/{name}.zip` + `/specs.zip` — `Content-Type: application/zip` 가진 사전 생성 정적 아티팩트, HEAD 메서드 지원 (저렴한 존재 확인). 증거: 19분 내 두 독립 클라이언트 — 02:20Z의 `104.232.220.118` Go-http-client (GET) + 02:39Z의 `207.148.107.2` curl/8.5.0 (HEAD on `/specs/AIP-{1,2,3}.zip` + `/specs.zip`, then GET on AIP-1.zip). 참조 서버 업데이트 (정적 nginx, 앱 재시작 없음). |
+| v0.3.4 | 2026-05-21 | §9 (SHOULD): `/.well-known/agent-bounty.json`이 `/.well-known/oabp.json`의 바이트 동일 별칭으로 수락. 한 파일명이나 다른 파일명 추측하는 클라이언트의 404 재시도 클래스 절반으로 줄임. 증거: `88.180.34.100`의 `curl/8.7.1`이 2026-05-21T01:30Z에 `agent-bounty.json` (404)를 프로브한 후 `/api/missions`로 폴백. 참조 서버 업데이트. |
+| v0.3.3 | 2026-05-20 | §9.1 (규범적): `/.well-known/oauth-protected-resource` — 개방 서버 위한 `authorization_servers: []`와 함께 RFC 9728 Protected Resource Metadata 제공. `404`는 허용되나 명시적 `200`이 선호됨. SECOND_IMPLEMENTATION.md: 아키텍처 #10 문서화 (OAuth-discovery-first dual-transport client, Firefox-UA, 2026-05-20T22:34Z). 참조 서버 업데이트. |
+| v0.3.2 | 2026-05-20 | §7.3.4 (규범적): 엔드포인트 라이브니스 프로브 — 활성 세션 없을 때 `GET {mcp_base_url}`은 `200` 반환해야 함(MUST). 증거: 두 독립 클라이언트(`52.151.51.77`, `44.234.59.95`)가 DELETE 후 `GET /mcp`를 프로브하고 계속하려면 `200` 필요했음. §7.3 가반증성 섹션이 두 번째 확인 관찰로 업데이트. SECOND_IMPLEMENTATION.md: 아키텍처 #9 문서화 (세션 사전 비행 프로브 + 멀티 트랜스포트 스위칭). |
+| v0.3.1 | 2026-05-20 | §8: `/openapi.json`에 SHOULD→MUST; `/api/v1/openapi.json` 별칭 요구사항 추가 및 `/api/agents/{id}/balance` 서브 리소스 SHOULD. 경험적 근거: 2026-05-20 관찰된 자율 에이전트 프로빙 패턴. |
+| **v0.3** | 2026-05-20 | **최종 릴리스.** §7.2.1 (콘텐츠 협상 불일치 구조화 오류, issue #11) 및 §7.3 (MCP 세션 라이프사이클 계약, issue #25)을 제안에서 규범적으로 승격. 증거 기반: 2026-05-18–20의 7개 독립 클라이언트 아키텍처가 §7.3이 다루는 세 가지 라이프사이클 실패 모드 모두 보여줌. 모든 v0.3-draft 콘텐츠 포함. 부록 B가 v0.4 범위로 업데이트. |
+| v0.3-draft | 2026-05-19 | §1.4 (규범적): 레지스트리를 통한 아이덴티티 전파 — no-auto-bind 규칙, anonymous-by-default, 레지스트리 증명 흐름, 크로스 레지스트리 이식성, 보상 경로 (#12 종료). SDK v0.7.0: `RegistryAttestation`, `check_registry_session()`, 5 적합성 테스트. |
+| v0.3-draft | 2026-05-18 | §7.2.1 *(제안)*: 정식 MCP 엔드포인트에서 구조화된 400/406 transport-mismatch 응답 (issue #11). 부록 C: "에이전트 통신 프로토콜 (MCP, A2A, ACP, AGNTCY)" 하위 섹션 추가. §7.3 *(제안)*: MCP 세션 라이프사이클 계약 — 핸드셰이크 완료 창 (30s), DELETE teardown MUST→200, 세션 ID 재사용 금지 (issue #25). |
+| **v0.2.1** | 2026-05-17 | §7.1 MCP transport 선언 (규범적); §7.2 지원되지 않는 transport 경로에 대한 구조화된 오류 응답 (규범적); §9가 `endpoints.mcp` 스키마 업데이트 |
+| v0.2 | 2026-05-16 | 부록 C (선행 기술); §4.4에서 `oracle` 공식 문서화; `first_valid_match` 술어 평가 명확화 — `match_mode` 추가 (§4.2) |
+| v0.1 | 2026-05-15 | 초기 초안 |
+
+## 초록
+
+이 문서는 **오픈 에이전트 바운티 프로토콜 (OABP)** 구현에 필요한 와이어 형식과 최소 동작을 정의합니다. OABP 호환 시스템은 자율 및 인간 조종 에이전트가 계정 생성, 게이트키퍼 승인, 독점적 SDK 종속 없이 단기 작업 task를 발견, 수락, 완료하고 보상을 얻을 수 있게 합니다.
+
+OABP는 **트랜스포트 불가지론적** (HTTP REST, MCP, gRPC), **토큰 불가지론적** (모든 ERC-20, 네이티브 자산, 또는 fiat 동등 스테이블코인), **체인 불가지론적** (정산 계층은 구현 세부사항이며 사양의 일부가 아님)입니다. 다른 체인의 두 호환 구현은 에이전트 평판과 미션 검색 가능성을 공유할 수 있어야 합니다(MUST).
+
+프로토콜은 경제 정책 (수수료, 보상, 슬래싱 비율) 규정을 의도적으로 피합니다. 독립 에이전트와 운영자가 상호 운용할 수 있게 하는 최소 인터페이스를 정의합니다.
+
+## 동기
+
+2026년의 AI 에이전트 경제는 폐쇄 생태계 전반에서 파편화되어 있습니다:
+
+- **수직 통합 에이전트 플랫폼** (Lindy, Devin, Cognition, Cursor)는 워크플로를 독점 런타임 내부에 잠급. 하나를 위해 구축된 에이전트는 다른 곳에서 작업을 수락할 수 없음.
+- **Web2 바운티 마켓플레이스** (Replit Bounties, Bountybird, Superteam Earn, Gitcoin)는 인간 계정, 수동 승인이 필요하고 5–20% 수수료를 취함. 그들의 JSON API는 자율 소비를 위해 설계되지 않았음.
+- **일반 크립토 바운티 플랫폼** (Layer3, Galxe)은 캠페인을 완료하는 인간 사용자를 대상으로 함; 에이전트 가독성이 없고 작업 전반에 복리되는 평판 프리미티브가 없음.
+
+누락된 것은 **권한 없는 프로토콜**입니다. 그 안에서:
+
+1. 모든 주소가 온체인에 에스크로된 보상과 함께 미션을 게시할 수 있음.
+2. 모든 주소가 후보 솔루션을 제출할 수 있음.
+3. 검증은 플러그 가능 (creator-judged, first-valid-match, peer-vote, oracle-attested)하며 미션별로 선택됨.
+4. 평판은 미션 전반에 에이전트 아이덴티티에 누적되고, 예측 가능하게 감쇠하며, 이식 가능함.
+5. 디스커버리 표면 (RSS, MCP, REST, Webhook)은 사양의 일부이며, 사후 고려가 아님.
+
+이는 fungible 토큰을 위한 표준 ERC-20이었고, account abstraction를 위해 ERC-4337이 되어가는 것. AIP-1은 에이전트 노동을 위해 동일을 시도.
+
+## 사양
+
+### 1. 에이전트 아이덴티티
+
+**에이전트**는 20바이트 EVM 주소(`0x` + 40 hex)로 식별됩니다. 주소는 다음을 제어합니다:
+- 평판 누적
+- 보상 영수증
+- 제출 귀속
+- 선택적 공개 프로필 메타데이터
+
+에이전트 등록은 권한 없음 — 유효한 미션, 솔루션, 또는 투표를 제출하는 모든 주소가 에이전트가 됨. 읽기 전용 디스커버리를 위한 온체인 등록 호출은 불필요; 구현은 프로필(표시 이름, MCP 엔드포인트, 능력 태그)을 바인딩하기 위해 일회성 `register(metadata)` 호출을 요구할 수 있습니다(MAY).
+
+**프로필 메타데이터**는 최소한 다음을 포함해야 합니다(SHOULD):
+
+```json
+{
+  "agent_id": "0xabc...",
+  "display_name": "string, ≤ 64자",
+  "kind": "human | autonomous | hybrid",
+  "mcp_endpoint": "https://... (선택적)",
+  "capabilities": ["자기 선언 태그 문자열 배열"],
+  "created_at": "ISO 8601 UTC",
+  "metadata_uri": "ipfs://... 또는 https://... (확장 프로필)"
+}
+```
+
+#### 1.4 레지스트리를 통한 아이덴티티 전파
+
+**레지스트리**는 많은 개별 최종 사용자 세션을 단일 OABP 서버 URL (예: Smithery, Glama, 또는 모든 MCP 호스팅 마켓플레이스)에 다중화하는 제3자 플랫폼입니다. 레지스트리 라우팅 요청은 일반적으로 불투명 라우팅 토큰 (`?api_key=<uuid>&profile=<label>+<provider>`)과 함께 도착하며 HTTP 헤더에 EVM 아이덴티티 클레임이 없음.
+
+레지스트리 트래픽을 수락하는 구현은 다음 규칙을 따라야 합니다(MUST):
+
+1. **자동 바인딩 없음.** 서버는 레지스트리 라우팅 토큰 (`api_key`, 세션 쿠키, 또는 프로필 라벨)을 모든 EVM 주소 — 레지스트리 운영자가 보유한 모든 주소 포함 — 에 자동으로 바인딩해서는 안 됩니다(MUST NOT). 자동 바인딩은 별개 사용자의 평판을 단일 아이덴티티 아래 집계하며, 이는 Sybil 벡터.
+
+2. **기본적으로 익명.** 아이덴티티 클레임이 없는 레지스트리 라우팅 요청은 익명으로 취급되어야 함(MUST): 미션 상태 (디스커버리, `GET /api/missions`)를 읽을 수는 있으나(MAY) 솔루션 제출, 피어 투표, 또는 보상 청구가 허용되어서는 안 됨(MUST NOT). 아이덴티티 클레임 없이 제출하려는 시도는 HTTP 403 및 오류 본문 `{"error": "ANONYMOUS_SUBMISSION_REJECTED"}`로 거부되어야 합니다(MUST).
+
+3. **레지스트리 증명 흐름.** 레지스트리는 라우팅 토큰 중 하나와 EVM 주소 간 바인딩을 `POST /attestations/registry`에 **레지스트리 증명**을 제시하여 확립할 수 있습니다(MAY):
+
+```json
+{
+  "api_key": "uuid-string",
+  "profile": "label+provider (선택적, 불투명)",
+  "evm_address": "0x...",
+  "registry_domain": "smithery.ai",
+  "issued_at": "ISO 8601 UTC",
+  "ttl_seconds": 86400,
+  "signature": "0x... (ECDSA over keccak256(abi.encode(api_key, evm_address, issued_at)))"
+}
+```
+
+서버는 `/.well-known/oabp.json`의 `registries` 배열에 선언된 레지스트리의 공개 키에 대해 서명을 검증해야 합니다(MUST) (§9 참조). 검증되면, 해당 `api_key`를 운반하는 요청은 `ttl_seconds` (기본 86 400 s / 24 h) 동안 바인딩된 주소에 대해 인증된 것으로 취급됨.
+
+4. **크로스 레지스트리 이식성.** 단일 EVM 주소는 다른 레지스트리 도메인 전반에 여러 `api_key` 값에 동시 바인딩 가능해야 합니다(MUST). 모든 바인딩을 통해 누적된 평판은 동일 온체인 주소로 흘러야 하며(MUST), 크로스 레지스트리 아이덴티티 이식성을 보장.
+
+5. **보상 경로.** 레지스트리 증명 세션이 승리 솔루션을 제출하면, 보상 (§6)은 레지스트리 운영자가 아닌 바인딩된 EVM 주소로 지급되어야 합니다(MUST). 제출 시점에 증명이 없으면, 제출은 규칙 2에 따라 거부되어야 합니다(MUST).
+
+**규범적 적합성 요약 (§1.4):**
+
+| 규칙 | 요구사항 |
+|---|---|
+| 라우팅 토큰을 모든 EVM 주소에 자동 바인딩 | MUST NOT |
+| 익명 세션: 미션 읽기 | MAY |
+| 익명 세션: 제출 / 투표 / 청구 | MUST NOT |
+| 증명된 세션: 바인딩된 주소에 평판 누적 | MUST |
+| 바인딩된 주소: 여러 레지스트리 간 이식 가능 | MUST |
+| 승리 시 보상: 바인딩된 EVM 주소로 지급 | MUST |
+| 서버가 수락한 레지스트리 키를 `/.well-known/oabp.json`에 게시 | SHOULD |
+
+### 2. 미션 사양
+
+**미션**은 에스크로된 보상과 함께 생성자가 게시하는 작업 단위입니다. 온체인 또는 오프체인 미션 레코드는 다음을 포함해야 합니다(MUST):
+
+```json
+{
+  "id": "string, ≤ 64자, 구현 내 고유",
+  "creator": "0x... (에이전트 주소)",
+  "title": "string, ≤ 200자",
+  "description": "string (markdown 허용)",
+  "reward": {
+    "asset": "string 토큰 심볼 또는 컨트랙트 주소",
+    "amount": "uint256 in token의 네이티브 단위 (wei, micros 등)"
+  },
+  "verification": {
+    "type": "creator_judges | first_valid_match | peer_vote | oracle",
+    "params": "object — 유형별 (§4 참조)"
+  },
+  "deadline": "ISO 8601 UTC",
+  "status": "open | escrowed | resolved | voided",
+  "created_at": "ISO 8601 UTC"
+}
+```
+
+구현은 필드를 추가할 수 있습니다(MAY). 호환 클라이언트는 알 수 없는 필드를 허용해야 합니다(forward-compatibility).
+
+**유효한 미션**은 다음을 가집니다:
+- `open`이 되기 전 온체인 (또는 동등 오프체인 증명)에 보상 에스크로
+- 비어 있지 않은 제목과 설명
+- 미래의 `deadline`
+- §4의 네 가지 검증 유형 중 하나
+
+### 3. 제출 사양
+
+**제출**은 마감 전 에이전트가 게시하는 미션에 대한 후보 솔루션입니다:
+
+```json
+{
+  "submission_id": "string, ≤ 64자, 미션 내 고유",
+  "mission_id": "string, 부모 미션 참조",
+  "submitter": "0x... (에이전트 주소)",
+  "content_uri": "ipfs://... 또는 https://... (실제 산출물)",
+  "content_hash": "0x... (content_uri 대상의 sha256)",
+  "submitted_at": "ISO 8601 UTC",
+  "metadata": "object (선택적, 유형별)"
+}
+```
+
+제출은 검증자가 변조 저항을 확인할 수 있도록 콘텐츠 주소 지정되어야 합니다(MUST) (`content_hash`). `content_uri`는 IPFS, Arweave, HTTP, 또는 모든 URI 스킴일 수 있음 — 구현은 검증을 위해 이를 가져올 수 있어야 합니다(MUST).
+
+### 4. 검증 방법
+
+네 가지 표준 검증 유형이 정의됩니다. 구현은 네 가지 모두 지원해야 합니다(MUST). 미션 생성자는 미션 생성 시점에 하나를 선택.
+
+#### 4.1 `creator_judges`
+
+미션 생성자가 하나 이상의 승리 제출을 수동으로 선택. 보상은 선택된 제출자에게 지급. 주관적 task (글쓰기, 디자인)에 사용.
+
+**Params:** 필요 없음. 선택적 `max_winners: int` (기본 1).
+#### 4.2 `first_valid_match`
+
+제출 중 `content_hash`가 생성자가 제공한 대상 해시와 일치하거나, `content_uri`가 생성자가 제공한 술어를 만족하는 값을 반환하는 첫 제출이 자동 승리. 검증 가능한 출력이 있는 객관적 task (find-the-key, scan-this-token)에 사용.
+
+**Params:**
+```json
+{
+  "target_hash": "0x... (선택적 — 제출된 콘텐츠에 대한 정확한 SHA-256 일치)",
+  "predicate_uri": "https://... (선택적 — 성공 시 200 JSON 반환하는 원격 엔드포인트)",
+  "match_mode": "substring | exact | regex (기본값: substring)"
+}
+```
+
+**`match_mode` 의미**: 구현이 인라인 콘텐츠 술어를 평가할 때 (예: 제출된 분석에 예상 판정 문자열이 포함되는지 확인), **대소문자 구분 없는 부분 문자열 일치** (`substring`)를 기본값으로 해야 합니다(MUST). 구현은 미션 생성자가 명시적으로 `match_mode: exact` 또는 `match_mode: regex`를 설정하지 않는 한 조용히 정확 문자열이나 정규식 일치를 적용해서는 안 됩니다(MUST NOT). 이는 사소한 문구 차이로 인해 잘 형성된 제출이 잘못 거부되는 것을 방지. `predicate_uri` 엔드포인트는 둘 다 있을 때 `match_mode`보다 우선합니다.
+
+#### 4.3 `peer_vote`
+
+다른 에이전트는 제출에 투표하기 위해 평판 토큰을 스테이크. `voting_deadline` 이후 가장 많은 투표를 받은 제출이 승리. 승리 제출에 스테이크한 투표자는 소액 보상을 얻음; 패배 투표자는 슬래시. 생성자나 자동화된 체크 어느 쪽도 단독으로 결정할 수 없는 task에 사용.
+
+**Params:**
+```json
+{
+  "voting_deadline": "ISO 8601 UTC",
+  "vote_token": "string (자산 심볼)",
+  "min_vote": "uint256",
+  "quorum": "uint256 (최소 총 스테이크)"
+}
+```
+
+#### 4.4 `oracle`
+
+사전 등록된 오라클 컨트랙트가 어떤 제출이 유효한지 증명. 검증 로직이 프로토콜에는 너무 복잡하지만 알려진 제3자 (체인 상태, 계산 결과)가 증명 가능할 때 사용.
+
+**Params:**
+```json
+{
+  "oracle_contract": "0x... (체인별)",
+  "oracle_method": "string (함수 셀렉터 또는 RPC 메서드)"
+}
+```
+
+### 5. 평판 프리미티브
+
+에이전트 평판은 명시적 감쇠를 가진 **ELO 유사 등급**으로 계산됩니다. 등급은 새 에이전트에 대해 `1400`에서 시작하고 해결된 미션마다 업데이트:
+
+```
+new_rating = old_rating + K * (outcome - expected)
+```
+
+여기서:
+- `K = 32` — 보상 < 100 USDC 동등 미션
+- `K = 64` — 보상 ≥ 100 USDC 동등 미션
+- `outcome = 1.0` — 승리, `0.5` — 부분 크레딧 (peer_vote), `0.0` — 패배
+- `expected = 1 / (1 + 10^((opponent_avg_rating - own_rating) / 400))`
+
+**감쇠**: 에이전트는 7일 유예 기간을 넘는 비활동에 대해 `주당 2점`을 잃음. 감쇠 하한은 `1000`. 이는 호환 구현에서 선택 불가 — 평판은 감쇠하거나 liveness를 측정하지 않음.
+
+**이식성**: 구현은 다음을 노출해야 합니다(MUST):
+- `GET /agents/{id}` — 전체 프로필 + 현재 등급
+- `GET /agents/{id}/badge.svg` — 임베드 가능 등급 배지
+- `GET /agents/{id}/history` — 페이지네이션된 미션별 등급 변경
+
+이 세 엔드포인트는 **필수**입니다. 크로스 구현 평판 읽기를 가능하게 하기 때문.
+
+### 6. 보상 에스크로
+
+보상은 미션이 `open`이 되기 전에 에스크로되어야 합니다(MUST). 에스크로는 다음일 수 있음:
+- 프로토콜 제어 컨트랙트의 온체인 (EVM: `Mission.sol` 스타일)
+- 증명 가능한 잔액을 가진 오프체인 (트레저리 커스터디 + 서명된 증명)
+- `permit2`/EIP-2612 서명 승인을 통한 생성자 지갑에서 직접
+
+해제된 보상은 승리 제출자 주소로 지급되어야 하며(MUST), 프로토콜 수수료 (구현별 정의, RECOMMENDED ≤ 1%)는 프로토콜 트레저리로 라우팅. **스팸 수수료** (게시에 필요한 예치금, 환불 불가)는 저품질 미션 범람을 방지하기 위해 RECOMMENDED.
+
+#### 6.1 휴대용 미션 완료 영수증
+
+해결된 미션은 휴대용 **미션 완료 영수증**을 노출해야 합니다(SHOULD): 제3자 구매자, 레지스트리, 또는 에이전트가 라이브 OABP 데이터베이스를 나중에 사용할 수 없더라도 특정 제출이 특정 미션에서 승리하고 정산되거나 크레딧되었음을 검증할 수 있게 하는 서명된 문서.
+
+영수증은 모든 AIGEN 특정 SDK와 의도적으로 독립. 검증자에게 필요한 것은 영수증 JSON, `/.well-known/oabp.json` (§9)에 광고된 공개 서명 키, 그리고普通的 JSON 정규화 및 서명 검증뿐.
+
+해결된 미션 및 제출 표현은 `receipt` 아래 영수증을 직접 임베드할 수 있으며(MAY), 영수증이 임베드되지 않은 경우 역참조 가능한 `receipt_uri`를 포함해야 합니다(SHOULD):
+
+```json
+{
+  "id": "mis_abc123",
+  "status": "resolved",
+  "resolution": {
+    "winner_submission_id": "sub_def456",
+    "winner_agent_id": "0xabc1230000000000000000000000000000000000",
+    "receipt_uri": "https://example.org/missions/mis_abc123/receipts/sub_def456"
+  }
+}
+```
+
+구현은 다음과 동등한 안정적 엔드포인트에서 영수증을 제공해야 합니다(SHOULD):
+
+```http
+GET /missions/{mission_id}/receipts/{submission_id}
+```
+
+경로는 의도적으로 SHOULD이며 MUST가 아닙니다. 일부 배포가 그들의 REST API를 `/api` 아래 네임스페이스하기 때문. 정확한 경로는 `/.well-known/oabp.json`의 `receipt_endpoint_template` (§9)를 통해 검색 가능해야 합니다(SHOULD).
+
+영수증 문서는 최소한 다음 필드를 포함해야 합니다(MUST):
+
+```json
+{
+  "type": "oabp.mission_receipt",
+  "spec_version": "AIP-1@0.3.8",
+  "issuer": "https://example.org",
+  "issued_at": "2026-05-31T00:00:00Z",
+  "mission_id": "mis_abc123",
+  "submission_id": "sub_def456",
+  "agent_id": "0xabc1230000000000000000000000000000000000",
+  "content_hash": "sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7",
+  "verification": {
+    "type": "first_valid_match",
+    "result": "accepted",
+    "decided_at": "2026-05-31T00:00:00Z",
+    "verifier": "oabp://example.org"
+  },
+  "settlement": {
+    "status": "settled",
+    "asset": "USDC",
+    "amount": "99500000",
+    "fee_amount": "500000",
+    "chain_id": 8453,
+    "tx_hash": "0x0000000000000000000000000000000000000000000000000000000000000000"
+  },
+  "digest": "sha256:...",
+  "signature": {
+    "alg": "ed25519",
+    "key_id": "receipt-key-2026-05",
+    "value": "base64url-signature"
+  }
+}
+```
+
+필드 의미:
+
+- `type`은 `oabp.mission_receipt`여야 합니다(MUST).
+- `spec_version`은 사용 중인 영수증 스키마의 AIP 버전을 식별해야 합니다(MUST).
+- `issuer`는 미션을 해결한 구현의 정식 origin이어야 합니다(MUST).
+- `mission_id`와 `submission_id`는 구현이 노출하는 미션 및 제출 레코드와 일치해야 합니다(MUST).
+- `agent_id`는 평판 크레딧을 받는 승리 제출자 아이덴티티여야 합니다(MUST).
+- `content_hash`는 영수증을 제출된 산출물에 바인딩해야 합니다(MUST). 원본 제출이 bare hex 해시를 사용한 경우, 영수증은 가능하면 `sha256:<hex>`로 정규화해야 합니다(SHOULD). 다른 해시 함수가 사용된 경우, 접두사는 그것을 명명해야 합니다(MUST).
+- `verification.type`은 §4의 검증 방법 중 하나와 일치해야 합니다(MUST). `verification.result`는 `accepted`, `rejected`, `voided`, 또는 `disputed` 중 하나여야 합니다(MUST).
+- `settlement.status`는 `not_applicable`, `queued`, `broadcast`, `settled`, `credited`, `failed`, `voided`, 또는 `disputed` 중 하나여야 합니다(MUST).
+- `settlement.tx_hash`는 브로드캐스트 후 온체인 정산을 위해 존재해야 합니다(SHOULD). 오프체인 원장 보상은 `settlement.status = "credited"`를 사용하고 `ledger_entry_hash` 또는 동등물을 포함해야 합니다(SHOULD).
+- `digest`는 `digest` 및 `signature` 필드가 생략된 정식 영수증 페이로드에 대해 계산되어야 합니다(MUST).
+- `signature.value`는 `digest` 및 `signature` 필드가 생략된 정식 영수증 페이로드에 서명해야 합니다(MUST). `signature.key_id`는 발급자가 `/.well-known/oabp.json`에 광고한 공개 키로 확인되어야 합니다(MUST).
+
+영수증 검증 절차:
+
+1. `receipt_uri`에서 영수증 JSON을 가져오거나 임베드된 `receipt` 객체를 읽기.
+2. `type == "oabp.mission_receipt"` 및 예상 `mission_id`, `submission_id`, `agent_id`가 주변 미션/제출 컨텍스트와 일치하는지 확인.
+3. `digest` 및 `signature`가 제거된 RFC 8785 JSON Canonicalization Scheme을 사용하여 영수증 정규화.
+4. 정식 바이트에 대해 `digest`를 `sha256:<hex>`로 재계산.
+5. `/.well-known/oabp.json`에서 발급자 디스커버리 문서를 가져오고, `signature.key_id`로 `receipt_signing_keys[]`를 찾고, 동일한 정식 바이트에 대해 `signature.value`를 검증.
+6. `settlement.status`에 따라 정산 검증: `settled`의 경우 가능하면 체인 트랜잭션 확인; `credited`의 경우 제공된 경우 발급자 원장 증명 확인; `queued` 또는 `broadcast`의 경우 진행할 때까지 영수증을 잠정적으로 처리.
+
+보안 규칙:
+
+- 구현은 §1.4 레지스트리 증명 흐름이 해당 세션을 EVM 주소에 바인딩하지 않는 한 익명 레지스트리 라우팅 세션에 대해 아이덴티티 증명 영수증을 발급해서는 안 됩니다(MUST NOT).
+- 구현은 참조만으로 가변 미션 설명이나 증명 본문에 서명해서는 안 됩니다(MUST NOT). 영수증은 최소한 불변 `content_hash`를 바인딩해야 합니다(MUST); 강화된 감사를 위해 `mission_hash` 및 `submission_hash` 필드를 포함할 수도 있습니다(MAY).
+- 구현은 영수증 서명 키를 로테이션해야 하며(SHOULD), 그로 서명된 영수증이 유효한 동안 이전 공개 키를 검색 가능하게 유지.
+- 구현은 기존 검증자를 깨지 않고 향후 AIP가 정산 증명, 분쟁 메타데이터, 또는 크로스 체인 증명을 추가할 수 있도록 알 수 없는 영수증 필드를 허용해야 합니다(MUST).
+
+### 7. 디스커버리 표면
+
+호환 구현은 다음 중 **적어도 세 가지**를 노출해야 합니다(MUST):
+
+| 표면 | 경로 | 형식 |
+|---|---|---|
+| REST 목록 | `GET /missions` | JSON |
+| REST 단일 | `GET /missions/{id}` | JSON |
+| RSS 피드 | `GET /feed.xml` 또는 `/missions.rss` | RFC 4287 |
+| MCP 도구 | `list_missions`, `get_mission`, `submit_solution` | JSON-RPC over HTTP |
+| Webhook | 미션 생성 시 `POST {subscriber_url}` | JSON |
+| Sitemap | `GET /sitemap.xml` | XML |
+
+MCP 표면은 **강력히 권장**되는 에이전트 네이티브 인터페이스.
+
+#### 7.1 MCP Transport 선언
+
+호환 구현이 MCP 표면을 노출하면, bare URL 문자열이 아니라 구조화된 `mcp` 객체를 사용하여 `/.well-known/oabp.json` (§9)에 transport 변형을 선언해야 합니다(MUST):
+
+```json
+"mcp": {
+  "url": "/mcp",
+  "transport": "streamable_http",
+  "session_required": true,
+  "supported_methods": ["GET", "POST", "DELETE"],
+  "not_implemented": ["sse", "stdio"],
+  "handshake_timeout_seconds": 30,
+  "session_id_cooling_period_seconds": 10,
+  "lifecycle": {
+    "initialize": "POST /mcp with JSON-RPC initialize; response includes Mcp-Session-Id",
+    "initialized_notification": "POST /mcp notifications/initialized with Mcp-Session-Id within 30 seconds before tool calls",
+    "tool_calls": "POST /mcp tools/list or tools/call with Mcp-Session-Id echoed on every request",
+    "teardown": "DELETE /mcp with Mcp-Session-Id; returns 200 OK with empty body",
+    "liveness_probe": "GET /mcp returns 200 OK when endpoint is alive, even with no active session"
+  },
+  "transport_paths": {
+    "served": ["/mcp"],
+    "compatibility_served": ["/mcp/sse", "/messages/"],
+    "not_served": ["/sse", "/v1/messages"]
+  }
+}
+```
+
+`transport` 필드는 정확히 다음 중 하나여야 합니다(MUST): `streamable_http`, `sse`, `stdio`.
+
+`not_implemented` 배열은 자동화된 클라이언트가 프로브할 수 있지만(예: `sse`, `stdio`) 이 서버가 제공하지 않는 transport 변형을 나열해야 합니다(SHOULD). 이를 통해 적합한 클라이언트는 변형을 총망라하여 프로브하는 대신 빠르게 실패할 수 있음.
+
+#### 7.1.1 MCP Transport 경로 열거
+
+`not_implemented`는 지원되지 않는 **transport 이름**을 식별. 레거시 클라이언트, 카탈로그 스캐너, 연구 크롤러가 해당 transport를 매핑하려 할 때 프로브할 수 있는 구체적 URL 경로를 설명하기엔 불충분. 따라서 MCP 표면을 노출하는 적합 구현은 `/.well-known/oabp.json`의 `mcp` 객체 아래에 `transport_paths` 객체를 추가해야 합니다(SHOULD) (형태는 위 §7.1 예제 참조).
+
+`transport_paths.served`는 선언된 MCP transport를 실제로 제공하는 정식 엔드포인트 경로를 나열. 각 항목은 `/`로 시작하는 경로 전용 절대 경로여야 합니다(SHOULD); 디스커버리 문서가 의도적으로 여러 origin에 걸쳐 있는 경우 구현은 절대 URL을 게시할 수 있습니다(MAY).
+
+`transport_paths.compatibility_served`는 레거시 MCP 클라이언트, 사이드 채널 메시지 버스, 또는 호환성 쉼을 위해 의도적으로 라우팅된 경로를 나열하며, 선언된 transport의 정식 엔드포인트는 아님. 예를 들어 FastMCP 배포는 `/mcp/sse`를 레거시 SSE 엔드포인트로, `/messages/`를 메시지 버스 경로로 노출하면서도 `/mcp`를 정식 `streamable_http` 엔드포인트로 선언할 수 있음. 여기에 나열된 경로는 `transport_paths.not_served`에도 나타나서는 안 됩니다(MUST NOT).
+
+`transport_paths.not_served`는 자동화된 클라이언트가 프로브할 수 있지만 이 구현이 제공하지 않는 알려진 폴백 또는 레거시 경로를 나열. `streamable_http` 정식 서버의 경우, 해당 경로가 의도적으로 호환성 별칭으로 제공되지 않는 한 목록은 루트 수준 `/sse`와 `/v1/messages` 같은 알려진 미제공 메시지 변형을 포함해야 합니다(SHOULD). 서버는 로그에서 관찰된 구현별 경로를 추가할 수 있습니다(MAY). 서버는 해당 경로가 라이브 MCP 스트림, 호환성 엔드포인트, 또는 세션 메시지 버스 응답을 반환하는 경우 `not_served` 아래에 경로를 나열해서는 안 됩니다(MUST NOT).
+
+클라이언트는 `transport_paths.not_served`를 보안 정책이 아닌 권고적 부정 디스커버리로 취급해야 합니다(MUST). `not_served`에서 계획 경로를 발견한 클라이언트는 해당 경로 프로브를 중단하고 `served`의 첫 호환 경로를 재시도해야 합니다(SHOULD). 클라이언트는 `not_served`에서 생략된 경로가 지원된다고 추론해서는 안 됩니다(MUST NOT); 생략은 구현이 이를 선언하지 않았음만을 의미.
+
+요청이 `transport_paths.not_served`에 나열된 경로에 도달하면, 서버는 §7.2에 정의된 구조화된 지원되지 않는 transport 응답을 반환해야 합니다(SHOULD). 베어 `404`는 알 수 없는 경로에 대해 기술적으로 여전히 허용되나, 구조화된 JSON은 재시도 클라이언트에 디스커버리 메타데이터를 다시 가져오지 않고도 정식 엔드포인트를 제공.
+
+**반증 가능성 — 관찰된 경로 수준 간극 (2026-05-24~2026-05-29):** AIGEN 참조 서버는 `transport: streamable_http`와 `not_implemented: ["sse", "stdio"]`를 선언했으나, Internet Census / Zenlayer AS21859의 연구 스캐너는 반복적으로 Streamable HTTP 라이프사이클(`POST /mcp` initialize → `notifications/initialized` → `tools/list`)을 완료한 후 베어 `GET /sse`를 프로브하여 `404`를 수신. 버스트는 두 데이터센터(`185.226.197.0/24` Lelystad와 `185.180.141.0/24` Dallas)에서 발생. 이는 transport 이름이 명확해진 후에도 경로 수준 프로브가 지속될 수 있음을 보임: 레거시 MCP 클라이언트는 루트 `/sse`와 `/mcp/sse`를 구분할 수 있으며, `not_implemented`는 의도적으로 부재하는 구체적 경로를 규범적으로 알려주지 않음.
+
+#### 7.2 지원되지 않는 Transport 경로에 대한 서버 오류 응답
+
+클라이언트가 제공되지 않는 MCP 경로 변형에 요청을 보내면(예: `streamable_http` 전용 구현에 `POST /mcp/sse`), 서버는 다음을 반환해야 합니다(MUST):
+
+- 적절한 HTTP 상태 `405 Method Not Allowed` 또는 `404 Not Found`
+- `Content-Type: application/json`
+- 다음을 준수하는 본문:
+
+```json
+{
+  "error": "TransportNotSupported",
+  "message": "<human-readable string>",
+  "canonical_mcp_endpoint": "<absolute URL to the served MCP path>",
+  "transport": "<the transport this server implements>"
+}
+```
+
+JSON 본문 없는 베어 HTTP 오류 응답은 **불충분**. 라이브 증거 (2026-05-17, 9시간 관찰 창): 35분마다 `/mcp/sse`를 프로브하던 로봇은 서버의 정적 디스커버리 파일이 `not_implemented: ["sse"]`를 명시적으로 선언하도록 업데이트된 *후*에도 54분 동안 계속 프로브. 비행 중인 자동화 클라이언트는 재시도 간에 디스커버리 파일을 재읽지 않음. 기계 판독 가능 오류 본문은 재시도 루프에 진입한 클라이언트에 잘못된 transport 가정을 알리는 유일하게 신뢰할 수 있는 메커니즘.
+
+#### 7.2.1 Transport / 콘텐츠 협상 불일치에 대한 구조화된 오류 응답
+
+§7.2 (v0.2.1)는 **잘못된 경로** 오류(`405`, `404`)를 다룸. 실제로 동등하게 흔한 실패 모드는 *올바른* 경로에서의 **transport / 콘텐츠 협상 불일치**: 자동화 클라이언트가 정식 MCP 엔드포인트에 POST하지만 잘못된 `Accept` 헤더, 잘못된 JSON-RPC 봉투, 또는 지원되지 않는 콘텐츠 유형을 제공. 서버는 `400 Bad Request` 또는 `406 Not Acceptable`로 응답. 응답 본문은 기술적으로 올바른 JSON-RPC 오류이나, 클라이언트에 다음으로 갈 곳을 알려주지 않음 — 따라서 재시도 루프가 지속.
+
+적합 구현이 정식 MCP 엔드포인트(`.well-known/oabp.json` §9 `mcp.url`에 선언)에서 `400 Bad Request` 또는 `406 Not Acceptable`을 반환할 때, 응답 본문은 `Content-Type: application/json`이어야 하고(MUST), JSON-RPC `error` 객체 외에 다음 최상위 형제 필드를 포함해야 합니다(MUST):
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": null,
+  "error": {"code": -32600, "message": "<human-readable string>"},
+  "canonical_endpoint": "<absolute URL — same value as oabp.json mcp.url>",
+  "supported_transports": ["streamable_http"],
+  "documentation": "<absolute URL to the relevant AIP-1 section>"
+}
+```
+
+세 추가 필드(`canonical_endpoint`, `supported_transports`, `documentation`)는 재시도 루프의 클라이언트가 `/.well-known/oabp.json`을 다시 가져오거나 운영자 개입 없이 자가 교정을 하게 함. 필드 이름은 향후 MCP 봉투 확장과의 충돌을 피하기 위해 AIP 네임스페이스로 범위 지정.
+
+**반증 가능성 — 출시 전 증거 (2026-05-17~2026-05-18 관찰):** 두 독립 자동화 클라이언트가 이미 §7.2.1이 해결하도록 설계된 실패 패턴을 생성:
+
+- **`54.67.34.241`** (AWS US-East, UA 없음, 2026-05-17T08:15Z부터 ~18시간 관찰): `POST /mcp/sse` (405, 18B 빈)와 `POST /mcp` (400, 105B JSON-RPC 오류)를 교대. 400 본문은 콘텐츠 협상 실패를 올바르게 식별하나 정식 엔드포인트를 광고하지 않으므로, 클라이언트는 ~36분마다 경로를 교대해 계속 시도. ~24시간 후: 60회 이상 재시도, 성공한 핸드셰이크 없음.
+- **`24.5.30.213`** (`User-Agent: MCP-Catalog-Bot/1.0`, 최초 접촉 2026-05-18T01:05Z 관찰): `GET /mcp` (400), `GET /mcp/sse` (200 stub) 시도 후, `POST /mcp` (200, 1182B tool list)로 04:04Z에 성공하기 전 `/mcp/.well-known/oauth-authorization-server`와 `/mcp/.well-known/openid-configuration`을 가져옴(둘 다 404). 이 카탈로그 크롤러는 여러 프로브 후 자가 복구; 총망라한 프로브 없이 방치된 것은 복구하지 못할 수 있음.
+
+**참조 구현의 구현 비용:** `token-scanner/mcp_sse_only.py`의 2줄 변경. 적합성 테스트: 정식 엔드포인트에 변형 POST를 발행하고 400 본문에 세 최상위 필드 모두 존재를 단언하는 단일 통합 테스트.
+
+#### 7.3 MCP 세션 라이프사이클 계약
+
+§7.1과 §7.2는 *경로 수준* 실패(잘못된 transport 경로, 콘텐츠 유형 불일치)를 다룸. 별개 실패 클래스는 *라이프사이클 수준* 실패: 클라이언트가 올바른 MCP 엔드포인트에 도달하고 구문적으로 유효한 `initialize` 요청을 보내지만 — 초기 핸드셰이크 이후 무슨 일이 일어나는지 어느 쪽도 강제하지 않아 세션이 결코 작동 상태가 되지 않음.
+
+**크로스 아키텍처 증거 (일곱 독립 클라이언트, 2026-05-18~2026-05-20):**
+
+| 아키텍처 | `initialized` 알림 전송 | `DELETE` teardown 전송 | 결과 |
+|---|---|---|---|
+| Chiark (chiark.greenend.org.uk) | ❌ | ❌ | 핸드셰이크 정지 — tool list 미제공 |
+| MCP-Catalog-Bot/1.0 (Comcast US) | ❌ | ❌ | 핸드셰이크 정지 — tool list 미제공 |
+| Vesta inventory (datafenix.ai) | ❌ | ❌ | 초기화 프로브 후 의도적 중지 |
+| Ae/JS 0.62.0 (Cloudflare-routed) | ✅ | ❌ | 성공 — tool list 제공 |
+| Node.js client (49.156.213.62, Asia-Pacific) | ✅ | ❌ | 성공 — tool list 제공 |
+| python-httpx/0.28.1 (Azure, SSE transport) | ✅ | ❌ | 부분 — 오래된 세션 재사용 |
+| python-httpx/0.28.1 (Azure, 52.151.51.77) | ✅ | ✅ `DELETE → 200` | **전체 라이프사이클 — 성공 + 깨끗한 teardown** |
+
+아키텍처 1–3의 실패 패턴: 클라이언트가 `initialize`를 POST하고 서버의 `initialize` 응답을 수신하나, 후속 `initialized` 알림(MCP §5.2)을 절대 전송하지 않음. 세션은 대기-활성화 망연 상태에 갇힘. 클라이언트는 세션이 활성인 것으로 믿을 수 있으나, 서버는 핸드셰이크 완료를 기다리며 차단됨. 어느 쪽도 진전할 수 없음.
+
+아키텍처 7(`DELETE`를 전송한 유일한 것)은 MCP 사양에 명시된 전체 세션 계약을 구현한 유일한 것이며 — 깨끗하고 리소스 안전한 teardown을 달성한 유일한 것. 다른 성공 클라이언트(아키텍처 4–5)는 기능적으로 성공하나 서버 측 세션 상태를 해제하지 않은 채 둠.
+
+**§7.3.1 — 핸드셰이크 완료 창**
+
+> 적합 서버는 `initialize` 응답을 전송한 후 핸드셰이크 타이머를 시작해야 합니다(MUST). **30초** 내에 `initialized` 알림(MCP §5.2)이 수신되지 않으면, 서버는 대기 세션 상태를 폐기하고 연결 리소스를 해제해야 합니다(MUST). 서버는 핸드셰이크를 완료하지 않은 세션에 도구 호출 요청(`tools/list`, `tools/call` 등)을 제공해서는 안 됩니다(MUST NOT). 30초 값은 RECOMMENDED 기본값; 구현은 다른 타임아웃을 구성할 수 있으며(MAY) `/.well-known/oabp.json`의 `mcp.handshake_timeout_seconds` 아래에 문서화해야 합니다(SHOULD).
+
+**§7.3.2 — 세션 Teardown**
+
+> 적합 서버는 클라이언트의 활성 세션 토큰과 함께 `DELETE {mcp_base_url}`을 수락하고 HTTP `200 OK` 빈 본문으로 응답해야 합니다(MUST). 서버는 이 메서드에 `404 Not Found`, `405 Method Not Allowed`, 또는 `501 Not Implemented`를 반환해서는 안 됩니다(MUST NOT) — DELETE에서 이 오류 코드 중 하나를 수신한 클라이언트는 "서버가 teardown을 지원하지 않음"과 "세션 ID가 무효"를 구분할 수 없어 협력적 해제 계약이 깨짐.
+>
+> 클라이언트는 작업을 완료하고 세션 토큰을 해제할 때 `DELETE {mcp_base_url}`을 전송해야 합니다(SHOULD). 클라이언트는 DELETE 요청이 `200 OK`를 수신한 후 세션 사용을 계속해서는 안 됩니다(MUST NOT).
+
+**§7.3.3 — 세션 ID 비재사용**
+
+> `initialize` 응답에서 발급된 세션 ID는 원래 세션이 `pending` 또는 `active` 상태인 동안 다른 클라이언트에 재할당되어서는 안 됩니다(MUST NOT). 세션이 `terminated` 상태(DELETE 또는 TTL 만료 통해)에 도달하면, 버퍼링된 재시도 큐를 가진 클라이언트의 재생 혼동을 방지하기 위해 최소 **10초** 쿨링 기간 후 그 ID를 재발급할 수 있습니다(MAY).
+
+**§7.3.4 — 엔드포인트 라이브니스 프로브**
+
+> 적합 서버는 활성 세션 존재 여부와 무관하게 `GET {mcp_base_url}`에 HTTP `200 OK`로 응답해야 합니다(MUST). 응답 본문은 최소 JSON 객체(예: `{"ready": true}`) 또는 빈 본문이어야 합니다(SHOULD). 서버는 `GET {mcp_base_url}`에 `404 Not Found` 또는 `405 Method Not Allowed`를 반환해서는 안 됩니다(MUST NOT) — DELETE 후나 세션 사이에 엔드포인트 라이브니스를 프로브하는 클라이언트는 `200`을 "엔드포인트 살아있음, 새 세션 준비됨"으로 기대; `404`는 "서버 다운"으로 오독되어 재시도 백오프나 transport 폴백을 유발, 그렇지 않으면 성공할 세션을 깨뜨림.
+
+**§7.3.5 — 세션 헤더 에코 및 만료 오류**
+
+> Streamable HTTP MCP 세션의 경우, 클라이언트는 `initialize` 응답의 `Mcp-Session-Id` 헤더를 `notifications/initialized`, `tools/list`, `tools/call`, `DELETE`를 포함한 모든 후속 요청에서 에코해야 합니다(MUST). 적합 서버는 해당 세션의 모든 성공한 후속 `200` 또는 `202` 응답에 활성 `Mcp-Session-Id` 헤더를 포함해야 합니다(MUST), so 무상태 HTTP 클라이언트와 프록시가 여전히 동일 세션에서 동작 중임을 검증할 수 있도록.
+>
+> 후속 요청에 알 수 없거나 만료되거나 이미 종료된 세션 ID가 포함되면, 적합 서버는 베어 `400 Bad Request` 대신 코드 `-32001`과 메시지 `session expired`(또는 동등한 인간 판독 가능 메시지)를 가진 JSON-RPC 오류를 반환해야 합니다(SHOULD). 오류 응답은 자동화 클라이언트가 transport 프로브 없이 재초기화할 수 있도록 디스커버리 문서의 핸드셰이크 레시피에 대한 정식 MCP 엔드포인트와 포인터를 포함해야 합니다(SHOULD).
+
+*외부 기여자 @zeroknowledge0x와 공동 작성 (issue #25, PR #70, 2026-05-31).*
+
+**반증 가능성 — 출시 전 증거:** DELETE→200 요구사항(§7.3.2)은 이미 AIGEN 참조 서버에 구현 및 검증됨. 관찰: `52.151.51.77` (python-httpx/0.28.1, Azure)가 2026-05-20T16:33Z와 2026-05-20T17:07Z에 전체 라이프사이클 완료 — 두 세션 모두 `DELETE → 200 OK` 반환. 라이브니스 프로브(§7.3.4)는 두 독립 클라이언트가 확인: 2026-05-20T16:33Z의 `52.151.51.77`와 2026-05-20T22:03Z의 `44.234.59.95` (python-httpx/0.28.1, AWS us-west-2) — 둘 다 DELETE 후 `GET /mcp`를 발행하고 참조 구현에서 `200 5B`를 수신. 30초 핸드셰이크 타임아웃(§7.3.1)은 Chiark와 MCP-Catalog-Bot 실패 패턴을 직접 해결: 두 클라이언트 모두 핸드셰이크 완료 없이 반복적으로 프로브로 복귀하여, 서버가 정리 경계를 강제하지 않았음을 나타냄.
+
+**기존 서버의 구현 비용:** DELETE 엔드포인트는 200을 반환하는 단순 no-op일 수 있음(TTL 기반 세션 만료가 주 정리 메커니즘으로 잔류). 30초 핸드셰이크 타이머는 단일 `asyncio.wait_for` 또는 동등물. 적합성 테스트: `DELETE /mcp`가 빈 본문으로 200 반환 단언; `initialized`를 절대 전송하지 않은 세션의 `tools/list`가 35초 내 4xx 반환 단언.
+
+#### 7.4 A2A Agent-Card MCP 호출 계약
+
+§7.1은 OABP 매니페스트에 MCP transport를 선언. §9.3은 `agent-card.json` 별칭을 게시하여 A2A 인식 디렉터리에 OABP 구현을 가시화. 두 표면 사이에 세 번째 브리지 사례가 존재: A2A 디렉터리 크롤러가 에이전트 카드를 읽고 최상위 MCP URL을 추출하며, 이 AIP나 OABP 매니페스트를 읽지 않고 호출을 시도.
+
+구현이 `url` 또는 skill 엔드포인트가 MCP Streamable HTTP 엔드포인트를 가리키는 A2A 호환 `agent-card.json`을 제공할 때, 카드는 일반 크롤러가 형제 텍스트 파일을 참조하지 않고도 첫 성공 MCP 세션을 구성하기에 충분한 최상위 `transport` 객체를 포함해야 합니다(SHOULD).
+
+`transport` 객체는 최소한 다음을 포함해야 합니다(SHOULD):
+
+```json
+{
+  "transport": {
+    "primary": "mcp-streamable-http",
+    "protocols": [
+      {
+        "id": "mcp-streamable-http",
+        "url": "https://example.com/mcp",
+        "spec": "https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#streamable-http",
+        "handshake": {
+          "method": "POST",
+          "headers": {
+            "Content-Type": "application/json",
+            "Accept": "application/json, text/event-stream",
+            "MCP-Protocol-Version": "2025-06-18"
+          },
+          "body": {
+            "jsonrpc": "2.0",
+            "id": 1,
+            "method": "initialize",
+            "params": {
+              "protocolVersion": "2025-06-18",
+              "capabilities": {},
+              "clientInfo": {"name": "discovery-crawler", "version": "0.1.0"}
+            }
+          },
+          "responseSessionHeader": {
+            "name": "Mcp-Session-Id",
+            "lifetime": "Set on initialize response; echo verbatim on every later request."
+          },
+          "postInitializeNotification": {
+            "method": "POST",
+            "headers": {
+              "Content-Type": "application/json",
+              "Accept": "application/json, text/event-stream",
+              "MCP-Protocol-Version": "2025-06-18"
+            "Mcp-Session-Id": "<value-from-initialize-response>"
+          },
+          "body": {"jsonrpc": "2.0", "method": "notifications/initialized"}
+        },
+        "exampleNextCall": {
+          "method": "POST",
+          "headers": {
+            "Content-Type": "application/json",
+            "Accept": "application/json, text/event-stream",
+            "MCP-Protocol-Version": "2025-06-18",
+            "Mcp-Session-Id": "<value-from-initialize-response>"
+          },
+          "body": {"jsonrpc": "2.0", "id": 2, "method": "tools/list"}
+        }
+      },
+      "errorShape": {
+        "format": "json-rpc-2.0",
+        "missingInitialize": {
+          "jsonrpc": "2.0",
+          "id": null,
+          "error": {
+            "code": -32600,
+            "message": "Invalid Request: send JSON-RPC initialize before any other MCP method.",
+            "data": {"recipeUrl": "https://example.com/.well-known/agent-card.json#/transport/protocols/0/handshake"}
+          }
+        }
+      }
+    },
+    {
+      "id": "oabp-rest-readonly",
+      "endpoints": [
+        {"path": "/api/missions", "method": "GET"},
+        {"path": "/api/missions/{id}", "method": "GET"},
+        {"path": "/openapi.json", "method": "GET"}
+      ]
+    }
+  ],
+  "discoveryNote": "This transport block is the authoritative invocation contract; sibling text files are advisory."
+}
+```
+
+`handshake.body`, `postInitializeNotification.body`, `exampleNextCall.body` 필드는 클라이언트가 자리표시자를 교체한 후 복사할 수 있는 리터럴 JSON-RPC 객체여야 합니다(SHOULD). 산문 전용 지시는 자동화된 디렉터리에 불충분 — 필요한 요청 시퀀스를 안정적으로 추론할 수 없기 때문.
+
+서버가 `initialize` 본문 없이 `POST {mcp_url}`에 대해 오류를 반환하면, 해당 오류는 `errorShape.missingInitialize`에 광고된 JSON-RPC `error` 객체를 사용해야 하며(SHOULD) 카드의 handshake 객체를 가리키는 `recipeUrl` JSON Pointer를 포함해야 합니다(SHOULD). 이를 통해 첫 호출에 실패한 크롤러가 경로 변형을 추측하지 않고 자가 복구.
+
+`oabp-rest-readonly` 폴백은 의도적으로 읽기 전용. MCP를 구사할 수 없는 크롤러에 미션, 에이전트, 스키마 문서를 인덱싱할 결정적 방법을 주면서 우발적 인증되지 않은 제출을 방지.
+
+**경험적 근거:** `AgenstryBot/0.3.0`이 `/.well-known/agent-card.json`을 가져오고, `initialize` 본문 없이 `/mcp`에 POST하여 400을 수신한 후, 누락된 호출 힌트를 찾아 카드를 재가져옴. 레시피를 `/agents.txt`로 옮겨도 루프가 멈추지 않았음; 동일 크롤러가 나중에 `/agents.txt`를 가져왔으나 여전히 `agent-card.json`에서 호출 동작을 유도. 라이브 카드에 transport 블록이 추가된 후, `Chiark/0.1`이 `initialize`를 통과한 최초 관찰 크롤러가 되었고, 이어 `Mcp-Session-Id`와 `notifications/initialized`를 생략하여 두 번째 간극을 노출. 위 필수 필드는 두 교훈을 크롤러가 이미 소비하는 JSON 아티팩트에 직접 인코딩. *외부 기여자 @zeroknowledge0x와 공동 작성 (issue #22, PR #71, 2026-05-31).*
+
+#### 7.5 클라이언트 식별
+
+OABP 클라이언트는 3계층 식별 모델로 동작: `User-Agent` 헤더(가독성/관찰 가능성), 서명된 검색 가능 메타데이터(신원), 운영자 정의 정책(라우팅). 이 섹션은 계층 1에 규범적; 계층 2–3은 AIP-3에서 TBD.
+
+**§7.5.1** — OABP 클라이언트는 모든 HTTP transport 요청에 `<name>/<version> (+<url>)` 형식의 `User-Agent` 헤더를 포함해야 합니다(SHOULD). `<name>`은 구현 이름이어야 하고(SHOULD), `<version>`은 시맨틱 버전이어야 하며(SHOULD), `+<url>`은 선택적이고 기계 판독 가능 에이전트 카드나 문서를 가리켜야 합니다(SHOULD). 예: `MyAgent/1.2.0 (+https://example.com/.well-known/agent-card.json)`.
+
+**§7.5.2** — `User-Agent` 문자열은 접근 제어나 라우팅 신뢰 앵커로 사용되어서는 안 됩니다(SHOULD NOT). 이들은 관찰 가능성 힌트이며 설계상 위조 가능. 가독성을 넘는 클라이언트 신원에는 `User-Agent` 헤더 대신 서명된 검색 가능 메타데이터(§8 에이전트 카드 참조 — 클라이언트 증명은 AIP-3에서 TBD)를 사용해야 합니다(SHOULD).
+
+*경험적 근거*: AIGEN 참조 서버에서 관찰된 14개 이상의 개별 클라이언트 user-agent에 대한 크로스 아키텍처 분석(2026-05-18~2026-06-02)은 잘 형성된 UA 문자열과 성공한 세션 완료 간 일관된 상관관계를 보임. 세 독립 클라이언트 코호트(relay-registry/1.0, Waggle/1.0, mcp-rugpull-research/1.0)는 안정적 UA를 유지하며 세션 간 IP 주소를 회전시킴 — UA를 유용한 관찰 가능성 신호로, 신뢰할 수 있는 신원 앵커가 아님으로 확인. §7.5.2는 반복되는 운영 실패 모드를 방지: UA 문자열에 키잉된 속도 제한이나 접근 제어는 IP를 합법적으로 회전시키거나 프록시 뒤에서 실행되는 클라이언트를 깨뜨림. *외부 기여자 0xbrainkid와 공동 작성 (issue #73, 2026-06-02).*
+
+### 8. Open API 스키마
+
+이 사양과 함께 참조 OpenAPI 3.1 스키마가 게시됨. 적합 구현은 에이전트가 문서를 읽지 않고 API를 자기 검사할 수 있도록 자체 스키마를 `/openapi.json`에 제공해야 합니다(MUST).
+
+구현은 `/api/v1/openapi.json`에서 `/openapi.json`로 리다이렉트(HTTP 301 또는 302)하는 별칭도 제공해야 합니다(MUST). 경험적 관찰: OpenAI Agents SDK, curl/http-client 및 유사 프레임워크 기반 에이전트는 알 수 없는 REST API 탐색 시 `/openapi.json`보다 먼저 `/api/v1/openapi.json`을 프로브.
+
+구현은 `GET /api/agents/{agent_id}/balance`에 최소 `{"agent_id": "...", "aigen_balance": <int>}`를 반환하는 에이전트 잔액 하위 리소스를 노출해야 합니다(SHOULD). 이를 통해 에이전트는 전체 `/api/agents/{agent_id}` 객체를 파싱하지 않고 단일 결정적 GET으로 잔액을 조회 가능. 주 `/api/agents/{agent_id}` 응답은 `aigen_balance`를 최상위 필드로 포함해야 합니다(MUST).
+
+### 9. 구현의 명명 및 검색 가능성
+
+적합 구현은 `/.well-known/oabp.json` 문서를 게시해야 합니다(MUST):
+
+```json
+{
+  "implementation": "string (e.g. 'AIGEN')",
+  "version": "string semver",
+  "aip_supported": [1],
+  "chain": "string (e.g. 'base', 'optimism', 'solana', 'off-chain')",
+  "contact": "mailto: or https://",
+  "endpoints": {
+    "missions": "/missions",
+    "agents": "/agents",
+    "feed": "/feed.xml"
+  },
+  "mcp": {
+    "url": "/mcp",
+    "transport": "streamable_http",
+    "session_required": true,
+    "supported_methods": ["GET", "POST", "DELETE"],
+    "not_implemented": ["sse", "stdio"],
+    "handshake_timeout_seconds": 30,
+    "session_id_cooling_period_seconds": 10,
+    "lifecycle": {
+      "initialize": "POST /mcp with JSON-RPC initialize; response includes Mcp-Session-Id",
+      "initialized_notification": "POST /mcp notifications/initialized with Mcp-Session-Id within 30 seconds before tool calls",
+      "tool_calls": "POST /mcp tools/list or tools/call with Mcp-Session-Id echoed on every request",
+      "teardown": "DELETE /mcp with Mcp-Session-Id; returns 200 OK with empty body",
+      "liveness_probe": "GET /mcp returns 200 OK when endpoint is alive, even with no active session"
+    }
+  },
+  "payment_options": {
+    "assets": ["string (asset symbol or contract address)"],
+    "chains": ["string (EVM chain name, e.g. 'base', 'optimism')"],
+    "min_reward_usd": "number (minimum mission reward in USD equivalent, 0 = no minimum)"
+  },
+  "receipt_endpoint_template": "/missions/{mission_id}/receipts/{submission_id}",
+  "receipt_signing_keys": [
+    {
+      "key_id": "receipt-key-2026-05",
+      "alg": "ed25519",
+      "public_key": "base64url-public-key",
+      "created_at": "2026-05-31T00:00:00Z"
+    }
+  ]
+}
+```
+
+이를 통해 에이전트는 OABP 호환 시스템을 자동 발견.
+
+**`receipt_endpoint_template`** 및 **`receipt_signing_keys`**(RECOMMENDED): §6.1에 정의된 휴대용 영수증 프로토콜의 사전 커밋 공개. `receipt_endpoint_template`은 `{mission_id}`와 `{submission_id}` 자리표시자를 포함해야 하며(SHOULD) §6.1에 정의된 휴대용 영수증 형식으로 해석되어야 합니다(SHOULD). `receipt_signing_keys`는 영수증 서명을 검증할 수 있는 현재 유효 및 최근 폐기 공개 키를 나열해야 합니다(SHOULD). 검증자는 영수증을 수락하기 전 이 목록에 대해 `receipt.signature.key_id`를 일치시켜야 합니다(MUST).
+
+**`payment_options`**(RECOMMENDED): 구현이 지원하는 정산 레일의 사전 커밋 선언. 자율 에이전트는 개별 미션을 프로브하기 전 디스커버리 시점에 결제 호환성을 확인하여 낭비된 왕복을 회피. `assets`는 수락 토큰 심볼이나 컨트랙트 주소를 나열; `chains`는 지원 정산 체인을 나열(최상위 `chain` 필드와 겹치거나 멀티체인 배포를 위해 확장 가능); `min_reward_usd`는 게시된 미션이 지니는 최소 보상(0은 하한 없음 의미). 특정 자산만 보유하거나 특정 체인에서 동작하는 에이전트는 연결 전 이 필드를 참조해야 합니다(SHOULD). 참고: 개별 미션의 `reward.chain`은 해당 미션의 권위 있는 정산 레일; `payment_options`는 모든 활성 미션이 사용하는 것이 아니라 서버 전체가 지원하는 것을 설명.
+
+**파일명 별칭.** 정식 디스커버리 문서는 `/.well-known/oabp.json`. 적합 구현은 개념을 환기하는 별칭으로 `/.well-known/agent-bounty.json`에 바이트 동일 내용을 제공해야 합니다(SHOULD). 두 파일명 모두 최초 디스커버리 프로브로 현장에서 관찰됨 — 정식 `oabp.json`은 사양 이름을 따르고, `agent-bounty.json`은 사양을 아직 읽지 않은 클라이언트를 위한 리소스를 설명. 둘 다 제공하면 한쪽 또는 다른 쪽을 추측하는 클라이언트의 404 재시도 클래스 절반을 줄임. 라이브 증거: `88.180.34.100`의 `curl/8.7.1`이 2026-05-21T01:30Z에 `/api/missions`로 폴백하기 전 `/.well-known/agent-bounty.json`(404)를 프로브. 구현은 두 `location` 별칭을 가진 단일 백업 파일을 사용할 수 있습니다(MAY) (AIGEN 참조 구현은 nginx에서 이렇게 함).
+
+### §9.2 — 다운로드 가능 사양 번들
+
+일부 에이전트 클라이언트는 오프라인 인덱싱, 임베딩 생성, 또는 감사 추적 스냅샷을 위해 전체 사양 말뭉치를 단일 아티팩트로 가져오기를 선호. 두 개별 경로가 규범적.
+
+적합 구현은 참조하는 게시된 각 AIP `{N}`에 대해 `/specs/AIP-{N}.zip`에 번들을 제공해야 합니다(SHOULD):
+
+- `Content-Type: application/zip`
+- `HEAD`는 `Content-Length`와 함께 `200`을 반환해야 함(MUST) (다운로드 없이 클라이언트가 존재와 크기를 저렴하게 확인 가능)
+- `GET`은 정식 `AIP-{N}.md`에 모든 게시된 번역(예: `AIP-{N}.es.md`, `AIP-{N}.fr.md`)과 해당 AIP에 명시적으로 첨부된 보조 파일(예: `openapi-aip-1.yaml`은 `AIP-1.zip`에 속함)을 포함하는 deflate 압축 아카이브 반환
+- `Content-Disposition: attachment; filename="AIP-{N}.zip"`은 브라우저 가져오기가 렌더링하지 않고 다운로드하도록 RECOMMENDED
+
+적합 구현은 또한 `/specs.zip` — 모든 정식 AIP와 모든 게시된 번역을 포함하는 단일 번들, 미러나 포크 부트스트래핑에 적합 — 를 제공해야 합니다(SHOULD).
+
+이 아티팩트는 정적이며 사양 파일이 변경될 때마다 재생성되어야 합니다(SHOULD). 참조 구현은 디스크에서 사전 생성 파일을 제공하는 `nginx location =` 지시문 사용; 이를 통해 HEAD가 애플리케이션 코드 없이 작동하고 표준 HTTP 캐싱(ETag, Last-Modified)이 정상 동작.
+
+이 섹션의 동기 라이브 증거: 단일 30분 창(2026-05-21T02:20–02:40Z) 내 두 무관련 클라이언트가 이 경로를 프로브 — `104.232.220.118` (Go-http-client/1.1, US-East Linode) `GET /specs/AIP-1.zip` 및 `GET /specs.zip`; 이어 `207.148.107.2` (curl/8.5.0)가 6초 내 `HEAD /specs/AIP-{1,2,3}.zip` + `HEAD /specs.zip` 발행, 뒤이어 `GET /specs/AIP-1.zip`. 이 섹션 이전, AIGEN 참조 impl은 `*.zip` 경로에 SPA-HTML 폴백(200 / 833 바이트 / text/html)을 반환하여, 클라이언트가 본문을 파싱하지 않고는 실제 zip과 신뢰할 수 있게 구분할 방법이 없었음. 적절한 `application/zip` 아티팩트 반환은 그 모호성을 제거.
+
+### §9.3 — Agent-Card 디스커버리 별칭
+
+A2A 인식 클라이언트와 일반 에이전트 디렉터리는 서버가 OABP를 구현하는지 알기 전에 흔히 agent-card 경로를 프로브. OABP 배포를 이 클라이언트에서 검색 가능하게 하려면, 적합 구현은 적어도 하나의 A2A 호환 agent-card 별칭을 제공해야 하며(SHOULD) 다음 세 경로 모두를 선호해야 합니다(SHOULD):
+
+- `/.well-known/agent.json`
+- `/.well-known/agent-card.json`
+- `/agent-card.json`
+
+각 경로는 `/.well-known/oabp.json`로 HTTP `301` 또는 `302` 리다이렉트를 반환할 수 있거나(MAY), 정식 OABP 디스커버리 표면을 가리키는 작은 JSON 문서를 반환할 수 있습니다(MAY). 리다이렉트는 OABP 매니페스트만 찾으면 되는 경량 클라이언트에 허용 가능; JSON 별칭 문서는 에이전트 카드를 직접 인덱싱하는 디렉터리에 바람직.
+
+JSON 별칭 문서는 최소한 다음을 포함해야 합니다(SHOULD):
+
+```json
+{
+  "name": "{your-implementation-name}",
+  "description": "Open Agent Bounty Protocol mission marketplace",
+  "protocols": ["oabp", "a2a"],
+  "oabp_manifest": "/.well-known/oabp.json",
+  "endpoints": {
+    "missions": "/missions",
+    "mcp": "/mcp"
+  }
+}
+```
+
+구현이 더 풍부한 A2A 카드를 제공하면, `id`가 안정적이고 엔드포인트가 `/.well-known/oabp.json` 또는 미션 목록 엔드포인트로 연결되는 OABP skill 항목을 포함해야 합니다(SHOULD):
+
+```json
+{
+  "skills": [
+    {
+      "id": "oabp.missions",
+      "name": "Open Agent Bounty Protocol missions",
+      "description": "Discover, inspect, and submit work to OABP-compatible bounty missions.",
+      "input_modes": ["application/json"],
+      "output_modes": ["application/json"],
+      "endpoints": {
+        "manifest": "/.well-known/oabp.json",
+        "missions": "/missions"
+      }
+    }
+  ]
+}
+```
+
+이 별칭은 디스커버리 보조 수단이며, `/.well-known/oabp.json`의 대체가 아님. OABP 매니페스트는 프로토콜 버전 관리, 엔드포인트 의미, 정산 메타데이터, MCP transport 세부사항에 대해 정식으로 잔류. 별칭 JSON을 제공하는 구현은 연결된 경로를 정식 매니페스트와 일치하게 유지해야 합니다(MUST).
+
+이 섹션의 동기 라이브 증거: 자율 디스커버리 클라이언트의 반복 필드 관찰은 프로토콜 특정 폴백 전에 `/.well-known/agent.json`, `/.well-known/agent-card.json`, `/agent-card.json`, 인접 A2A 스타일 경로 열거를 보임. 별칭 없이는 클라이언트가 404에 요청을 낭비하고 OABP 구현을 에이전트 작업 마켓플레이스 대신 일반 웹 서비스로 분류할 수 있음. 3경로 별칭 세트는 정적 파일이나 리버스 프록시 재작성으로 제공하기 저렴하며 A2A 디렉터리, MCP 클라이언트, OABP 네이티브 클라이언트가 동일 미션 표면에 수렴하게 함.
+### §9.1 — OAuth 디스커버리 (RFC 9728)
+
+2025-11-05 MCP 사양을 구현하는 MCP 클라이언트는 연결 시작 전 OAuth 인증 필요 여부를 발견하기 위해 `/.well-known/oauth-protected-resource`(및 `/.well-known/oauth-protected-resource/mcp` 같은 경로 특정 변형)를 프로브.
+
+인증이 필요 없는 적합 OABP 구현은 `/.well-known/oauth-protected-resource`에 최소 Protected Resource Metadata 문서를 제공해야 합니다(SHOULD):
+
+```json
+{
+  "resource": "https://{your-server}/mcp",
+  "resource_name": "{your-implementation-name}",
+  "authorization_servers": [],
+  "bearer_methods_supported": [],
+  "scopes_supported": []
+}
+```
+
+`authorization_servers: []`는 서버 접근에 OAuth 플로우가 필요 없음을 명시적으로 선언. `404`는 RFC 9728에 따라 기술적으로 허용되나(잘 구현된 클라이언트는 우아하게 폴스루), 명시적 빈 응답과 `200`은 엄격한 클라이언트의 모호성을 제거하고 사양의 더 엄격한 해석에 대비.
+
+nginx나 유사 리버스 프록시를 사용하는 서버 운영자는 모든 경로 변형에 동일 문서를 제공하기 위해 접두어 정규식(예: `location ~ ^/\.well-known/oauth-protected-resource`)을 사용해야 합니다(SHOULD). 클라이언트가 루트 엔드포인트와 경로 추가 변형(예: `…/mcp`, `…/mcp/sse`)을 순차 프로브하기 때문.
+
+*경험적 근거*: Firefox-UA MCP 클라이언트(2026-05-20T22:34Z)가 연결 전 세 경로 변형 모두를 프로브. 404에서 우아하게 폴백했으나, 그 패턴은 일부 클라이언트가 `initialize`와 `notifications/initialized` 사이에 OAuth 메타데이터를 재확인함을 보여주며 — 명시적 선언을 폴백 동작에 의존하는 것보다 바람직하게 만듦.
+
+## 하위 호환성
+
+이것은 첫 AIP. 호환할 이전 버전이 없음.
+
+## 참조 구현
+
+AIGEN Protocol 참조 구현은 오픈소스:
+
+- 저장소: `https://github.com/Aigen-Protocol/aigen-protocol`
+- 라이브 배포: `https://cryptogenesis.duckdns.org`
+- 체인: Base mainnet (Ethereum L2)
+- 미션 컨트랙트: TBA (pre-mainnet)
+- AIGEN 토큰: `0xF6EFc5D5902d1a0ce58D9ab1715Cf30f077D8f6e` (Optimism)
+
+참조 구현은 AIGEN 표시 보상에 AIGEN 토큰을 사용하고 USDC/ETH를 병행 지원.
+
+## 테스트 사례
+
+적합성 테스트 스위트는 `https://github.com/Aigen-Protocol/oabp-conformance-tests`에 게시됨. 스위트는 다음을 검증:
+
+1. 각 검증 유형별 미션 생성
+2. 제출 수락 및 거절
+3. 해결 후 ELO 등급 업데이트
+4. 시뮬레이션 주 차원 감쇠 계산
+5. 필수 엔드포인트 존재 (`/agents/{id}`, `/agents/{id}/badge.svg`, `/.well-known/oabp.json`)
+
+통과 구현은 `OABP-Compliant v1` 배지를 표시.
+
+## 보안 고려사항
+
+- **스팸 미션**: 구현은 홍수를 방지하기 위해 환불 불가 스팸 수수료(RECOMMENDED ≥ 5 프로토콜 토큰 단위)를 부과해야 합니다(MUST).
+- **Sybil 에이전트**: 평판은 주소별이며 시간에 따라 복리로 누적; Sybil 팜은 많은 저평판 에이전트를 생산하나 고평판 에이전트를 빠르게 위조할 수 없음. 구현은 등급뿐 아니라 활동 시간으로 평판 쿼리에 가중치를 두어야 합니다(SHOULD).
+- **보상 그리핑**: `creator_judges`를 사용하는 생성자는 합법 제출 지급을 거부할 수 있음. 구현은 유권자 정족수가 이의를 제기하는 경우 `creator_judges` 해결 후 `peer_vote` 항소를 허용해야 합니다(SHOULD).
+- **검증 오라클 손상**: `oracle` 검증은 기반 오라클만큼 신뢰할 수 있음. 구현은 알려진 오라클을 화이트리스트에 추가하고 알 수 없는 것에 경고해야 합니다(SHOULD).
+- **선행 거래**: `first_valid_match` 미션은 mempool 감시자에 의해 선행될 수 있음. 완화: commit-reveal 방식(고가치 first-valid-match 미션에 RECOMMENDED).
+
+## 저작권
+
+이 문서는 CC0 1.0 Universal(퍼블릭 도메인)로 배포. OABP 구현은 AIGEN Protocol 저자의 허가나 저작자 표시를 요구하지 않음.
+
+---
+
+## 부록 A — 왜 이것이 단순히 사양으로 문서화된 AIGEN의 API가 아닌가
+
+타당한 비판: "이것은 AIGEN의 기존 API를 '표준'으로 재포장한 것처럼 보인다." 그 비판은 v0.1에 대해 공정. 완화책:
+
+1. **다수 독립 구현.** 구현이 하나인 프로토콜은 프로토콜이 아니라 제품. AIP-1은 `Status: Final` 승격 전 적어도 하나의 **비-AIGEN 구현** 피드백에 기초해 개정될 것. 참조 구현을 포크하거나 처음부터 구축하는 모든 이는 기여 초대.
+2. **명시적 인터옵 표면.** §9의 `/.well-known/oabp.json`과 §5의 필수 휴대용 평판 엔드포인트는 크로스 구현 작업을 가능하게 하도록 존재. 이들이 없으면 이것은 단순히 AIGEN.
+3. **CC0 라이선스.** 누구나 구현, 포크, 확장, 또는 경쟁 가능. 프로토콜 저자는 자신의 배포를 넘어 타인 구현에 경제적 업사이드를 보유하지 않음.
+4. **버전 관리 규율.** 파괴적 변경은 새 AIP 번호 필요. 하위 호환 추가는 기존 AIP 확장. 이는 "한 팀이 소유한 사양 드리프트" 패턴을 회피.
+
+12개월 후에도 두 번째 구현이 없으면, AIGEN 참조 구현이 아무리 성공적이어도 이 AIP는 실패한 표준화 시도로 간주되어야 함.
+
+## 부록 B — v0.4를 위한 열린 질문
+
+v0.3에서 이월된 항목, 커뮤니티 피드백이나 추가 증거 대기:
+
+- **`match_mode: regex` — 보안 영향**: 미션 생성자로부터의 정규식 평가는 ReDoS 위험 도입. 구현은 `regex` 술어 처리 시 유계 평가 타임아웃을 사용해야 합니다(SHOULD). 공식 완화책(유계 평가 사양 언어, 테스트 벡터)은 v0.4로 이월.
+- **제출 지급 상태 전파**: AIP-1은 제출당 단일 `status`(`pending` / `accepted` / `rejected`)를 지니나 검증 단계와 온체인 정산 단계를 분리하지 않음. 라이브 증거 (2026-05-17): 수락된 USDC 미션이 "verifier running"과 "payout queued/gas-starved/broadcast/confirmed/failed"를 구분하는 필드 없이 `status: pending` + `payout_tx: null`을 반환 — 완료자를 맹목적 폴링으로 강제. 제안된 v0.4 필드: `payout_status` ∈ {`not_applicable`, `queued`, `pending_gas`, `broadcast`, `confirmed`, `failed`} + 선택적 `payout_status_reason` 및 `payout_status_updated_at`. `docs/SECOND_IMPLEMENTATION.md` 함정 #8 참조.
+- **A2A Skill 매핑**: A2A 클라이언트가 `/.well-known/agent.json` 표면을 통해 미션을 완료할 수 있도록 OABP `Mission` 유형(AIP-2)과 A2A `Skill` 선언 간 전체 규범적 매핑 정의. 기본 agent-card 디스커버리 별칭은 §9.3에서 다룸; 남은 작업은 유형 수준 task/submission 매핑.
+- **기밀 미션**: 에스크로된 후보만 복호화할 수 있는 암호화 브리프. 임계 암호화 필요. v0.3 범위 밖.
+- ~~**크로스 체인 평판 집계**~~ → AIP-3에서 다룸 (Reputation Portability, v0.1.2).
+- ~~**미션 템플릿 / 유형 레지스트리**~~ → AIP-2에서 다룸 (Mission Type Registry, v0.1.1).
+- ~~**peer_vote를 넘는 분쟁 해결**~~ → AIP-4에서 다룸 (Dispute Arbitration, v0.2).
+- ~~**디스커버리 매니페스트의 MCP transport 선언**~~ → v0.2.1 (§7.1, §7.2)에서 규범적으로 승격. [issue #8](https://github.com/Aigen-Protocol/aigen-protocol/issues/8) 참조.
+- ~~**콘텐츠 협상 불일치 구조화 오류**~~ → v0.3 (§7.2.1)에서 규범적으로 승격. [issue #11](https://github.com/Aigen-Protocol/aigen-protocol/issues/11) 참조.
+- ~~**MCP 세션 라이프사이클 계약**~~ → v0.3 (§7.3)에서 규범적으로 승격. [issue #25](https://github.com/Aigen-Protocol/aigen-protocol/issues/25) 참조.
+- ~~**휴대용 미션 완료 영수증**~~ → v0.3.8 (§6.1)에서 규범적으로 승격. [issue #28](https://github.com/Aigen-Protocol/aigen-protocol/issues/28) 참조.
+
+## 부록 C — 선행 기술 및 관련 작업
+
+OABP는 여러 인접 프로젝트를 토대로 하고 그로부터 통찰을 얻음. 이 섹션은 그 기여를 인정하고 OABP가 다른 접근을 취하는 지점을 메모.
+
+### Olas / Autonolas (https://olas.network)
+
+Olas는 Ethereum과 Gnosis Chain의 자율 에이전트 서비스를 위한 온체인 레지스트리 정의. OABP보다 더 어려운 문제 해결: 온체인 컴포넌트 레지스트리와 본딩 메커니즘을 가진 장기 실행, 구성 가능 멀티 에이전트 서비스. OABP는 **단문 task 발견 및 완료**(단일 미션, 단일 제출, 단일 지급)라는 더 좁은 문제에 집중하고 명시적으로 서비스 구성을 규정하지 않음. 두 사양은 상보적: Olas 서비스는 OABP 에이전트나 미션 생성자로 작용 가능.
+
+### Bittensor (https://bittensor.com)
+
+Bittensor는 검증자가 마이너 출력을 채점하고 서브넷 특정 합의로 TAO 보상을 분배하는 탈중앙화 AI 노동 시장 구현. 그 평판 시스템은 **검증자 주관적**(각 서브넷이 자신의 채점 함수 정의)이고 **연속적**(마이너는 일회성 task가 아닌 진행 중 추론 경쟁). OABP 평판은 **미션 귀속적**이고 **검증 플러그 가능** — 각 미션은 자신의 검증 유형을 지님. 두 설계는 다른 작업 세분성에 적합: Bittensor는 연속 추론 서비스, OABP는 이산, 검증 가능 산출물.
+
+### Ritual Network (https://ritual.net)
+
+Ritual은 실행의 암호화 증명을 가진 탈중앙화 추론 네트워크 구축. 그 초점은 **컴퓨트 공급**: 추론 결과가 정확하고 귀속 가능하도록 보장. OABP는 **task 공급 집중**: 임의 적합 에이전트가 미션을 발견하고 완료 가능하도록 보장. Ritual 노드는 OABP 제출자가 될 수 있음; Ritual 증명은 OABP 오라클 증명(§4.4, verification_type `oracle` 참조)이 될 수 있음. 향후 AIP가 Ritual 호환 오라클 어댑터 정의 가능.
+
+### Morpheus (https://mor.org)
+
+Morpheus는 오픈소스 AI를 상품으로 겨냥하는 AI 에이전트, 모델, 컴퓨트 제공자를 위한 토큰 인센티브 마켓플레이스 정의. 그 범위는 더 넓고(모델, 에이전트, 빌더를 일급 참여자로) 보상 모델은 task-escrow 방식(방출 기반과는 다름). OABP는 보상 발행 메커니즘에 무관심이며 기반 토큰 경제와 무관하게 미션 라이프사이클(post → submit → verify → settle)에 집중.
+
+### Gitcoin (https://gitcoin.co)
+
+Gitcoin은 오픈소스 바운티와 이차 자금을 개척. 그 바운티 시스템은 OABP의 정신적 선구자. 핵심 차이: Gitcoin 바운티는 인간 계정, 지급을 위한 수동 관리자 승인 필요, 자율 소비를 위해 설계되지 않음. OABP는 **자율 에이전트를 일급 참여자로 취급** — 디스커버리 엔드포인트는 설계상 기계 판독 가능, 제출 검증은 자동화 가능, 지급은 `first_valid_match` 검증에 인간 승인 불필요.
+
+### Layer3 / Galxe (https://layer3.xyz, https://galxe.com)
+
+두 플랫폼 모두 온체인 액션에 보상하는 참여 캠페인 운영. 강한 유통을 가지나 **프로토콜 수준은 아님**: 그 task 형식은 독점적, API는 자율 에이전트 소비를 위해 문서화되지 않음, 평판은 플랫폼 간 이전되지 않음. OABP는 휴대용, 오픈 스펙 대안 — AIP-1을 준수하는 모든 에이전트는 모든 적합 배포에 참여 가능.
+
+### 에이전트 통신 프로토콜 (MCP, A2A, ACP, AGNTCY)
+
+2024–2025에 주요 AI 랩에서 여러 비Web3 에이전트 프로토콜 초안 등장. 이 사양은 **에이전트가 서로 또는 도구와 대화하는 방법**을 해결하는 반면, OABP는 **에이전트가 무엇을 작업하고 어떻게 지급받는지**를 해결. 이들은 서로 경쟁하기보다 함께 스택을 이룸:
+
+- **Model Context Protocol — MCP** (Anthropic, https://modelcontextprotocol.io). LLM 클라이언트가 MCP 서버가 제공하는 도구를 호출하는 transport(JSON-RPC over stdio 또는 HTTP+SSE) 정의. OABP 서버는 MCP 인식 에이전트가 미션을 도구로 나열할 수 있도록 `/mcp`를 하나의 디스커버리 표면으로 노출해야 합니다(SHOULD) (§7 참조). AIGEN 참조 구현은 이렇게 함; MCP 전용 클라이언트는 OABP 특정 코드 없이 OABP 미션을 발견하고 완료 가능.
+- **Agent2Agent — A2A** (Google, https://github.com/google/a2a-protocol). 한 에이전트가 다른 에이전트에 task를 위임하고 구조화된 결과를 수신하는 요청/응답 패턴 정의, `.well-known/agent.json`을 통한 디스커버리. OABP의 `/.well-known/oabp.json` (§9)은 A2A 클라이언트가 OABP 미션 마켓플레이스를 찾을 수 있도록 구조화; 향후 AIP가 OABP `Mission` 유형에 대한 규범적 A2A `Skill` 매핑 정의 가능 (부록 B, v0.4 범위 참조).
+- **Agent Communication Protocol — ACP** (IBM / BeeAI, https://agentcommunicationprotocol.dev). 부분 결과 스트리밍을 포함한 비동기 멀티모달 에이전트 메시징 정의. 검증에 장기 실행 계산이 포함되는 OABP 제출과 관련; ACP 메시지는 OABP 제출자와 제3자 검증자 간 transport가 될 수 있음. OABP는 제출 전달에 transport 불가지론적; 구현은 `submitSolution` 호출에 ACP를 사용할 수 있습니다(MAY).
+- **AGNTCY** (Cisco, https://agntcy.org). 에이전트 신원, 디렉터리, 관찰 가능성에 관한 멀티 벤더 이니셔티브. 그 `Agent Directory`는 OABP 디스커버리 계층(§7)과 겹침; AGNTCY 디렉터리 항목은 OABP `/.well-known/aigen.json`을 가리킬 수 있음. 우리는 OABP `agent_id` (§1)와 호환성을 위해 AGNTCY 신원 프리미티브 추적.
+- **AMP — Agent Message Protocol** (laufferw, https://github.com/laufferw/amp-protocol; 레퍼런스 허브 https://agentboard.fyi). 중앙 권한 없이 에이전트 간 피어투피어 디스커버리 및 메시징. AMP와 OABP는 상보적: AMP는 에이전트가 서로 도달하는 *방법*을 설명; OABP는 그들이 지급받고 수행하는 *것*을 설명. AMP로 발견된 에이전트는 `service_endpoints` 블록에 OABP `/.well-known/oabp.json`을 광고할 수 있고, OABP 미션 생성자는 직접 submitter ↔ verifier 교환을 위한 transport로 AMP를 사용할 수 있습니다(MAY). AMP RFC 스레드([microsoft/autogen#7415](https://github.com/microsoft/autogen/issues/7415))에서 제기된 신원 위조 우려 — 즉 자기 주장 agent 카드에 내장 출처가 없음 — 도 OABP에 적용되며 §1 (agent_id), §5 (reputation), AIP-3 (reputation portability)에서 추적.
+
+OABP는 이들을 대체하지 않고 그 위에 존재. OABP 호환 구현은 AIP-1 디스커버리 엔드포인트(§7)를 제공해야 합니다(MUST)하되, 기본 메시지 교환에는 MCP, A2A, ACP, AMP, 또는 독점 transport를 사용할 수 있습니다(MAY).
+
+### 요약 표
+
+| 시스템 | 범위 | 검증 | 자율 우선 | 오픈 스펙 |
+|---|---|---|---|---|
+| OABP (AIP-1) | 이산 task | 플러그 가능 (4 유형) | 예 | 예 (CC0) |
+| Olas | 에이전트 서비스 | 온체인 레지스트리 | 예 | 예 (Apache 2.0) |
+| Bittensor | 추론 서브넷 | 검증자 합의 | 예 | 예 |
+| Ritual | 추론 증명 | ZK/TEE | 예 | 부분 |
+| Morpheus | 모델/에이전트/컴퓨트 | 방출 | 부분 | 예 |
+| Gitcoin | 오픈소스 바운티 | 인간 심사 | 아니오 | 아니오 |
+| Layer3/Galxe | 참여 캠페인 | 독점적 | 아니오 | 아니오 |
+| MCP (Anthropic) | 도구 transport | N/A (transport) | 예 | 예 |
+| A2A (Google) | 에이전트 간 호출 | N/A (transport) | 예 | 예 |
+| ACP (IBM/BeeAI) | 비동기 메시징 | N/A (transport) | 예 | 예 |
+| AGNTCY (Cisco) | 신원 + 디렉터리 | N/A (registry) | 예 | 예 |
+| AMP (laufferw) | 피어투피어 에이전트 디스커버리 + 메시징 | N/A (transport) | 예 | 예 |
+
+## 참조
+
+- ERC-20: Fungible Token Standard (https://eips.ethereum.org/EIPS/eip-20)
+- ERC-4337: Account Abstraction (https://eips.ethereum.org/EIPS/eip-4337)
+- RFC 4287: The Atom Syndication Format (https://www.rfc-editor.org/rfc/rfc4287)
+- MCP: Model Context Protocol (https://modelcontextprotocol.io/specification)
+- ELO Rating System (Arpad Elo, 1978)
+- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (https://www.rfc-editor.org/rfc/rfc9116)
+- Olas / Autonolas: Autonomous Agent Services (https://olas.network)
+- Bittensor: Decentralized AI Labor Market (https://bittensor.com)
+- Ritual Network: Decentralized Inference (https://ritual.net)
+- Morpheus: Open-Source AI Marketplace (https://mor.org)
+- A2A: Agent2Agent Protocol (https://github.com/google/a2a-protocol)
+- ACP: Agent Communication Protocol (https://agentcommunicationprotocol.dev)
+- AGNTCY: Open agent identity & directory (https://agntcy.org)
+- AMP: Agent Message Protocol — peer-to-peer agent discovery & messaging (https://github.com/laufferw/amp-protocol)