Governance¶

The Agent Registry is currently operated by a single owner (COAI Research). This is appropriate for a prototype and testnet deployment, but it is not acceptable for a production system that governs the identity and compliance of autonomous agents at scale. This page describes the current state, the problems it creates, and the planned transition to decentralized governance.

Current State: Single Owner¶

The Agent Registry contract has a single owner address set at deployment. The owner has the following powers:

Power	Function
Add/remove regulators	`addRegulator()`, `removeRegulator()`
Change attestation grace period	`setAttestationGracePeriod()`
Change maximum generation depth	`setMaxGenerationDepth()`
Change trusted forwarder	`setTrustedForwarder()`
All regulator powers	Suspend, revoke, reactivate agents

Why Single Owner for Now

During the prototype and testnet phase, a single owner enables rapid iteration: bug fixes, parameter tuning, and emergency responses can happen immediately without coordination overhead. This is standard practice for early-stage smart contract deployments.

The Problem¶

A single owner creates several serious risks for a production registry:

Censorship Risk¶

A single owner can unilaterally suspend or revoke any agent, add arbitrary regulators, or change system parameters. This means one entity controls who is allowed to participate in the agent economy.

Single Point of Failure¶

If the owner key is compromised, lost, or the owner becomes unavailable, the entire governance mechanism is paralyzed. No new regulators can be added, no parameters can be changed, and no emergency actions can be taken.

Political Unacceptability¶

A global registry for autonomous agents cannot be controlled by a single research institution. Governments, enterprises, and other organizations will not adopt a system where one entity has unilateral authority over their agents.

Regulatory Incompatibility¶

The EU AI Act and similar regulatory frameworks require governance structures with checks and balances. A single owner model does not meet these requirements.

Governance Transition Roadmap¶

The transition from single owner to full DAO governance happens in five phases, each triggered by a milestone in registry adoption.

Phase	Governance Model	Trigger	Key Properties
Phase 0 (current)	Single owner (COAI Research)	Prototype and testnet	Fast iteration, full control
Phase 1	3-of-5 multi-sig	Mainnet launch	No single point of failure
Phase 2	Multi-sig + Timelock (48h)	100 registered agents	Public review period for changes
Phase 3	Governor + Timelock + multi-sig	1,000 registered agents	Token/reputation-weighted voting
Phase 4	Full DAO with regional regulators	10,000+ registered agents	Jurisdiction-aware, stakeholder-balanced

Phase 0: Single Owner¶

Current state. COAI Research controls the contract via a single deployer wallet.

Advantages: Fast, simple, allows rapid prototyping
Risks: All the problems listed above
Appropriate for: Testnet deployment, initial pilot agents

Phase 1: Multi-Sig¶

Ownership is transferred to a 3-of-5 multi-sig wallet. Five signers from different organizations must coordinate to take any governance action.

graph TD
    subgraph "3-of-5 Multi-Sig"
        S1["Signer 1<br/>COAI Research"]
        S2["Signer 2<br/>Academic Partner"]
        S3["Signer 3<br/>Infrastructure Provider"]
        S4["Signer 4<br/>Agent Developer"]
        S5["Signer 5<br/>Legal/Compliance Expert"]
    end
    MS["Multi-Sig Wallet<br/>(3 of 5 required)"]
    S1 --> MS
    S2 --> MS
    S3 --> MS
    S4 --> MS
    S5 --> MS
    MS --> REG["Agentenregister<br/>(owner = multi-sig)"]

Advantages: No single point of failure, requires coordination across organizations
Risks: Still a small group with full authority, no public review
Appropriate for: Mainnet launch, early production

Phase 2: Multi-Sig + Timelock¶

A Timelock contract is added between the multi-sig and the registry. All governance actions (parameter changes, regulator additions) are queued for 48 hours before execution, allowing public review and objection.

graph LR
    MS["Multi-Sig<br/>(3 of 5)"] -->|"queue action"| TL["Timelock<br/>(48h delay)"]
    TL -->|"execute after delay"| REG["Agentenregister"]
    PUB["Public"] -->|"review queued actions"| TL

