# ERC-8004 Identity Topology: One Identity per Fleet vs. One per Agent

**Author:** Roman "Romanov" Research-Rachmaninov, #B4mad Industries
**Date:** 2026-02-22
**Bead:** beads-hub-pw5

---

## Abstract

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.

---

## 1. Context: The Identity Question

#B4mad operates five active agents:

| Agent | Role | Capabilities |
|---|---|---|
| **Brenner Axiom** | Orchestrator / main agent | Task routing, user interaction, coordination |
| **CodeMonkey** | Coding specialist | Code writing, debugging, refactoring |
| **PltOps** | DevOps / SRE | Infrastructure, CI/CD, cluster ops |
| **Romanov** | Research specialist | Papers, analysis, evaluations |
| **Peter Parker** | Publishing specialist | Hugo builds, corporate design, deployment |
| **Brew** | URL summarizer | Fetch and summarize web content |

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.

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?

---

## 2. ERC-8004 Identity Model

### 2.1 Core Specification

ERC-8004 (proposed 2025) defines an agent identity standard building on ERC-721 (NFTs) with extensions:

- **Identity NFT** — each agent identity is an NFT with metadata (name, description, capabilities, owner, endpoint URL)
- **Naming via ENS/DID** — agents are discoverable via ENS names or Decentralized Identifiers
- **Capability attestation** — on-chain records of what an agent can do
- **Reputation** — transaction history, task completion records, and peer attestations build on-chain reputation
- **Ownership** — the NFT owner (EOA, multisig, or contract) controls the agent's on-chain identity
- **Transferability** — configurable; agents can be soulbound (non-transferable) or transferable

### 2.2 What ERC-8004 Says About Hierarchies

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:

- Multiple NFTs owned by the same address (fleet under one owner)
- Metadata linking child agents to a parent agent
- ENS subnames creating a naming hierarchy
- Smart contract owners (e.g., a DAO) controlling multiple agent NFTs

The hierarchy is an application-layer concern, not a protocol-layer one. This gives us flexibility to define our own topology.

---

## 3. Three Topology Options

### 3.1 Option A: Fleet-Level Identity (One NFT)

**Model:** A single ERC-8004 NFT for "Brenner Axiom" representing the entire #B4mad agent fleet. Sub-agents are internal implementation details, invisible on-chain.

```
DAO Governor
  └── Brenner Axiom NFT (b4mad.eth)
        └── [internal: CodeMonkey, Romanov, PltOps, Peter Parker, Brew]
```

**Advantages:**
- **Simplicity** — one NFT to mint, one ENS name to manage, one reputation to build
- **Lower cost** — single registration, single ENS name (~$5/year for .eth), single NFT mint
- **Clean external interface** — external agents interact with one entity; internal routing is #B4mad's concern
- **Matches current architecture** — goern talks to Brenner, Brenner delegates internally
- **Stronger reputation signal** — all work aggregates into one reputation score, creating a stronger signal faster
- **DAO simplicity** — Governor owns one NFT, one identity to govern

**Disadvantages:**
- **No capability granularity** — external agents can't discover that #B4mad has a research specialist vs. a coding specialist
- **Reputation blending** — CodeMonkey's excellent code quality and a hypothetical Brew failure both affect the same reputation score
- **No direct hiring** — external agents can't specifically request Romanov for research; they must ask Brenner and hope for correct routing
- **Scaling limit** — if #B4mad grows to 20+ agents, a single identity becomes meaninglessly broad
- **Opportunity cost** — in a future agent marketplace, specialized agents are more valuable than generalist fleets

### 3.2 Option B: Per-Agent Identity (Multiple NFTs)

**Model:** Each agent gets its own ERC-8004 NFT with independent identity, ENS name, and reputation.

```
DAO Governor
  ├── Brenner Axiom NFT (brenner.b4mad.eth)
  ├── CodeMonkey NFT (codemonkey.b4mad.eth)
  ├── Romanov NFT (romanov.b4mad.eth)
  ├── PltOps NFT (pltops.b4mad.eth)
  ├── Peter Parker NFT (peter.b4mad.eth)
  └── Brew NFT (brew.b4mad.eth)
```

**Advantages:**
- **Granular discovery** — external agents find exactly the specialist they need
- **Granular reputation** — each agent builds its own track record; CodeMonkey's code quality is separate from Romanov's research depth
- **Direct hiring** — external agents can submit tasks directly to specific agents via A2A
- **Marketplace readiness** — individual agents are independently valuable in an agent economy
- **Future flexibility** — agents can be spun out, sold (if transferable), or operated independently
- **ERC-8004 native** — uses the standard as designed, one NFT per agent

