Launching the On & Offchain DAO Protocol

Toronto, ON — Nov 27th, 2025

Agora announces the On & Offchain DAO Protocol: A light and attestation based framework for transparent management of proposals.

Governance shouldn't require a token standard.

Today we're announcing the On & Offchain Attestation DAO Protocol (OOADAO) — a new open standard for DAO creation and governance built on top of https://attest.org/. The protocol is live on Ethereum, Base, and Optimism. We're open-sourcing the full implementation in the first quarter of 2026.

The Problem

Most DAO governance stacks today are tightly coupled to ERC20 token contracts. If you want to run a vote, you need an ERC20 token that implements IVotes — complete with checkpointing, delegation, and snapshot logic baked directly into the token itself. This creates real friction:

• Not every community has an ERC20 token, and not every community should need one to govern itself.
• Voting power doesn't always come from a single token. It might come from NFT holdings, staking calculations, multisig membership, identity credentials, badge systems, or offchain reputation — disparate sources that don't fit neatly into ERC20Votes.getVotes().
• Deploying and maintaining governance contracts is expensive. Governor, Timelock, token wrappers, delegation registries — it adds up fast.

The question we kept asking was: what if you could run a full governance lifecycle with nothing more than signed attestations?

How It Works

OOADAO defines a small, composable vocabulary of attestation verbs that together describe the complete lifecycle of a DAO:

• INSTANTIATE — Declare a DAO and its initial authority.
• GRANT — Delegate permissions (propose, vote, administrate) to addresses with fine-grained bitmask levels.
• CREATE_PROPOSAL_TYPE — Define voting rules: standard majority, approval voting, or optimistic governance.
• CREATE_PROPOSAL — Submit proposals with start/end timestamps and flexible configuration.
• SIMPLE_VOTE / ADVANCED_VOTE — Cast votes, either as simple for/against/abstain choices or as rich JSON payloads for approval and weighted voting.
• BADGE_DEFINITION / IDENTITY_BADGE — Define and assign identity badges that distinguish participants for governance and recognition.
• DELETE — Retroactively nullify any attestation, with proper authorization.

Every one of these is an EAS attestation — a signed, structured data object that can live onchain or offchain. There's no Governor contract. No Timelock. No token wrapper. Just attestations, linked together by dao_uuid and proposal references.

Voting Power Without ERC20IVotes

This is the key unlock. Because votes are attestations — not contract calls against a token's checkpoint history — voting power can come from anywhere.

A SIMPLE_VOTE attestation contains a voter address and a choice. The weight of that vote? That's determined by whatever source of truth your DAO recognizes. An indexer or client can verify voting power against:

• An ERC20 balance snapshot
• An ERC721 or ERC1155 holding
• An IDENTITY_BADGE attestation issued by the DAO itself
• A Gitcoin Passport score
• An offchain database of verified contributors
• Any combination of the above

The protocol deliberately separates the act of voting from the verification of voting power. This means a single DAO can accept votes from members whose authority comes from completely disparate sources — token holders, badge recipients, credentialed participants — and tally them together coherently.

Identity and Badges

The protocol includes first-class support for identity through Badge Definitions and Identity Badges. DAOs can define badge types ("Security Council Member," "Core Contributor," "Season 5 Delegate") and issue them to participants. These badges are EAS attestations themselves — portable, revocable (if configured), and composable with the rest of the governance stack.

This means identity verification isn't an afterthought bolted onto a token-voting system. It's a native part of the protocol, sitting alongside proposals and votes as a first-class primitive.

Onchain or Offchain — Your Choice

Every attestation in the protocol can be issued onchain (with optional custom resolver contracts for enforcement) or offchain (as signed EIP-712 payloads). This gives DAOs a spectrum of options:

• Fully onchain with resolver contracts that enforce invariants like double-vote prevention and voting windows.
• Fully offchain with signed attestations verified by an indexer — zero gas costs for voters.
• Hybrid — proposals onchain, votes offchain, or any other combination.

The protocol is already deployed with resolver contracts on Ethereum mainnet, Base, and Optimism, with testnet deployments on Sepolia.

Open Source in Q1 2026

We're open-sourcing the full protocol specification, the resolver contracts, and the CLI tooling in Q1 2026. The protocol spec (v0.2.0) is finalized and the deployments are live today for multiple DAOs. We are hopeful a community may build on this — indexers, frontends, alternative resolver implementations, integrations with existing governance tooling.

The design is intentionally minimal. Most enforcement logic lives in indexers and clients, not in onchain contracts. This makes the protocol cheap to adopt, easy to extend, and compatible with governance models that don't exist yet.

If you're building a DAO that doesn't fit the ERC20-Governor mold — or if you're tired of wrapping tokens just to get checkpoint support — this protocol is for you.

Reach out to learn more. Mention OODAO for a special gift!

Stay tuned. We'll be sharing the repositories soon.

The On & Offchain Attestation DAO Protocol is built on https://attest.sh/ and deployed on Ethereum, Base, and Optimism.