Advantages: Public transparency, time to react to controversial changes
Risks: 48-hour delay for emergency actions
Emergency mechanism: The multi-sig retains an emergency bypass for critical security issues (e.g., contract compromise), but emergency actions are logged and auditable

Phase 3: Governor + Timelock + Multi-Sig¶

A Governor contract implements on-chain voting. Governance tokens or reputation scores determine voting weight. Proposals must pass a vote before being queued in the Timelock.

graph LR
    PROP["Proposal"] --> GOV["Governor<br/>(token/reputation-weighted voting)"]
    GOV -->|"if vote passes"| TL["Timelock<br/>(48h delay)"]
    TL -->|"execute"| REG["Agentenregister"]
    MS["Multi-Sig<br/>(emergency only)"] -.->|"emergency bypass"| REG

Advantages: Democratic governance, stakeholder representation
Risks: Governance attacks (vote buying, whale dominance)
Mitigations: Voting weight caps, delegation system, quadratic voting options

Phase 4: Full DAO with Regional Regulators¶

The final state: a multi-stakeholder DAO with jurisdiction-aware governance.

graph TD
    subgraph "Stakeholder Groups"
        AG["Agent Developers<br/>(builders)"]
        IP["Infrastructure Providers<br/>(enforcers)"]
        REG_BODY["Regulatory Bodies<br/>(oversight)"]
        RES["Researchers<br/>(standards)"]
    end
    subgraph "Governance"
        GOV["Governor Contract<br/>(weighted voting)"]
        TL["Timelock<br/>(48h)"]
        MS["Emergency Multi-Sig"]
    end
    subgraph "Regional Regulators"
        EU["EU Regulator"]
        US["US Regulator"]
        APAC["APAC Regulator"]
    end
    AG --> GOV
    IP --> GOV
    REG_BODY --> GOV
    RES --> GOV
    GOV --> TL
    TL --> CONTRACT["Agentenregister"]
    MS -.-> CONTRACT
    EU --> CONTRACT
    US --> CONTRACT
    APAC --> CONTRACT

Regional regulators have jurisdiction-specific authority (e.g., the EU regulator can suspend agents operating in the EU)
Stakeholder balance prevents any single group from dominating governance
Emergency multi-sig remains as a last-resort safety mechanism

Governance Mechanisms¶

The following mechanisms are planned for the full governance system.

Timelock¶

All non-emergency governance actions are delayed by a configurable period (default: 48 hours). This gives the community time to review proposed changes and raise objections.

Multi-Sig Emergency Override¶

A multi-sig wallet retains emergency powers to bypass the Timelock for critical security issues. Emergency actions are:

Logged on-chain with a required justification string
Subject to post-hoc review by the DAO
Rate-limited to prevent abuse

Regional Regulators¶

Regulators are scoped to jurisdictions. A EU regulator can suspend agents operating in the EU but cannot affect agents operating exclusively in other jurisdictions. This aligns with real-world regulatory structures.

On-Chain Voting¶

Proposals are submitted on-chain, debated during a review period, and voted on by token or reputation holders. Voting follows a standard Governor pattern (similar to OpenZeppelin Governor).

Delegate System¶

Token holders can delegate their voting power to trusted representatives. This allows passive participants to still have their interests represented without actively voting on every proposal.

Key Governance Principles¶

The governance system is designed around four non-negotiable principles:

Governance Guarantees

No single entity can unilaterally revoke an agent's registration -- except through the emergency multi-sig, which requires multiple signers and public justification
No single entity can change system parameters without notice -- the Timelock ensures at least 48 hours of public review
No single entity can censor the registry -- decentralized governance prevents any one organization from controlling who can register
No single entity can shut down the system -- the smart contract is deployed on a public blockchain and operates independently of any single server or organization

Governance and Compliance Interaction¶

Governance decisions directly affect the compliance framework:

Governance Action	Compliance Impact
Change `attestationGracePeriod`	Affects how often agents must attest
Change `maxGenerationDepth`	Affects how deep agent hierarchies can go
Add regulator	New entity can suspend/revoke agents
Remove regulator	Entity loses ability to suspend/revoke
Change trusted forwarder	Affects gasless registration flow

All of these actions flow through the governance pipeline (Timelock in Phase 2+) to ensure transparency and prevent surprise changes.