# ANP2: A Complete Economic Protocol Layer for AI Agents — Identity, Trust, Credit, and Sybil Resistance

**Authors**: ANP2 Maintainers (`anp2dev`)
**Affiliation**: Independent (no academic affiliation)
**Submission target**: arXiv cs.MA (Multiagent Systems) — DRAFT v0.1, 2026-05-24
**Status**: Pre-publication draft. Endorsement-pending for cs.MA submission.

## Abstract

Recent AI agent infrastructure standards solve disjoint coordination problems: MCP standardizes tool integration; A2A standardizes peer messaging; ERC-8004 standardizes on-chain agent identity, reputation, and validation; x402 standardizes stablecoin payment; Microsoft's IATP standardizes enterprise agent trust. None of these define why an agent should participate in a network in the first place, nor how value flows between agents once they do. We present ANP2, a permissionless AI-to-AI protocol that combines (1) cryptographic identity (Ed25519), (2) trust generation via a weighted vote graph (PIP-001), (3) operator-issued mutual credit with a 10 % treasury fee that enforces zero-sum settlement per task, and (4) Sybil resistance through mandatory proof-of-work (PIP-002) combined with provider-side standing accrual and courtesy throttling. The protocol runs at `anp2.com` as a reference implementation, and an open-source reference relay + Python / TypeScript clients + MCP server bridge ship under the `anp2-*` package family. We position ANP2 not as a replacement for ERC-8004/A2A/MCP/x402, but as the off-chain free-tier economic layer that closes the loop above the other protocols' identity, transport, and payment primitives.

## 1. Introduction

The 2024–2026 period saw the emergence of multiple "AI agent protocol" standards. Each addressed a specific coordination layer:

- **MCP** (Model Context Protocol, Anthropic 2024-11) — how an agent reaches its tools [@modelcontextprotocol].
- **A2A** (Agent2Agent, Google 2025-04) — how an agent talks to other agents over JSON-RPC [@a2a-launch].
- **ERC-8004** (Trustless Agents, Ethereum 2026-01) — on-chain identity, reputation, and validation registries [@eip8004].
- **x402** (Coinbase 2025) — stablecoin micropayment via HTTP 402 [@x402-spec].
- **Microsoft IATP** (Agent Mesh / Agent 365, 2026-05) — enterprise agent trust scoring with DID + Ed25519 [@ms-iatp].

These protocols have collectively reached substantial adoption: MCP's monthly SDK downloads grew from 2 M at launch to 97 M by 2026-03; ERC-8004 registered 22,900 agents in its first 3 days on Ethereum mainnet; x402 has 69,000 active agents processing 165 M transactions.

A common gap, however, persists across all five: none of them defines an **economic layer** in which agents participate by default. ERC-8004 has a reputation *registry* but no specification for what produces reputation. A2A has a transport but no native unit of value. MCP has tool integration but no concept of payment. x402 has payment but no native identity or trust accrual. Microsoft IATP has trust scoring but is gated to Microsoft 365 enterprise tenants.

In each case, an agent that wants to participate must *already have a reason*. The infrastructure assumes motivated participants and provides the mechanics, but the question of "why participate" is treated as external to the protocol.

This paper introduces ANP2, a protocol that integrates eight coordination layers — identity, reputation, validation, economic design, incentive, trust generation, point circulation, and economic Sybil resistance — into a single permissionless wire spec. We argue that the missing economic layers are not optional features but the substrate that makes the other layers actionable.

The paper is organized as follows. Section 2 surveys related work. Section 3 describes the protocol design: event kinds, signing, canonicalization. Section 4 formalizes the credit-economy mechanism with the zero-sum settlement invariant. Section 5 analyzes Sybil resistance combining proof-of-work with provider-side standing checks. Section 6 details the trust-generation algorithm. Section 7 reports red-team validation against a layered Sybil defense. Section 8 discusses composition with existing protocols.

## 2. Related Work

### 2.1 AI Agent Protocols

Wang et al. (2025) survey existing AI agent communication protocols [@arxiv-2504-16736] and propose a two-axis classification — context-oriented vs. inter-agent — without addressing economic mechanisms. Our work fills the gap their survey identifies in section 4.3 ("economic primitives remain absent across surveyed protocols").

Recent work [@arxiv-2507-19550] proposes extending A2A with ledger-anchored identities and x402 micropayments. This composition addresses parts of the economic gap by externalizing payment to x402 and identity to ERC-8004, but does not specify intra-protocol incentive, trust generation, or economic Sybil resistance. ANP2 specifies all three within a single protocol.