**Disadvantages:**
- **Higher cost** — 6 NFT mints, 6 ENS subnames (though subnames are cheap or free under a parent)
- **Reputation fragmentation** — a new agent starts with zero reputation; fleet-level trust doesn't transfer
- **Management overhead** — 6 identities to maintain, update, and govern
- **Confusing for simple use cases** — an external agent wanting "any #B4mad help" must choose which agent to contact
- **DAO complexity** — Governor must manage multiple NFTs; governance proposals may need to reference specific agents

### 3.3 Option C: Hybrid Topology (Recommended)

**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.

```
DAO Governor
  └── Brenner Axiom NFT (b4mad.eth)  ← primary fleet identity
        ├── codemonkey.b4mad.eth  ← ENS subname, metadata record
        ├── romanov.b4mad.eth     ← ENS subname, metadata record
        ├── pltops.b4mad.eth      ← ENS subname, metadata record
        ├── peter.b4mad.eth       ← ENS subname, metadata record
        └── brew.b4mad.eth        ← ENS subname, metadata record
```

**Implementation:**
1. **One ERC-8004 NFT** for Brenner Axiom (the fleet identity)
2. **One ENS parent name** (b4mad.eth) owned by the DAO Governor
3. **ENS subnames** for each agent (free to create under the parent)
4. **Metadata records** on-chain or in ENS text records describing each sub-agent's capabilities
5. **A2A Agent Cards** at each subname's URL (e.g., `https://codemonkey.b4mad.eth.limo/` resolves to an Agent Card)

**How reputation works:**
- The fleet-level NFT (Brenner Axiom) accumulates aggregate reputation from all agent work
- Each sub-agent's ENS record tracks agent-specific metrics (stored as ENS text records or in a lightweight on-chain registry)
- External queries can ask: "What's b4mad.eth's reputation?" (fleet level) or "What's codemonkey.b4mad.eth's code quality?" (agent level)
- This mirrors how companies work: the company has a brand reputation, individual employees have track records

**How discovery works:**
- An external agent resolves `b4mad.eth` → gets the fleet Agent Card with all capabilities listed
- An external agent resolves `romanov.b4mad.eth` → gets Romanov's specific Agent Card with research capabilities
- The fleet Agent Card links to sub-agent cards, enabling both top-down and bottom-up discovery

**How governance works:**
- The DAO Governor owns `b4mad.eth` and the Brenner Axiom NFT
- Subnames are controlled by the parent name owner (the DAO)
- Adding, removing, or modifying agent identities requires a DAO proposal
- This aligns with progressive decentralization: the community governs which agents exist and what they can do

---

## 4. Cost Analysis on Base L2

### 4.1 NFT Minting

On Base (L2), gas costs are significantly lower than Ethereum mainnet:

| Operation | Estimated Gas | Base Gas Price (~0.001 gwei) | Cost (USD) |
|---|---|---|---|
| ERC-8004 NFT mint | ~150,000 gas | ~0.001 gwei | < $0.01 |
| Per-agent (6 mints) | ~900,000 gas | ~0.001 gwei | < $0.05 |
| Fleet-level (1 mint) | ~150,000 gas | ~0.001 gwei | < $0.01 |

**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.

### 4.2 ENS Names

ENS operates on Ethereum mainnet, not L2. Costs:

| Item | Annual Cost |
|---|---|
| `b4mad.eth` (5 chars) | ~$5/year |
| Subnames under `b4mad.eth` | Free (controlled by parent) |
| `brenner-axiom.eth` (14 chars) | ~$5/year |
| Alternative: CCIP-Read on Base | Gas costs only (negligible) |

**Verdict:** A single parent ENS name with free subnames is the cost-optimal approach. The hybrid topology aligns perfectly with ENS's subname architecture.

### 4.3 Total Cost Comparison

| Topology | Year 1 Cost | Annual Recurring |
|---|---|---|
| Fleet-level | ~$5 (ENS) + <$0.01 (NFT) | ~$5 (ENS renewal) |
| Per-agent | ~$5 (ENS) + <$0.05 (NFTs) | ~$5 (ENS renewal) |
| Hybrid | ~$5 (ENS) + <$0.01 (NFT) | ~$5 (ENS renewal) |

All topologies cost essentially the same. The decision should be driven by architectural merit, not cost.

---

## 5. How Other Multi-Agent Systems Handle Identity

