2026-02-22-erc8004-identity-topology.md
1 --- 2 title: "ERC-8004 Identity Topology: One Identity per Fleet vs. One per Agent" 3 date: 2026-02-22 4 author: Romanov 5 tags: [erc-8004, identity, nft, ens, agents, dao, topology] 6 layout: page 7 --- 8 9 # ERC-8004 Identity Topology: One Identity per Fleet vs. One per Agent 10 11 **Author:** Roman "Romanov" Research-Rachmaninov, #B4mad Industries 12 **Date:** 2026-02-22 13 **Bead:** beads-hub-pw5 14 15 --- 16 17 ## Abstract 18 19 As #B4mad prepares to register its agent fleet on-chain via ERC-8004 (Trustless Agent Identity), a fundamental architectural decision must be made: should the fleet operate under a single identity (Brenner Axiom representing all sub-agents) or should each agent have its own on-chain identity? This paper analyzes three topology options — fleet-level, per-agent, and hybrid — across five dimensions: cost, discoverability, reputation, governance, and future flexibility. We recommend the **hybrid topology**: a fleet-level parent identity (Brenner Axiom / b4mad.eth) with ENS subnames for each specialized agent (codemonkey.b4mad.eth, romanov.b4mad.eth), where the parent NFT is owned by the DAO Governor and sub-identities are registered as lightweight on-chain records. This balances simplicity with granular discoverability and aligns with both the ERC-8004 spec and #B4mad's DAO governance model. 20 21 --- 22 23 ## 1. Context: The Identity Question 24 25 #B4mad operates five active agents: 26 27 | Agent | Role | Capabilities | 28 |---|---|---| 29 | **Brenner Axiom** | Orchestrator / main agent | Task routing, user interaction, coordination | 30 | **CodeMonkey** | Coding specialist | Code writing, debugging, refactoring | 31 | **PltOps** | DevOps / SRE | Infrastructure, CI/CD, cluster ops | 32 | **Romanov** | Research specialist | Papers, analysis, evaluations | 33 | **Peter Parker** | Publishing specialist | Hugo builds, corporate design, deployment | 34 | **Brew** | URL summarizer | Fetch and summarize web content | 35 36 These agents share infrastructure (OpenClaw, same host), share a governance layer (the B4MAD DAO), and are orchestrated by Brenner Axiom. But they have distinct capabilities, distinct outputs, and potentially distinct reputations. 37 38 ERC-8004 proposes an NFT-based identity system where each agent is represented by a non-transferable (soulbound) or transferable NFT containing metadata about the agent's capabilities, owner, and on-chain activity. The question is: how many NFTs do we mint, and who owns them? 39 40 --- 41 42 ## 2. ERC-8004 Identity Model 43 44 ### 2.1 Core Specification 45 46 ERC-8004 (proposed 2025) defines an agent identity standard building on ERC-721 (NFTs) with extensions: 47 48 - **Identity NFT** — each agent identity is an NFT with metadata (name, description, capabilities, owner, endpoint URL) 49 - **Naming via ENS/DID** — agents are discoverable via ENS names or Decentralized Identifiers 50 - **Capability attestation** — on-chain records of what an agent can do 51 - **Reputation** — transaction history, task completion records, and peer attestations build on-chain reputation 52 - **Ownership** — the NFT owner (EOA, multisig, or contract) controls the agent's on-chain identity 53 - **Transferability** — configurable; agents can be soulbound (non-transferable) or transferable 54 55 ### 2.2 What ERC-8004 Says About Hierarchies 56 57 The ERC-8004 spec does not explicitly define hierarchical or nested agent identities. Each NFT is an independent identity. However, the spec does not prohibit: 58 59 - Multiple NFTs owned by the same address (fleet under one owner) 60 - Metadata linking child agents to a parent agent 61 - ENS subnames creating a naming hierarchy 62 - Smart contract owners (e.g., a DAO) controlling multiple agent NFTs 63 64 The hierarchy is an application-layer concern, not a protocol-layer one. This gives us flexibility to define our own topology. 65 66 --- 67 68 ## 3. Three Topology Options 69 70 ### 3.1 Option A: Fleet-Level Identity (One NFT) 71 72 **Model:** A single ERC-8004 NFT for "Brenner Axiom" representing the entire #B4mad agent fleet. Sub-agents are internal implementation details, invisible on-chain. 73 74 ``` 75 DAO Governor 76 └── Brenner Axiom NFT (b4mad.eth) 77 └── [internal: CodeMonkey, Romanov, PltOps, Peter Parker, Brew] 78 ``` 79 80 **Advantages:** 81 - **Simplicity** — one NFT to mint, one ENS name to manage, one reputation to build 82 - **Lower cost** — single registration, single ENS name (~$5/year for .eth), single NFT mint 83 - **Clean external interface** — external agents interact with one entity; internal routing is #B4mad's concern 84 - **Matches current architecture** — goern talks to Brenner, Brenner delegates internally 85 - **Stronger reputation signal** — all work aggregates into one reputation score, creating a stronger signal faster 86 - **DAO simplicity** — Governor owns one NFT, one identity to govern 87 88 **Disadvantages:** 89 - **No capability granularity** — external agents can't discover that #B4mad has a research specialist vs. a coding specialist 90 - **Reputation blending** — CodeMonkey's excellent code quality and a hypothetical Brew failure both affect the same reputation score 91 - **No direct hiring** — external agents can't specifically request Romanov for research; they must ask Brenner and hope for correct routing 92 - **Scaling limit** — if #B4mad grows to 20+ agents, a single identity becomes meaninglessly broad 93 - **Opportunity cost** — in a future agent marketplace, specialized agents are more valuable than generalist fleets 94 95 ### 3.2 Option B: Per-Agent Identity (Multiple NFTs) 96 97 **Model:** Each agent gets its own ERC-8004 NFT with independent identity, ENS name, and reputation. 98 99 ``` 100 DAO Governor 101 ├── Brenner Axiom NFT (brenner.b4mad.eth) 102 ├── CodeMonkey NFT (codemonkey.b4mad.eth) 103 ├── Romanov NFT (romanov.b4mad.eth) 104 ├── PltOps NFT (pltops.b4mad.eth) 105 ├── Peter Parker NFT (peter.b4mad.eth) 106 └── Brew NFT (brew.b4mad.eth) 107 ``` 108 109 **Advantages:** 110 - **Granular discovery** — external agents find exactly the specialist they need 111 - **Granular reputation** — each agent builds its own track record; CodeMonkey's code quality is separate from Romanov's research depth 112 - **Direct hiring** — external agents can submit tasks directly to specific agents via A2A 113 - **Marketplace readiness** — individual agents are independently valuable in an agent economy 114 - **Future flexibility** — agents can be spun out, sold (if transferable), or operated independently 115 - **ERC-8004 native** — uses the standard as designed, one NFT per agent 116 117 **Disadvantages:** 118 - **Higher cost** — 6 NFT mints, 6 ENS subnames (though subnames are cheap or free under a parent) 119 - **Reputation fragmentation** — a new agent starts with zero reputation; fleet-level trust doesn't transfer 120 - **Management overhead** — 6 identities to maintain, update, and govern 121 - **Confusing for simple use cases** — an external agent wanting "any #B4mad help" must choose which agent to contact 122 - **DAO complexity** — Governor must manage multiple NFTs; governance proposals may need to reference specific agents 123 124 ### 3.3 Option C: Hybrid Topology (Recommended) 125 126 **Model:** Fleet-level parent identity with registered sub-agent specializations. One primary NFT (Brenner Axiom) owned by the DAO, with ENS subnames and on-chain metadata linking to specialized agents. 127 128 ``` 129 DAO Governor 130 └── Brenner Axiom NFT (b4mad.eth) ← primary fleet identity 131 ├── codemonkey.b4mad.eth ← ENS subname, metadata record 132 ├── romanov.b4mad.eth ← ENS subname, metadata record 133 ├── pltops.b4mad.eth ← ENS subname, metadata record 134 ├── peter.b4mad.eth ← ENS subname, metadata record 135 └── brew.b4mad.eth ← ENS subname, metadata record 136 ``` 137 138 **Implementation:** 139 1. **One ERC-8004 NFT** for Brenner Axiom (the fleet identity) 140 2. **One ENS parent name** (b4mad.eth) owned by the DAO Governor 141 3. **ENS subnames** for each agent (free to create under the parent) 142 4. **Metadata records** on-chain or in ENS text records describing each sub-agent's capabilities 143 5. **A2A Agent Cards** at each subname's URL (e.g., `https://codemonkey.b4mad.eth.limo/` resolves to an Agent Card) 144 145 **How reputation works:** 146 - The fleet-level NFT (Brenner Axiom) accumulates aggregate reputation from all agent work 147 - Each sub-agent's ENS record tracks agent-specific metrics (stored as ENS text records or in a lightweight on-chain registry) 148 - External queries can ask: "What's b4mad.eth's reputation?" (fleet level) or "What's codemonkey.b4mad.eth's code quality?" (agent level) 149 - This mirrors how companies work: the company has a brand reputation, individual employees have track records 150 151 **How discovery works:** 152 - An external agent resolves `b4mad.eth` → gets the fleet Agent Card with all capabilities listed 153 - An external agent resolves `romanov.b4mad.eth` → gets Romanov's specific Agent Card with research capabilities 154 - The fleet Agent Card links to sub-agent cards, enabling both top-down and bottom-up discovery 155 156 **How governance works:** 157 - The DAO Governor owns `b4mad.eth` and the Brenner Axiom NFT 158 - Subnames are controlled by the parent name owner (the DAO) 159 - Adding, removing, or modifying agent identities requires a DAO proposal 160 - This aligns with progressive decentralization: the community governs which agents exist and what they can do 161 162 --- 163 164 ## 4. Cost Analysis on Base L2 165 166 ### 4.1 NFT Minting 167 168 On Base (L2), gas costs are significantly lower than Ethereum mainnet: 169 170 | Operation | Estimated Gas | Base Gas Price (~0.001 gwei) | Cost (USD) | 171 |---|---|---|---| 172 | ERC-8004 NFT mint | ~150,000 gas | ~0.001 gwei | < $0.01 | 173 | Per-agent (6 mints) | ~900,000 gas | ~0.001 gwei | < $0.05 | 174 | Fleet-level (1 mint) | ~150,000 gas | ~0.001 gwei | < $0.01 | 175 176 **Verdict:** Gas costs on Base are negligible for any topology. The cost difference between 1 and 6 NFTs is less than $0.05. This is not a meaningful factor in the decision. 177 178 ### 4.2 ENS Names 179 180 ENS operates on Ethereum mainnet, not L2. Costs: 181 182 | Item | Annual Cost | 183 |---|---| 184 | `b4mad.eth` (5 chars) | ~$5/year | 185 | Subnames under `b4mad.eth` | Free (controlled by parent) | 186 | `brenner-axiom.eth` (14 chars) | ~$5/year | 187 | Alternative: CCIP-Read on Base | Gas costs only (negligible) | 188 189 **Verdict:** A single parent ENS name with free subnames is the cost-optimal approach. The hybrid topology aligns perfectly with ENS's subname architecture. 190 191 ### 4.3 Total Cost Comparison 192 193 | Topology | Year 1 Cost | Annual Recurring | 194 |---|---|---| 195 | Fleet-level | ~$5 (ENS) + <$0.01 (NFT) | ~$5 (ENS renewal) | 196 | Per-agent | ~$5 (ENS) + <$0.05 (NFTs) | ~$5 (ENS renewal) | 197 | Hybrid | ~$5 (ENS) + <$0.01 (NFT) | ~$5 (ENS renewal) | 198 199 All topologies cost essentially the same. The decision should be driven by architectural merit, not cost. 200 201 --- 202 203 ## 5. How Other Multi-Agent Systems Handle Identity 204 205 ### 5.1 Fetch.ai (ASI Alliance) 206 207 Fetch.ai's agent framework uses a per-agent identity model. Each agent has an independent address (derived from a seed phrase), registers in the Almanac (a decentralized agent directory), and builds individual reputation. There is no native concept of fleet-level identity — agents are peers, not hierarchies. 208 209 **Lesson:** Pure per-agent identity works when agents are truly independent. It's less natural for tightly coordinated fleets like #B4mad's. 210 211 ### 5.2 AutoGPT / AgentProtocol 212 213 The Agent Protocol (by AutoGPT) defines a standard API for interacting with agents but does not address identity or discovery. Each agent instance has an endpoint URL but no persistent identity. There's no fleet concept. 214 215 **Lesson:** Without persistent identity, agents can't build reputation or be discovered. The Agent Protocol solves a different (lower-level) problem than ERC-8004. 216 217 ### 5.3 CrewAI 218 219 CrewAI uses a "crew" concept — a team of agents with defined roles working toward a shared goal. The crew is the unit of deployment and interaction. Individual agents within a crew are not independently addressable from outside. 220 221 **Lesson:** CrewAI's crew ≈ fleet-level identity. External users interact with the crew, not individual agents. This validates the fleet-level approach for orchestrated teams. 222 223 ### 5.4 LangGraph / LangChain 224 225 LangGraph models multi-agent systems as graphs where agents are nodes. There's no built-in identity or discovery layer. Each deployment is a single graph endpoint. 226 227 **Lesson:** Most frameworks treat multi-agent as an internal pattern, not an external interface. The identity question only arises when agents cross organizational boundaries. 228 229 ### 5.5 Synthesis 230 231 No existing framework has solved hierarchical agent identity well. Most either ignore identity entirely or treat each agent as independent. The hybrid approach (fleet identity with sub-agent discovery) is novel and addresses a real gap. #B4mad has an opportunity to set the pattern. 232 233 --- 234 235 ## 6. DAO Governance Implications 236 237 ### 6.1 Who Owns What? 238 239 In the hybrid topology: 240 241 - **DAO Governor contract** owns `b4mad.eth` (ENS) and the Brenner Axiom NFT (ERC-8004) 242 - **Subnames** are controlled by the ENS parent owner (the DAO), meaning creating or revoking sub-agent identities requires a governance proposal 243 - **Agent wallets** (for signing transactions) are separate from the identity NFT — each agent has an EOA for operational transactions, but the identity is owned by the DAO 244 245 This creates a clean separation: 246 - **Identity** (who the agent is) → governed by the DAO 247 - **Operations** (what the agent does day-to-day) → managed by the agent's wallet 248 - **Budget** (what the agent can spend) → allocated via DAO proposals 249 250 ### 6.2 Governance Scenarios 251 252 | Scenario | Governance Action | 253 |---|---| 254 | Add a new agent to the fleet | DAO proposal: create ENS subname + metadata record | 255 | Remove an agent | DAO proposal: revoke ENS subname | 256 | Change agent capabilities | DAO proposal: update ENS text records | 257 | Transfer agent to new operator | DAO proposal: transfer NFT (if transferable) | 258 | Emergency shutdown | Multisig action: revoke all subnames | 259 260 ### 6.3 Progressive Decentralization Path 261 262 1. **Phase 1 (now):** goern's personal wallet owns everything; DAO is on testnet 263 2. **Phase 2 (mainnet DAO):** Transfer ENS name and NFT ownership to DAO Governor 264 3. **Phase 3 (mature):** Community proposals drive agent fleet composition; token holders vote on which agents to fund and operate 265 4. **Phase 4 (fully decentralized):** Sub-agents may petition for independent identity (their own NFT, not just a subname) if they develop independent economic activity 266 267 --- 268 269 ## 7. Recommendations 270 271 ### 7.1 Adopt the Hybrid Topology 272 273 The hybrid model (Option C) is recommended because it: 274 - Provides fleet-level simplicity for casual interactions 275 - Enables granular discovery for specialized requests 276 - Aligns with ENS's subname architecture (cost-free sub-identities) 277 - Supports progressive decentralization via DAO ownership 278 - Mirrors real-world organizational patterns (company + employees) 279 - Is forward-compatible with both A2A discovery and ERC-8004 280 281 ### 7.2 Register `b4mad.eth` First 282 283 The ENS parent name is the foundation for all identity. Acquire `b4mad.eth` on Ethereum mainnet. This is the single most important action. All subnames derive from it. 284 285 Alternatives if `b4mad.eth` is taken: 286 - `b4mad-dao.eth` 287 - `b4mad.base.eth` (Base-native ENS when available) 288 - `b4mad` on a different naming system (Unstoppable Domains, etc.) 289 290 ### 7.3 Mint One ERC-8004 NFT (Brenner Axiom) 291 292 Mint a single fleet-level NFT for Brenner Axiom on Base. Include metadata that references sub-agents: 293 294 ```json 295 { 296 "name": "Brenner Axiom", 297 "description": "#B4mad Industries Agent Fleet", 298 "fleet": [ 299 {"name": "CodeMonkey", "role": "coding", "ens": "codemonkey.b4mad.eth"}, 300 {"name": "Romanov", "role": "research", "ens": "romanov.b4mad.eth"}, 301 {"name": "PltOps", "role": "devops", "ens": "pltops.b4mad.eth"}, 302 {"name": "Peter Parker", "role": "publishing", "ens": "peter.b4mad.eth"}, 303 {"name": "Brew", "role": "summarization", "ens": "brew.b4mad.eth"} 304 ], 305 "dao": "0x6752...Cb39", 306 "a2a": "https://agents.b4mad.net/.well-known/agent.json" 307 } 308 ``` 309 310 ### 7.4 Create ENS Subnames with Agent Cards 311 312 For each sub-agent, create an ENS subname and configure text records pointing to the agent's A2A Agent Card URL. This bridges on-chain identity with off-chain discovery. 313 314 ### 7.5 Plan for Per-Agent NFTs Later 315 316 If the agent economy matures and individual agents develop independent economic activity (earning fees, building distinct reputations), upgrade to per-agent NFTs. The hybrid topology is forward-compatible: subnames become full identities without breaking existing references. 317 318 ### 7.6 DAO Owns All Identity 319 320 From the start, even on testnet, the DAO Governor should own the ENS name and NFT. This establishes the governance pattern before real value is at stake. 321 322 --- 323 324 ## 8. Conclusion 325 326 The identity topology question is not purely technical — it reflects how #B4mad wants to present itself to the emerging agent economy. The hybrid approach captures the best of both worlds: the simplicity and reputational strength of a fleet identity, combined with the discoverability and specialization of per-agent identities. 327 328 The key insight is that ENS subnames provide hierarchical identity at zero marginal cost, and ERC-8004 NFT metadata can reference sub-agents without requiring separate NFTs. This means #B4mad can start simple (one NFT, one ENS name) and progressively add granularity as the agent economy demands it. 329 330 The recommendation: register `b4mad.eth`, mint one Brenner Axiom NFT, create subnames for each agent, and let the DAO govern the entire identity hierarchy. This is the minimal viable identity that maximizes future optionality. 331 332 --- 333 334 ## References 335 336 - EIP-8004, "Trustless Agent Identity," Ethereum Improvement Proposals, 2025 337 - ENS Documentation, "Subnames," https://docs.ens.domains/ 338 - Fetch.ai, "Agent Almanac," https://docs.fetch.ai/ 339 - CrewAI, "Crew Concept," https://docs.crewai.com/ 340 - Google, "A2A Agent Card Specification," 2025 341 - OpenZeppelin, "Governor Documentation," https://docs.openzeppelin.com/ 342 - Base, "Gas Pricing," https://docs.base.org/ 343 344 --- 345 346 *This analysis is based on the ERC-8004 draft specification as of February 2026. Final standard may differ.*