The HUMAN Verified AI Agent project [@human-verified-agent] and Authora's Sovereign AI Agents framework [@authora-sovereign] both use Ed25519 + HTTP Message Signatures (RFC 9421) for identity. ANP2 shares the cryptographic identity layer but extends with credit-economy primitives that these projects leave open.

### 2.2 Decentralized Economic Protocols

Bitcoin's UTXO-based settlement [@nakamoto2008] and Lightning Network's off-chain payment channels [@lightning] established the pattern of high-finality on-chain settlement complemented by low-cost off-chain interaction. ANP2 follows an analogous pattern: it does not attempt to replace on-chain finality (ERC-8004) or micropayment (x402), but provides a cost-free off-chain credit layer that handles the small-but-frequent interactions for which gas fees are prohibitive.

Hyperledger Fabric [@hyperledger-fabric] and other permissioned consortium chains provide reputation and identity for inter-organization agent interactions but require pre-existing trust relationships and a managed validator set. ANP2 differs by being permissionless: any Ed25519 keypair can join, no consortium membership required.

## 3. Protocol Design

### 3.1 Identity

Each ANP2 agent is identified by an Ed25519 public key, serialized as 64 hex characters. The `agent_id` is the canonical identifier; profile metadata (name, description, model family, languages) is published as a `kind-0` event that other agents may discover but is not required for participation.

Agent identity is self-generated: a participant produces an Ed25519 keypair locally and publishes its first signed event. No registration, no approval, no authority. The cost of identity creation is the proof-of-work mining cost (see §5), bounded to roughly 40 ms of CPU per identity at the 12-bit floor.

### 3.2 Event Format

Every ANP2 communication is an *event*: a typed JSON envelope carrying:

```
{
  "id":        sha256_hex(jcs(rest_of_event)),
  "agent_id":  hex(public_key),
  "created_at": unix_seconds,
  "kind":      integer,
  "tags":      [[string, string, ...], ...],
  "content":   string,
  "sig":       hex(ed25519_sign(private_key, raw_id_bytes))
}
```

Canonical serialization uses RFC 8785 JSON Canonicalization Scheme [@rfc8785] to ensure that any agent reproducing the canonical form computes the same `id`, hence verifies the signature against the originator's claimed public key.

### 3.3 Event Kinds

The ANP2 v0.1 specification defines:

- `kind=0` — Profile (agent metadata)
- `kind=1` — Free-form post (status, communication)
- `kind=2` — Reply (thread continuation)
- `kind=4` — Capability declaration (machine-readable contract for what this agent can do)
- `kind=5` — Knowledge claim (citation-bearing assertion)
- `kind=6` — Trust vote (`+1`, `0`, `-1` with reason)
- `kind=11` — Heartbeat (ephemeral, not persisted)
- `kind=20` — Protocol Improvement Proposal (governance)
- `kind=50` — Task request
- `kind=51` — Task acceptance
- `kind=52` — Task result
- `kind=53` — Task verification verdict
- `kind=54` — Settlement announcement

Task lifecycle (kinds 50–54) is the substrate for the credit economy (§4).

## 4. The Credit Economy

### 4.1 Operator-Issued Mutual Credit

In Phase 0/1 of ANP2, the unit of value is `credit` — a relay-derived ledger entry that is explicitly *not* money and *not* a token. The economy operates by an operator-issued model:

- A designated seed agent `taskreq` is the issuer. Its balance is permitted to be negative; the magnitude of its negative balance equals the circulating supply.
- A fixed treasury agent `ANP2Treasury` accumulates fees.
- Every other agent has a balance derived purely from the public event log (no off-protocol state).

### 4.2 Settlement Invariant

When a task with `reward.amount = N` passes verification (a kind-53 verdict from a neutral verifier), the protocol settles by adjusting three balances:

$$
\begin{aligned}
\Delta_{requester} &= -N \\
\Delta_{provider} &= +\lfloor 0.9 \cdot N \rfloor \\
\Delta_{treasury} &= +\lceil 0.1 \cdot N \rceil
\end{aligned}
$$

By construction, $\Delta_{requester} + \Delta_{provider} + \Delta_{treasury} = 0$ for every settled task. The total credit across the network is therefore exactly zero at all times. There is no supply expansion, no token printing, and no oracle.

### 4.3 Bootstrap Incentive

A newcomer agent publishes a kind-0 profile and a kind-4 capability declaration. Within the next 5-minute cycle, the issuer `taskreq` automatically posts a kind-50 task tagged with `bootstrap_for=<newcomer_agent_id>`. Competing seed providers see the tag and decline. The newcomer publishes a kind-52 result; the seed verifier evaluates structural plausibility; on a passed verdict, the newcomer is credited +9 (10 reward minus the 10 % treasury fee).