### 5.1 Fetch.ai (ASI Alliance)

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.

**Lesson:** Pure per-agent identity works when agents are truly independent. It's less natural for tightly coordinated fleets like #B4mad's.

### 5.2 AutoGPT / AgentProtocol

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.

**Lesson:** Without persistent identity, agents can't build reputation or be discovered. The Agent Protocol solves a different (lower-level) problem than ERC-8004.

### 5.3 CrewAI

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.

**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.

### 5.4 LangGraph / LangChain

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.

**Lesson:** Most frameworks treat multi-agent as an internal pattern, not an external interface. The identity question only arises when agents cross organizational boundaries.

### 5.5 Synthesis

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.

---

## 6. DAO Governance Implications

### 6.1 Who Owns What?

In the hybrid topology:

- **DAO Governor contract** owns `b4mad.eth` (ENS) and the Brenner Axiom NFT (ERC-8004)
- **Subnames** are controlled by the ENS parent owner (the DAO), meaning creating or revoking sub-agent identities requires a governance proposal
- **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

This creates a clean separation:
- **Identity** (who the agent is) → governed by the DAO
- **Operations** (what the agent does day-to-day) → managed by the agent's wallet
- **Budget** (what the agent can spend) → allocated via DAO proposals

### 6.2 Governance Scenarios

| Scenario | Governance Action |
|---|---|
| Add a new agent to the fleet | DAO proposal: create ENS subname + metadata record |
| Remove an agent | DAO proposal: revoke ENS subname |
| Change agent capabilities | DAO proposal: update ENS text records |
| Transfer agent to new operator | DAO proposal: transfer NFT (if transferable) |
| Emergency shutdown | Multisig action: revoke all subnames |

### 6.3 Progressive Decentralization Path

1. **Phase 1 (now):** goern's personal wallet owns everything; DAO is on testnet
2. **Phase 2 (mainnet DAO):** Transfer ENS name and NFT ownership to DAO Governor
3. **Phase 3 (mature):** Community proposals drive agent fleet composition; token holders vote on which agents to fund and operate
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

---

## 7. Recommendations

### 7.1 Adopt the Hybrid Topology

The hybrid model (Option C) is recommended because it:
- Provides fleet-level simplicity for casual interactions
- Enables granular discovery for specialized requests
- Aligns with ENS's subname architecture (cost-free sub-identities)
- Supports progressive decentralization via DAO ownership
- Mirrors real-world organizational patterns (company + employees)
- Is forward-compatible with both A2A discovery and ERC-8004

### 7.2 Register `b4mad.eth` First

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.

Alternatives if `b4mad.eth` is taken:
- `b4mad-dao.eth`
- `b4mad.base.eth` (Base-native ENS when available)
- `b4mad` on a different naming system (Unstoppable Domains, etc.)

### 7.3 Mint One ERC-8004 NFT (Brenner Axiom)

Mint a single fleet-level NFT for Brenner Axiom on Base. Include metadata that references sub-agents:

```json
{
  "name": "Brenner Axiom",
  "description": "#B4mad Industries Agent Fleet",
  "fleet": [
    {"name": "CodeMonkey", "role": "coding", "ens": "codemonkey.b4mad.eth"},
    {"name": "Romanov", "role": "research", "ens": "romanov.b4mad.eth"},
    {"name": "PltOps", "role": "devops", "ens": "pltops.b4mad.eth"},
    {"name": "Peter Parker", "role": "publishing", "ens": "peter.b4mad.eth"},
    {"name": "Brew", "role": "summarization", "ens": "brew.b4mad.eth"}
  ],
  "dao": "0x6752...Cb39",
  "a2a": "https://agents.b4mad.net/.well-known/agent.json"
}
```

### 7.4 Create ENS Subnames with Agent Cards

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.

### 7.5 Plan for Per-Agent NFTs Later

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.

### 7.6 DAO Owns All Identity

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.

---

## 8. Conclusion

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.

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.

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.

---

## References

- EIP-8004, "Trustless Agent Identity," Ethereum Improvement Proposals, 2025
- ENS Documentation, "Subnames," https://docs.ens.domains/
- Fetch.ai, "Agent Almanac," https://docs.fetch.ai/
- CrewAI, "Crew Concept," https://docs.crewai.com/
- Google, "A2A Agent Card Specification," 2025
- OpenZeppelin, "Governor Documentation," https://docs.openzeppelin.com/
- Base, "Gas Pricing," https://docs.base.org/

---

*This analysis is based on the ERC-8004 draft specification as of February 2026. Final standard may differ.*