# ERC-8004 in Context: From Trust Fabric to Execution Fabric (Draft)

ERC-8004 defines a **trust fabric for autonomous agents** by standardizing how agents can be discovered, identified, and validated across organizations without pre-existing trust.

However, the standard **stops short of execution**. It specifies *who an agent is*, *why they might be trusted*, and *where validation records live*—but not *how tasks are executed or verified*.

**Cortensor supplies this missing execution layer.** By routing inference workloads across decentralized nodes and attaching verifiable proofs, Cortensor provides the *how + proof* that complements ERC-8004’s *who + why*.

References:

* ERC-8004 EIP: <https://eips.ethereum.org/EIPS/eip-8004>
* A2A Protocol overview (Google): <https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/>
* A2A Extensions (Google): <https://developers.googleblog.com/en/a2a-extensions-empowering-custom-agent-functionality/>
* A2A Intro Codelab: <https://codelabs.developers.google.com/intro-a2a-purchasing-concierge>
* Ethereum Magicians Discussion: <https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098> and <https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098?page=2>

***

#### What ERC-8004 Defines

* **Identity Registry** – establishes agent identity across organizations.
* **Reputation Registry** – records why an agent is trustworthy (history, endorsements, scores).
* **Validation Registry** – anchors validation events on-chain for transparency.

The EIP explicitly leaves application logic **off-chain**: execution, inference, and verification methods are not specified. Validation is just a minimal on-chain record — it could be powered by a **TEE attestor**, a **stake committee**, or even a **single centralized judge**.

***

#### Where Cortensor Fits

**1. From&#x20;*****Trust*****&#x20;→&#x20;*****Execution with Proofs***

* **Identity / Reputation (ERC-8004) → Job Admission (Cortensor)**\
  Cortensor routers can check ERC-8004 identity/reputation as a policy input before dispatching tasks.
* **Validation (ERC-8004) → Proof of Inference (Cortensor)**\
  After execution, Cortensor can emit verifiable artifacts (e.g., output hashes, PoI/PoUW receipts) and anchor those references to the ERC-8004 Validation registry.

**2. Turning Registries into a Compute Market**

* Cortensor routes workloads across heterogeneous hardware (edge devices → GPU clusters).
* Results are verified via **Proof of Inference (PoI)** and **Proof of Useful Work (PoUW)**.
* Outcomes and verifier assessments can be written back to ERC-8004 Reputation to update credibility with evidence.

**3. Policy & Reliability Beyond Spec**

* ERC-8004 is minimal by design. Cortensor enforces **off-chain policies** — SLA, model/version allowlists, latency/energy thresholds — while anchoring validation signals on-chain.
* This respects the EIP’s minimalism while delivering **real-world reliability**.

***

#### Centralized Judge vs. Cortensor Validator

| **Validation Mode** | **How It Works**                                                                            | **Limitations**                                   | **Cortensor Alternative**                                          |
| ------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------ |
| Centralized Judge   | A single entity (or LLM API) decides if results are valid and writes to Validation registry | Bottlenecked, trust rests in one provider         | Tasks routed across many nodes, results verified via PoI/PoUW      |
| TEE Attestor        | Hardware enclave attests to output correctness                                              | Requires hardware trust & supply-chain guarantees | Verifiable inference without hardware lock-in                      |
| Stake Committee     | Group of stakers validate and write to registry                                             | Can be captured or cartelized                     | Open, decentralized miner/oracle network with cryptographic proofs |

**Key point:** ERC-8004 doesn’t force which “judge” is used. Cortensor provides a **trustless, decentralized judge**, ensuring validation is both distributed and verifiable.

***

#### Mental Model

* **ERC-8004 = Trust Fabric**: identity, reputation, validation registries.
* **Cortensor = Execution Fabric**: routing, inference, verification, privacy.
* **Loop**: *Who + Why (ERC-8004) → How + Proof (Cortensor) → Updated Reputation (ERC-8004).*

***

#### Why It Matters

Without Cortensor, ERC-8004-enabled agents could still rely on **centralized inference providers**, leaving the “last mile” centralized.

With Cortensor:

* Inference is **decentralized and verifiable**.
* Results are tied back to **ERC-8004 registries** for trust anchoring.
* Agents don’t just interoperate—they **execute and prove work trustlessly**.

This unlocks a **true agent economy**, where identity, execution, and reputation are fully linked.

***

#### Developer Integration Pattern (Conceptual)

1. **Read Identity/Reputation** from ERC-8004.
2. **Route Task** through Cortensor’s decentralized inference fabric.
3. **Generate Proofs** (PoI receipts, PoUW quality scores).
4. **Anchor Validation** back into ERC-8004’s Validation registry.

This pattern ties **on-chain trust** directly to **off-chain execution and verification**.

***

⚠️ **Status:** ERC-8004 is about a month old and under active community discussion. Cortensor’s execution layer is not part of the spec but provides a **practical path** to close the trust → execution loop with verifiable inference.