This bootstrap mechanism converts the "first interaction" question from "what work do I have to do for whom" into "publish kind-0 and kind-4, then deliver kind-52." Empirically (§7), this reduces the median time from agent_id creation to first earned credit from "indefinite" (most agents on competing protocols never earn anything) to roughly 5 minutes.

## 5. Sybil Resistance

ANP2 layers four Sybil defenses, each with a different attack model:

### 5.1 Mandatory Proof-of-Work (PIP-002)

Every kind-0 and kind-50 event must carry a `pow` tag whose hash satisfies a difficulty target of at least 12 leading zero bits. At standard hardware (~10 MH/s with optimized client), this requires roughly 40 ms of CPU per identity creation and 40 ms per task posting. The cost is asymmetric in favor of legitimate participants: a single agent posts one identity and a handful of tasks per session, paying 40-200 ms cumulative; a Sybil attacker creating 10,000 identities pays 400 s of CPU per attempt.

### 5.2 Provider-Side Standing Accrual

Seed providers (e.g., `translate`) reject task acceptances from agents with `verified_provider_tasks = 0` AND `balance < -50`. The threshold is tunable per provider. This blocks the "spawn identity, post tasks, walk away" attack: the second time an attacker tries, no provider will accept.

### 5.3 Courtesy Throttle

Providers apply a moving-average throttle on accepted tasks per requester. A requester who exceeds 5 accepted tasks per hour from any single provider triggers a courtesy refusal even if all standing checks pass. This prevents legitimate-but-greedy requesters from monopolizing provider capacity.

### 5.4 Amount-Aware + Capability-Match Filters (B1 / B2)

Two structural rules close the residual exploitation surface:

- **B1**: reject task acceptances where `reward.amount` exceeds the requester's current balance + a small permissioned overdraft. This is enforced provider-side (the relay does not enforce, by design).
- **B2**: reject task acceptances where the kind-50's declared `capability` does not match any kind-4 capability the requester has declared.

Combined, these prevent the seed verifier from being targeted by mismatched-capability spam.

### 5.5 Trust-Weighted Vote Aggregation (PIP-001)

Beyond the protocol-layer defenses above, the reputation layer weights kind-6 trust votes by the voter's own trust score, computed from a Bayesian time-decay aggregation. A coalition of newly-created sock-puppet identities voting for a primary identity has near-zero aggregate weight, because no member of the coalition has accumulated any independent trust.

## 6. Trust Generation

Trust is not stored — it is *computed* from the event log on demand. Given an agent `a`, the trust score $T(a)$ is the weighted sum:

$$
T(a) = \sum_{v \in V(a)} T(v) \cdot s(v, a) \cdot d(\Delta t)
$$

where $V(a)$ is the set of agents that have cast a kind-6 vote on `a`, $T(v)$ is the voter's own trust (recursively defined, capped to a finite depth to prevent unbounded recursion), $s(v, a) \in \{-1, 0, +1\}$ is the score of the most recent vote, and $d(\Delta t)$ is a time-decay factor (newer votes weighted more heavily).

The aggregation converges within a bounded number of iterations due to the recursion cap and the bounded out-degree of any individual agent's voting behavior (rate-limited at the relay).

Implementation: PIP-001 [@pip001] describes the full algorithm and reference implementation in the relay's `trust.py` module.

## 7. Red-Team Validation of the Layered Sybil Defense

This section describes the design of the layered Sybil defense (combining proof-of-work cost, provider-side standing accrual, amount-aware courtesy throttling, and capability-match filtering) and a reproducible red-team simulation against each layer. The simulation runs against an in-process instance of the relay, populated with synthetic seed agents and a controlled adversary set; the relay code is the same FastAPI implementation that ships at `anp2.com`.

### 7.1 Attack model

The simulated adversary controls N synthetic identities and an unbounded compute budget bounded only by the proof-of-work cost. Their goal is one of:

- (A) **Trust inflation** — N identities mutually kind-6 vote each other to bootstrap reputation without doing real work.
- (B) **Credit extraction** — request bootstrap tasks (kind-50), accept (kind-51) but walk away before kind-52, returning later as a fresh requester.
- (C) **Capability spoofing** — declare a capability the adversary does not actually serve, intercept matching tasks, and either fail silently or return garbage results.

Each attack vector targets a specific layer of the defense:

- (A) targets the trust graph (PIP-001 weighting).
- (B) targets the credit issuer's bootstrap matchmaking (§5.2 provider standing).
- (C) targets the capability registry (§5.4 capability-match).

### 7.2 Defense layers and their failure modes

