Skip to main content
T TON Adoption
Basics BASICS · 2026

DAOs on TON: Voting, Governance, and Frameworks 2026

What DAOs actually exist in the TON ecosystem, how voting works without an Aragon-style framework, off-chain Snapshot vs on-chain execution, and how to participate in governance.

Author
TON Adoption Team · research desk
Published
6 min read

A DAO — Decentralized Autonomous Organization — is a governance model where decisions are made by token holders or community members rather than a centralized team. On Ethereum the stack matured over a decade: Aragon, Compound Governor, OpenZeppelin Governor, Tally, Snapshot, Boardroom. On TON in 2026 the picture is fundamentally different — there is no single mature DAO framework that everyone uses.

That does not mean DAOs on TON do not exist. They do, but they are wired differently: usually off-chain Snapshot-style voting executed through a multi-sig, occasionally a hand-rolled Tact or FunC contract for a specific case. This guide unpacks which models work, who is already voting, and how to participate.

What a DAO is and why a project needs one

A minimal DAO has five moving parts:

  1. Voting rights — who can vote (token holders, SBT owners, KYC-verified members).
  2. Proposals — a formal procedure to put a question on the ballot.
  3. Quorum and threshold — the minimum participation and the share of “yes” votes needed.
  4. Execution — how an approved proposal becomes an action (a transfer, a parameter change, a proxy upgrade).
  5. Transparency — every step must be auditable.

The point of a DAO is to reduce trust in the team, give the community a legitimate influence channel, and distribute responsibility. In practice most DAOs even on EVM operate as advisory — voting is recommendation, the core team still ships.

Why TON has no Aragon analogue

There are architectural and cultural reasons:

  • Asynchronous messages. Aragon on EVM relies on synchronous execution: “vote ends, then proposal executes in the same transaction.” On TON DAO logic is split across many messages, which requires a different design pattern.
  • Ecosystem youth. Active DeFi development on TON only really started in 2022–2023. Three years is not enough for a universal stack to settle.
  • A strong TON Foundation. Decisions that an EVM project would hand to a DAO are often kept in the foundation on TON — that is faster but less decentralized.
  • Off-chain pragmatism. Many teams decide that Snapshot plus a multi-sig covers 90% of the real need at 10% of the effort, and skip a full on-chain governance build.

DAOs that already exist on TON

Despite the missing framework, several DAO initiatives are running in production:

  1. STON.fi DAO. STON token holders vote on protocol parameters: new pool listings, revenue distribution, router upgrades. Mix of off-chain and on-chain voting contracts.
  2. TON Society contributor voting. Inside TON Society, holders of specific SBT badges can vote on grant distribution, hackathon winners, and ecosystem program priorities.
  3. EVAA Protocol governance. Token holders vote on lending risk parameters (LTV, rates, new collateral listings).
  4. Tonstakers and staking pools. Some pool parameters are delegated to a vote of stakers.
  5. Ad-hoc community votes. Notcoin and DOGS communities periodically run off-chain polls and Snapshot votes on next steps.

It is not Compound-grade governance, but it is real activity producing real decisions.

Voting models in use

You will see three or four core schemes across TON projects:

ModelHow it worksWho uses it
Token-weighted (1 token = 1 vote)More tokens, more weight. DeFi default.STON.fi, EVAA
Quadratic votingWeight = √(balance), reduces whale power. Harder to defend from Sybil.Experimental
SBT-gated (1 person = 1 vote)Only holders of a non-transferable badge vote.TON Society
Delegated votingA delegate votes on behalf of others.Tonstakers pools

Each has trade-offs. Token-weighted easily turns into whale rule, SBT defends from plutocracy but introduces a “who issues the SBT” question, quadratic is mathematically elegant but exposed to address farming.

Off-chain vs on-chain in detail

Off-chain voting, Snapshot-style:

  • The user signs the vote with their wallet (gasless).
  • Signatures are collected on a server or IPFS.
  • The client tallies votes against a balance snapshot taken at proposal creation.
  • The result is a JSON the multi-sig executes by hand.

