[Draft ERC] Swarm AI Framework — registry and charter model for purpose-bound agent swarms

What it claims

A draft ERC defining a "swarm" as one on-chain object: a membership boundary, an objective with attainment rules, and a declared collaboration structure. The authors argue that existing agent standards cover the individual (identity, reputation, validation), the single coordinated act, the decision, and the single-provider job. None defines a group, so pipelines currently redefine it in application code where counterparties such as tenders, treasuries and indexers cannot read it. The ERC is not yet filed: the ethereum/ERCs PR is "to be added after filing", and the Sepolia deployments are announced but not yet live.

How it works

The page states several design rules that the summary does not:

• Hashing. specHash = keccak256(abi.encode(SwarmSpec)) is frozen at formation. Any structural change is a succession (a new swarm), not an edit. The off-chain charter uses charterHash = SHA-256(JCS(root)) and is versioned.
• Admission. The authority's admit and the member's accept can happen in either order. A signed acceptance binds the charter hash, seat epoch and phase. Leaving is always allowed.
• Fallbacks are mandatory. Every state, including forming, has a permissionless exit after a declared fallback. A spec without one is invalid. Time never counts as success. Only objectives, rosters or decisions end a swarm. Lifecycle state, outcome type (with reason) and settlement are tracked as three separate fields.
• Decisions. The reference ERC-8436 adapter snapshots the deciding role's roster as a new policy version for each decision. It files the exact call as the issue subject and enacts only on Final × Yes. NoDecision keeps the status quo.
• Kernel scope. The registry holds no value and has no notion of "agent". Agent-ness is checked live through eligibility predicates against external registries.
• Resources. Skills, datasets, models, code and funds attach as resources with a kind, an optional anchor, a digest and digest kind, a provider and a role scope. They get no seat and no allocation.
• Obligation binding. The swarm account is the fulfiller of record for an external tender, and an adapter concludes the swarm from the tender's record.

Challenge handling, which governs how bad members are removed:

flowchart TD
  C[Anyone challenges member] --> E{Role eligibility module}
  E -->|true| N[No change]
  E -->|revert| N
  E -->|false| S[Seat suspended]
  S --> G[Grace period]
  G --> X[Expulsion]
  X --> R[Substitution, allowed even in CLOSED phase]

A revert in the eligibility module leaves the member in place. Only an explicit false suspends.

Evidence

• The registry is non-upgradeable, 16,379 bytes, with three external logic libraries and a spec validator.
• There are 85 Foundry tests. Two are end-to-end cases run against the real ERC-8436 reference registries and a real token-bound task-tender kernel:
• a tender-bound cooperative swarm paid through its account;
• a two-phase tender (open bidding, then selected execution) that includes a challenge and a substitution.
• The deterministic vectors cover specHash, EIP-712 Join digests, charter hashes from two independent canonicalizers, term IDs and ERC-165 IDs. All are re-derived in Solidity.

How to use it

• Draft text: ERCS/erc-sai.md in garyyang-finchip/swarm-ai-framework on GitHub. The same repo holds the implementation, schemas, vectors and tests.
• Normative dependencies: ERC-165, 712, 1271, 6372, 8004 and 8436.
• Informative only: ERC-8001, 8063 and 8444.
• The page gives no install commands and no licence.

Limits

• This is a pre-filing draft with no testnet deployment yet.
• The authors list as open questions:
• whether ERC-8004 should be required at all;
• whether amendment class should be enforced rather than self-declared by the authority (currently the registry "never second-guesses it", so an objectiveHash change can be labelled minor);
• whether digest kinds should be a fixed set;
• whether one policy per decision is too costly.
• The authors flag these security concerns for review: sybil rosters, griefing through fallbacks, decisions in flight, and allocation drift.