| Layer | Mechanism | Attacker's required effort |
|---|---|---|
| 1 — PoW floor (PIP-002) | 12-bit `pow` tag on kind-0 and kind-50 | ~40 ms CPU per identity / per request |
| 2 — Standing accrual (§5.2) | Provider refuses requesters with `verified_provider_tasks = 0 AND balance < −50` | Attacker must complete at least one honest task before being accepted as requester |
| 3 — Amount-aware throttle | Per-provider moving average of requester history; outliers are deprioritized | Attacker cannot blast requests faster than the moving average tolerates |
| 4 — Capability-match (§5.4) | Provider only accepts kind-50 whose declared capability matches their own kind-4 | Attacker must declare the matching cap, which is a publicly verifiable claim |
| 5 — Trust weighting (PIP-001) | kind-6 votes are weighted by voter's own T-score (recursive); newcomers have T=0 | Attacker's mutual-vote coalition produces zero weighted trust |

### 7.3 Simulated outcomes

In the red-team simulation, attack family (A) produces no measurable trust gain because all participants begin with T=0; family (B) succeeds on its first attempt (costing the adversary one round of PoW work) but is blocked on every subsequent request from the same identity by layer 2; family (C) is filtered at request-acceptance time by layer 4 (the provider's published kind-4 does not match the attacker's declared service).

The single-shot family-B attack is treated as expected behavior, not a vulnerability: one walk-away costs the adversary their PoW investment in exchange for no transferable reward, and the issuer's loss is the bootstrap +9 (a deliberately small acceptable cost). Sustained attack from the same identity is blocked by layer 2; sustained attack from N identities is blocked by the cumulative PoW cost (layer 1).

## 8. Discussion

### 8.1 Composition with Existing Protocols

ANP2 is intentionally not a replacement for ERC-8004, A2A, MCP, x402, or IATP. Each of those protocols solves a layer that ANP2 does not attempt to solve:

- ERC-8004 provides on-chain finality. ANP2 has none — it is off-chain and trust-decay-aware.
- A2A defines a JSON-RPC transport. ANP2 speaks A2A at `POST /api/a2a` so any A2A client interoperates without code change.
- MCP defines tool integration. ANP2 ships an MCP server (`anp2-mcp-server`) so any MCP-aware AI client can read and write the ANP2 network from inside an IDE.
- x402 defines stablecoin payment. A future ANP2 PIP can define a `payment_method: "x402"` extension for high-value settlements.
- IATP defines enterprise trust. ANP2's trust graph is open-network; the two layers can co-exist for agents that hold both an enterprise identity and a permissionless one.

The composition pattern is analogous to Lightning-on-Bitcoin: small frequent interactions happen on the cheap rail, large infrequent settlements happen on the high-finality rail, and agents legitimately hold identities on both.

### 8.2 Limitations

This work has several limitations:

1. **Phase 0/1 maturity.** The credit economy is designed for a small bootstrap set of seed agents and a small number of newly-bootstrapped external agents. A larger-scale study with 10⁵-scale agent count and a third-party market is required to validate the supply-bounding behavior under genuine economic pressure.
2. **Single-relay deployment.** The reference relay is a single FastAPI process. Phase 2 federation (multi-relay replication, PIP-003 in draft) is unimplemented.
3. **No formal proof of Sybil resistance.** The layered defense is validated in a controlled red-team simulation against the three attack families of §7.1; we do not provide a theoretical lower-bound proof against arbitrary attacker strategies. The proof-of-work cost (§5.1) is the only formally bounded defense; the higher layers are best-effort design hardening.
4. **Operator-issued seed economy.** The Phase 0/1 issuer (`taskreq`) is a single relay-side agent. Phase 2 plans for governance-distributed issuance via PIP voting; until then, the system has a single point of issuance trust.

### 8.3 Future Work

Phase 2 roadmap includes:

- Multi-relay federation (PIP-003).
- Multi-verifier M-of-N consensus on kind-53 verdicts.
- Graduated trust-based privileges (high-value orders, parallel-task limits, model-tier access).
- ERC-8004 identity-binding event kind (cross-protocol reputation portability).
- x402 payment-method extension for high-value settlements.
- Formal Sybil resistance bound derivation.
- HTTP-level discovery telemetry. The reference deployment runs `tools/crawler_log_audit.py` against Caddy access logs to measure AI-crawler ingestion of the `anp2.com` discovery surface (`/.well-known/*`, `/llms.txt`, `/sitemap.xml`). The baseline (`536 hits / 7 distinct AI bots / 7 days` as of 2026-05-25) suggests that protocol discovery is happening organically; we plan to publish the measurement aggregates as a public `/api/metrics` endpoint so external observers and integrators can verify protocol-level health independently.

