# Onchain Governance Readiness

> Evidence-backed governance guidance for agents and builders choosing DAO, voting, execution, privacy, and treasury-control stacks.

- Status: active
- Review status: reviewed
- Last verified: 2026-06-09

## Why it matters

Onchain governance builders need more than a generic DAO tooling recommendation. Agents should distinguish voting contracts from voting UIs, offchain signaling from executable onchain proposals, treasury controls from voter eligibility, and public voting from private or anti-collusion voting before recommending a stack.

## Candidate change areas

### governance dao ops tooling surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: DAO operations tooling covers proposal creation, delegate profiles, voting interfaces, templates, Safe integration, organization settings, and governance admin workflows.
- Possible consequences:
  - Tally and Aragon are official-source-backed DAO operations surfaces but are registry coverage gaps until first-class records exist.
  - Agents should avoid recommending a governance UI without checking whether the underlying contract framework and voting model are supported.
  - Safe-first governance can be appropriate for treasuries and smaller organizations, but it should not be described as token-holder governance unless voting controls actually route execution.

### governance governor contract surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Governor contracts define proposal creation, voting, quorum, vote counting, and execution mechanics, but they are only one layer of a complete governance stack.
- Possible consequences:
  - Agents should separate the Governor contract from the UI, treasury wallet, timelock, indexer, voting token, and delegation layer.
  - OpenZeppelin Governor, Tally Governor deployment flows, and Aragon OSx are official-source-backed surfaces but are registry coverage gaps until first-class records exist.
  - Builders should not claim a DAO is production-ready from a Governor contract alone without reviewing token voting, roles, timelock, execution, and recovery controls.

### governance indexing auditability surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Governance UIs and agents need reliable indexing for proposals, votes, delegation, quorum, queueing, execution, cancellation, and treasury actions.
- Possible consequences:
  - Agents should verify proposal lifecycle state from contract events or indexed sources before claiming a proposal passed, queued, executed, or failed.
  - Governance frontends should account for Governor proposal IDs, description hashes, vote events, timelock operation hashes, and Safe treasury actions.
  - The Graph and Goldsky are registry-covered indexing options, but exact governance schemas and event coverage should be validated per framework.

### governance private voting surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Private governance voting requires choosing between membership privacy, vote privacy, coercion resistance, tally verification, and coordinator trust assumptions.
- Possible consequences:
  - Semaphore is a strong fit for anonymous group membership proofs and double-signaling prevention, but it is not a full DAO execution stack by itself.
  - MACI is a strong fit for private onchain voting and anti-collusion properties, but builders must document coordinator assumptions and supported networks.
  - Agents should avoid broad anonymity or coercion-resistance claims unless the chosen primitive and operational model support them.

### governance snapshot signal vs execution surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: medium
- Summary: Snapshot-style governance can mean offchain gasless signaling or Snapshot X fully onchain voting, and agents should not collapse those into one execution model.
- Possible consequences:
  - Agents should distinguish offchain Snapshot voting from Snapshot X, which documents fully onchain voting, onchain voting-power computation, and trustless proposal execution.
  - Offchain signaling can be useful for governance process and UX but should not be described as binding onchain execution without a separate execution path.
  - Snapshot and Snapshot X are official-source-backed surfaces but are registry coverage gaps until first-class records exist.

### governance timelock execution surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Timelocks and execution roles decide when approved proposals can affect protocol contracts, treasuries, and permissions.
- Possible consequences:
  - The timelock should hold governed assets, ownership, and access-control roles when proposals are meant to execute binding actions.
  - Proposer, executor, canceller, and admin roles are security-critical and should be reviewed before deployers renounce setup permissions.
  - Governance UIs and agents should distinguish proposal passage from queued, ready, executed, cancelled, or expired execution state.

### governance voting power delegation surface
- Status: reviewed
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Voting power and delegation determine who can propose, vote, meet quorum, and represent token holders or members.
- Possible consequences:
  - Agents should ask whether voting power comes from ERC20Votes, ERC721Votes, a wrapped legacy token, a membership list, or another strategy.
  - Proposal thresholds, quorum, voting delay, voting period, and delegation support should be treated as governance design choices, not defaults to copy blindly.
  - Gasless delegation or voting can improve participation, but it does not remove the need to verify voter eligibility and signature handling.

