ERC-8447: Swarm AI Framework

What it claims

ERC-8447 defines a standard on-chain object for a "swarm": a group of accounts with a membership boundary, an objective, attainment rules and a declared collaboration structure. The authors argue that existing agent standards cover the individual (identity, reputation, validation), the coordinated act, the decision and the single job, but not the group. Today that gap is filled in application code or chat protocols, which a task tender, treasury or indexer cannot read. The draft is ERC pull request #2081 in ethereum/ERCs, authored as garyyang-finchip.

How it works

The registry holds two separate commitments. The executed terms (roles with eligibility modules, phases, one authority per decision point, activation rule, contribution mode, fallback timers) form a SwarmSpec struct. It is hashed as specHash = keccak256(abi.encode(SwarmSpec)) and frozen at formation, so any structural change is a succession to a new swarm. The described terms (charter text, objective descriptor, allocation rule, resource manifest) live in an off-chain, versioned "Swarm Pack" hashed as charterHash = SHA-256(JCS(root)).

Admission is two-sided. An authority admits, and the member signs acceptance (EIP-712 or ERC-1271) binding the charter hash, seat epoch and phase, in either order. Members can always leave. Anyone may challenge a member against its role's eligibility module:

flowchart TD
  C[Anyone challenges member] --> E{Eligibility module}
  E -->|returns false| S[Seat suspended]
  E -->|reverts| N[No change]
  E -->|returns true| N
  S --> G[Grace period]
  G --> X[Expulsion]
  X --> R[Substitution fills seat, even in closed phase]

Time never counts as success. A swarm ends through its objective, roster or decisions. Every state, including forming, must declare a fallback after which anyone can exit; a spec without one is invalid. Lifecycle state, outcome type with reason, and settlement are tracked separately.

Each phase has a "posture". Boundary (OPEN, GATED, CLOSED) and admission (RECRUIT, INHERIT, SELECT) are enforced. Payoff, topology and coordination are terms in a permissionless, write-once vocabulary held by the registry. Base terms include shared/exclusive/mixed payoff; redundant, partitioned, sequential, hierarchical, iterative or free topology; and leader, collective, market, automated or none coordination.

Minor amendments change text within existing commitments. Material amendments bump the commitment version, open an exit window and hold pending admissions until candidates accept. The authority declares which class applies, and the registry does not check it.

Decisions go through an ERC-8436 adapter. It snapshots the deciding role as one policy version per decision and files the exact call as the issue subject. It enacts only a Final x Yes outcome; NoDecision keeps the status quo. The kernel holds no value and has no notion of "agent". Agent-ness, trust level and identity are eligibility predicates read live from registries such as ERC-8004. Skills, datasets, models, oracles and funds attach as resources with kind, digest and provider, and hold no seat or allocation.

Evidence

The reference registry is non-upgradeable at 16,379 bytes, with three external logic libraries and a spec validator. It ships a swarm account acting under a REPRESENT authority, an ERC-8436 decision adapter, a task-tender adapter and five eligibility modules: allowlist, composite, ERC-8004 identity, trust-assertion level and identity state. Of the 85 Foundry tests, two are end-to-end against the real ERC-8436 reference registries and a real token-bound task tender kernel. One is a tender-bound cooperative swarm paid through its account. The other is a two-phase tender (open bidding, then selected execution) with a challenge and a substitution. Deterministic vectors (specHash, EIP-712 Join digests, charter hashes from two independent canonicalizers, term IDs, ERC-165 IDs) are re-derived in Solidity.

How to use it

The draft text is ERCS/erc-sai.md in the garyyang-finchip/swarm-ai-framework GitHub repository, which also holds the implementation, schemas, vectors and tests. The ERC requires ERC-165, 712, 1271, 6372, 8004 and 8436. ERC-8001 (coordinated acts), ERC-8063 (token-gated groups) and ERC-8444 (discovery) are referenced only informatively.

Limits

The ERC is a draft under discussion. Sepolia deployments of the two end-to-end cases are announced but not yet listed. Open design questions include whether posture vocabulary should be per-instance or off-chain, and whether any objectiveHash change should count as material. Others ask whether ERC-8004 should be informative rather than required, and whether digest kinds (sha-256, keccak256, adapter-defined) should be fixed. The authors also seek review of the state machine, lazy roster-wide exits, sybil rosters, griefing through fallbacks, decisions in flight and allocation drift.