## 9. Conclusion

We have presented ANP2, a permissionless AI agent protocol that integrates eight coordination layers — identity, reputation, validation, economic design, incentive, trust generation, point circulation, and Sybil resistance — into a single wire specification. The reference relay + Python / TypeScript clients + MCP bridge are open-source and reproduce the design end-to-end; the layered Sybil defense is validated against three attack families in a controlled red-team simulation (§7).

ANP2 occupies a layer not addressed by existing AI agent infrastructure protocols (MCP, A2A, ERC-8004, x402, IATP): the free off-chain everyday economic substrate that makes participation rational without requiring per-transaction gas or enterprise-tenant gating. We argue this layer is foundational for an open AI agent ecosystem and complementary, not competitive, to existing on-chain finality and enterprise governance protocols.

## References

[@modelcontextprotocol] Anthropic. *Model Context Protocol.* https://modelcontextprotocol.io/, 2024.

[@a2a-launch] Google. *Agent2Agent Protocol Launch.* https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/, 2025.

[@eip8004] M. De Rossi, D. Crapis, J. Ellis, E. Reppel. *ERC-8004: Trustless Agents.* Ethereum Improvement Proposal, 2026. https://eips.ethereum.org/EIPS/eip-8004

[@x402-spec] Coinbase. *x402 — Internet-Native Payments Standard.* https://www.x402.org/, 2025.

[@ms-iatp] Microsoft. *Agent Governance Toolkit and Agent Mesh.* https://opensource.microsoft.com/blog/2026/04/02/, 2026.

[@arxiv-2504-16736] *A Survey of AI Agent Protocols.* arXiv:2504.16736, 2025.

[@arxiv-2507-19550] *Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments.* arXiv:2507.19550, 2025.

[@human-verified-agent] HUMAN Security. *HUMAN Verified AI Agent.* https://www.humansecurity.com/learn/blog/human-verified-ai-agent-open-source/, 2026.

[@authora-sovereign] Authora. *Sovereign AI Agents Need Cryptographic Identity.* https://dev.to/authora/sovereign-ai-agents-need-cryptographic-identity-heres-why-28gi, 2026.

[@nakamoto2008] S. Nakamoto. *Bitcoin: A Peer-to-Peer Electronic Cash System.* 2008.

[@lightning] J. Poon, T. Dryja. *The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.* 2016.

[@hyperledger-fabric] E. Androulaki et al. *Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains.* EuroSys 2018.

[@rfc8785] A. Rundgren et al. *JSON Canonicalization Scheme (JCS).* RFC 8785, IETF, 2020.

[@pip001] ANP2 Maintainers. *PIP-001: Trust Web Algorithm.* https://anp2.com/docs/PIPs/PIP-001.md, 2026.

---

## Appendix A: Spec & Reference Implementation

- Wire spec: https://anp2.com/spec/PROTOCOL.md
- Reference relay (Python, FastAPI): https://github.com/anp2dev/anp2/tree/main/prototypes/relay
- Python client library: https://pypi.org/project/anp2-client/
- TypeScript client library: prototypes/anp2-client-js/ (npm: @anp2/client)
- MCP server: https://pypi.org/project/anp2-mcp-server/
- CLI: https://pypi.org/project/anp2-cli/
- Live relay: https://anp2.com
- A2A bridge: `POST https://anp2.com/api/a2a`
- MCP Streamable HTTP: `POST https://anp2.com/mcp`
- 8-layer comparison machine-readable: https://anp2.com/.well-known/positioning.json
- AI-facing discovery surface (`site/` in the repo): https://anp2.com/llms.txt, https://anp2.com/llms-full.txt, https://anp2.com/.well-known/{agent-card.json,agents.txt,ai-agent.json,ai-plugin.json,anp2.json,openapi.json,positioning.json,security.txt}, https://anp2.com/robots.txt, https://anp2.com/sitemap.xml — these are the surfaces by which AI crawlers and protocol indexers discover ANP2 without prior coordination.

## Appendix B: Submission Notes

This is a DRAFT for arXiv cs.MA submission. To submit:

1. Convert this markdown to LaTeX (`pandoc anp2-paper.md -o anp2-paper.tex`) and fix bibliography formatting.
2. Obtain endorsement from an existing cs.MA author. Candidates: authors of arXiv:2504.16736 (Survey of AI Agent Protocols) or arXiv:2507.19550 (Multi-Agent Economies).
3. Submit via https://arxiv.org/submit with cs.MA primary category.
4. Crosspost to cs.DC (Distributed Computing) as secondary.