## Initiative intents

- **Plan an onchain governance stack** (plan-onchain-governance-stack) — Return the smallest credible governance stack for one DAO or protocol control model, with voting, execution, treasury, indexing, and privacy caveats separated.
- **Assess DAO tooling fit** (assess-dao-tooling-fit) — Decide whether a project should start from OpenZeppelin Governor, Tally, Snapshot X, Aragon OSx, Safe-first controls, or a smaller signaling-only flow.
- **Design a private governance vote** (design-private-governance-vote) — Check whether Semaphore or MACI fits a voting app, grant round, or DAO decision process that needs membership privacy, private votes, or anti-collusion properties.
- **Prepare a governance indexer** (prepare-governance-indexer) — Identify proposal, vote, queue, execute, cancellation, delegation, and treasury events that should be indexed before a governance UI or agent makes claims about state.

## Official sources

- [OpenZeppelin onchain governance guide](https://docs.openzeppelin.com/contracts/5.x/governance)
- [OpenZeppelin governance API reference](https://docs.openzeppelin.com/contracts/api/governance)
- [Tally documentation](https://docs.tally.xyz/)
- [Tally deploy a governor documentation](https://docs.tally.xyz/set-up-and-technical-documentation/deploying-daos/deploy-a-dao-with-token-voting/)
- [Snapshot documentation](https://docs.snapshot.box/)
- [Snapshot X overview](https://docs.snapshot.box/snapshot-x/overview)
- [Aragon documentation](https://docs.aragon.org/)
- [Aragon OSx DAO setup guide](https://docs.aragon.org/osx-contracts/1.x/guide-set-up-dao/)
- [Safe documentation](https://docs.safe.global/)
- [MACI documentation](https://maci.pse.dev/docs/introduction)
- [Semaphore documentation](https://docs.semaphore.pse.dev/)

## What the agent receives

```json
{
  "initiative": "onchain-governance-readiness",
  "name": "Onchain Governance Readiness",
  "status": "active",
  "registry_version": "2026.06.10-8752c9d",
  "supported_intents": [
    {
      "id": "plan-onchain-governance-stack",
      "title": "Plan an onchain governance stack",
      "related_changes": [
        "governance-governor-contract-surface",
        "governance-voting-power-delegation-surface",
        "governance-timelock-execution-surface",
        "governance-indexing-auditability-surface"
      ]
    },
    {
      "id": "assess-dao-tooling-fit",
      "title": "Assess DAO tooling fit",
      "related_changes": [
        "governance-dao-ops-tooling-surface",
        "governance-snapshot-signal-vs-execution-surface",
        "governance-governor-contract-surface"
      ]
    },
    {
      "id": "design-private-governance-vote",
      "title": "Design a private governance vote",
      "related_changes": [
        "governance-private-voting-surface"
      ]
    },
    {
      "id": "prepare-governance-indexer",
      "title": "Prepare a governance indexer",
      "related_changes": [
        "governance-indexing-auditability-surface",
        "governance-timelock-execution-surface"
      ]
    }
  ],
  "changes": [
    {
      "id": "governance-dao-ops-tooling-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "governance_operators",
        "dao_builders",
        "ai_agents"
      ],
      "possible_consequences": [
        "Tally and Aragon are official-source-backed DAO operations surfaces but are registry coverage gaps until first-class records exist.",
        "Agents should avoid recommending a governance UI without checking whether the underlying contract framework and voting model are supported.",
        "Safe-first governance can be appropriate for treasuries and smaller organizations, but it should not be described as token-holder governance unless voting controls actually route execution."
      ],
      "evidence_refs": [
        "official:tally-docs",
        "official:aragon-docs",
        "official:aragon-osx-setup",
        "official:safe-docs"
      ]
    },
    {
      "id": "governance-governor-contract-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "dao_builders",
        "smart_contract_developers",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should separate the Governor contract from the UI, treasury wallet, timelock, indexer, voting token, and delegation layer.",
        "OpenZeppelin Governor, Tally Governor deployment flows, and Aragon OSx are official-source-backed surfaces but are registry coverage gaps until first-class records exist.",
        "Builders should not claim a DAO is production-ready from a Governor contract alone without reviewing token voting, roles, timelock, execution, and recovery controls."
      ],
      "evidence_refs": [
        "official:openzeppelin-governance-guide",
        "official:openzeppelin-governance-api",
        "official:tally-deploy-governor"
      ]
    },
    {
      "id": "governance-indexing-auditability-surface",
      "type": "indexer_surface",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "indexer_teams",
        "governance_operators",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should verify proposal lifecycle state from contract events or indexed sources before claiming a proposal passed, queued, executed, or failed.",
        "Governance frontends should account for Governor proposal IDs, description hashes, vote events, timelock operation hashes, and Safe treasury actions.",
        "The Graph and Goldsky are registry-covered indexing options, but exact governance schemas and event coverage should be validated per framework."
      ],
      "evidence_refs": [
        "official:openzeppelin-governance-api"
      ]
    },
    {
      "id": "governance-private-voting-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "privacy_builders",
        "dao_builders",
        "grant_program_teams",
        "ai_agents"
      ],
      "possible_consequences": [
        "Semaphore is a strong fit for anonymous group membership proofs and double-signaling prevention, but it is not a full DAO execution stack by itself.",
        "MACI is a strong fit for private onchain voting and anti-collusion properties, but builders must document coordinator assumptions and supported networks.",
        "Agents should avoid broad anonymity or coercion-resistance claims unless the chosen primitive and operational model support them."
      ],
      "evidence_refs": [
        "official:maci-docs",
        "official:semaphore-docs"
      ]
    },
    {
      "id": "governance-snapshot-signal-vs-execution-surface",
      "type": "external_reference",
      "status": "reviewed",
      "priority": "medium",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "dao_builders",
        "governance_operators",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should distinguish offchain Snapshot voting from Snapshot X, which documents fully onchain voting, onchain voting-power computation, and trustless proposal execution.",
        "Offchain signaling can be useful for governance process and UX but should not be described as binding onchain execution without a separate execution path.",
        "Snapshot and Snapshot X are official-source-backed surfaces but are registry coverage gaps until first-class records exist."
      ],
      "evidence_refs": [
        "official:snapshot-docs",
        "official:snapshot-x-overview"
      ]
    },
    {
      "id": "governance-timelock-execution-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "smart_contract_developers",
        "governance_operators",
        "security_reviewers",
        "ai_agents"
      ],
      "possible_consequences": [
        "The timelock should hold governed assets, ownership, and access-control roles when proposals are meant to execute binding actions.",
        "Proposer, executor, canceller, and admin roles are security-critical and should be reviewed before deployers renounce setup permissions.",
        "Governance UIs and agents should distinguish proposal passage from queued, ready, executed, cancelled, or expired execution state."
      ],
      "evidence_refs": [
        "official:openzeppelin-governance-guide",
        "official:openzeppelin-governance-api",
        "official:safe-docs"
      ]
    },
    {
      "id": "governance-voting-power-delegation-surface",
      "type": "protocol_architecture",
      "status": "reviewed",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "dao_builders",
        "governance_operators",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should ask whether voting power comes from ERC20Votes, ERC721Votes, a wrapped legacy token, a membership list, or another strategy.",
        "Proposal thresholds, quorum, voting delay, voting period, and delegation support should be treated as governance design choices, not defaults to copy blindly.",
        "Gasless delegation or voting can improve participation, but it does not remove the need to verify voter eligibility and signature handling."
      ],
      "evidence_refs": [
        "official:openzeppelin-governance-guide",
        "official:tally-docs"
      ]
    }
  ]
}
```

---
Canonical: https://composewith.eth/initiatives/onchain-governance-readiness · JSON: https://composewith.eth/initiatives/onchain-governance-readiness/index.json