Pros: free, flexible, you can change the strategy without migrating a contract. Cons: the final step still needs a trusted multi-sig — formally the community cannot force anything.

On-chain voting via a DAO contract:

  • The proposal is written on chain.
  • Votes are on-chain transactions (paying fees).
  • Tallying and execution are automatic inside the contract.

Pros: trustless, execution guaranteed. Cons: expensive, inflexible, any bug in the contract needs a migration.

Most TON projects choose the hybrid: vote off-chain, mirror the outcome on chain for the public log, execute via multi-sig.

TON vs EVM governance stack

AspectEthereumTON
Mature DAO frameworksAragon, OZ Governor, CompoundNone universal
Voting UISnapshot, Tally, BoardroomSnapshot (generic) + custom
Delegation standardERC-5805Ad-hoc
Timelock equivalentOZ TimelockControllerMulti-sig wrapper
Active DAOsHundreds (Uniswap, Aave, ENS, …)A handful (STON.fi, TON Society)
Treasury under DAO controlBillions of dollarsTens of millions

The gap is obvious — and the niche is open. Teams willing to build a TON-native governance stack have room.

How to participate as a regular user

Practical steps:

  1. Register with TON Society via their official site and your Telegram account. Pick up the base SBT badge — it unlocks some votes.
  2. Hold the project token for the DAO you want to influence (STON, EVAA, native tokens of DEX or lending protocols).
  3. Follow proposal channels. Most DAOs have a Telegram channel or Discord with new-vote alerts.
  4. Vote through the official interface: either the project’s Snapshot space or an in-app governance tab.
  5. Delegate if you cannot keep up. Many pool-style governance models let you delegate to an active community member or a validator.

Where DAOs break: lessons from EVM history

Failure modes that will eventually surface on TON:

  • Quorum capture. If the quorum is low (5–10%), a whale holding 6% can pass anything alone. Defenses: high quorum (20–30%) and a timelock.
  • Flash-loan voting attacks. An attacker takes a flashloan in DAO tokens, votes, repays. TON has no clean EVM-style flashloans, but JIT liquidity and pool manipulation can mimic the effect.
  • Social-engineered multi-call proposals. Complex bundles hiding a malicious call. Defense: independent audit of every proposal before voting.
  • Backdoor in the executor. If the multi-sig has emergency functions, the DAO is decoration.

What to expect from TON governance over the next year

Reasonable bets for 2026–2027:

  • One or two candidate frameworks — Tact libraries at the OZ Governor level that try to standardize DAO development on TON.
  • TON Society maturing into a real ecosystem-level governance body (grants, standards votes).
  • Delegation as default. EVM took eight years to reach ERC-5805; TON can shortcut if it moves before the mass DeFi wave.
  • Regulatory pressure. The EU is debating DAO legal status — TON projects with European users will be affected.

Conclusion

DAOs on TON are still early. No universal framework, most governance is Snapshot plus multi-sig, active DAOs are a handful. But the direction is clear: STON.fi, EVAA, and TON Society are building the first working models, the patterns are forming.

If you hold tokens of TON projects — vote. Right now it is cheap (often free) and your voice actually matters, because participation is low. In two or three years, when DAOs become mainstream, your share of influence will shrink.

Frequently asked

Not in the Aragon or Compound Governor sense. As of May 2026 most TON DAO initiatives use off-chain Snapshot-style voting plus a multi-sig for execution. On-chain DAO logic is written ad-hoc in Tact or FunC per project, not from a shared standard library.
STON.fi runs governance around the STON token: holders can vote on pool parameters, revenue distribution, and listings. Some votes are off-chain via a Snapshot-like interface, others are executed through on-chain voting contracts.
Off-chain (Snapshot-style) collects signed messages from voters, tallies them, and hands the result to a multi-sig for human execution. On-chain voting lives entirely in a contract: counting and execution are automatic. Off-chain is cheaper and more flexible; on-chain is less trust-dependent.
Yes: either spin up a Snapshot space with a jetton balance strategy, or write a custom Tact contract that tallies token or SBT votes. There is still no universal Aragon-grade framework in the TON ecosystem, so each project does its own thing.

Related