# 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: * A2A Protocol overview (Google): * A2A Extensions (Google): * A2A Intro Codelab: * Ethereum Magicians Discussion: and *** #### 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 *****Trust***** → *****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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cortensor.network/technical-architecture/designs-wip/wip-agentic/erc-8004-in-context-from-trust-fabric-to-execution-fabric-draft.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.