As decentralized governance evolves from fringe experiment to essential infrastructure across Web3, a new kind of builder is emerging—one who understands that “code is law” isn’t just a philosophy, it’s architecture. On Flow, this journey begins with Cadence, a smart contract language that was built for composability, safety, and ownership at its core.
This isn’t just about deploying proposals or running a token vote. This is about engineering governance systems that can adapt, endure, and scale. If your DAO needs to be more than a Discord with a wallet, Cadence might be the blueprint you’ve been looking for.
Why Cadence Fits DAO Logic Like a Glove
Cadence isn’t your typical smart contract language. It doesn’t try to look like JavaScript or pretend Solidity is the gold standard. Instead, it’s resource-oriented, meaning it enforces ownership and access rights directly into the type system. That changes everything when you’re building systems meant to govern other systems.
Three design principles of Cadence make it uniquely effective for DAO development:
- Resources Think of resources like tokens, proposals, or voting rights, objects that can’t be copied and must be explicitly transferred. This creates a powerful trust model by default.
- Capabilities These define who can do what. Capabilities in Cadence act like programmable permissions, clean, controlled, and explicit.
- Clarity and Safety Cadence is intentionally strict. That may slow you down in the short term, but it’s a feature, not a bug. Especially when the stakes are high.
Modeling a DAO Proposal
Let’s walk through what this looks like in code.
At the core of every DAO is the ability to propose action. Here’s a simple resource that captures a proposal with votes:
cadence
CopyEdit
pub resource Proposal {
pub let id: UInt64
pub let description: String
pub var votes: {Address: Bool}
init(_id: UInt64, _description: String) {
self.id = _id
self.description = _description
self.votes = {}
}
pub fun castVote(voter: Address, support: Bool) {
self.votes[voter] = support
}
}
This model gives us:
- A unique ID for each proposal
- A human-readable description
- A votes mapping to track each participant’s stance
Votes are binary here, support or oppose, but this could easily evolve into weighted voting or rank choice later.
Vote Delegation (Because Not Everyone Votes)
Now let’s add some nuance.
What happens when someone can’t vote, but wants to empower someone else to vote on their behalf? That’s delegation, and it matters, especially in large communities or time-constrained environments.
Here’s a basic resource to enable that:
cadence
CopyEdit
pub resource Voter {
pub let owner: Address
pub var delegate: Address?
init(owner: Address) {
self.owner = owner
self.delegate = nil
}
pub fun setDelegate(newDelegate: Address) {
self.delegate = newDelegate
}
}
This opens the door to representative governance. Think of it like staking your voice to someone who shares your values, or has more time to attend the meetings.
Proposals + Quorum = Governance
A DAO without execution logic is a group chat. To actually do something, we need to define how many votes are required to move a proposal forward. That’s quorum.
Here’s a simple DAO contract that handles proposal creation and execution:
cadence
CopyEdit
pub contract DAO {
pub var totalMembers: UInt64
pub var proposals: @{UInt64: Proposal}
init() {
self.totalMembers = 0
self.proposals <- {}
}
pub fun createProposal(description: String): UInt64 {
let proposalId = UInt64(self.proposals.length) + 1
let newProposal <- create Proposal(_id: proposalId, _description: description)
self.proposals[proposalId] <-! newProposal
return proposalId
}
pub fun executeProposal(proposalId: UInt64) {
let proposal <- self.proposals.remove(proposalId)
?? panic(“Proposal not found”)
let voteCount = proposal.votes.length
let quorum = self.totalMembers / 2
if voteCount >= quorum {
// Execute your business logic here
} else {
panic(“Quorum not met”)
}
destroy proposal
}
}
There’s a lot more we could add:
- Time-based voting windows
- Weighted votes based on stake
- Reversible actions or proposal expiration
But this gives you a solid foundation to build upon.
The Real-World Challenge: Mutable Governance
Cadence shines in enforcing ownership and limiting access, but what happens when your DAO needs to evolve?
DAOs aren’t static. Governance parameters change. Rules change. And unless you design for that from the start, you’ll be stuck in upgrade hell.
A few best practices:
- Parameter Resources Store values like quorum threshold and voting duration in a resource so they can be safely updated.
- Governance Controllers Create admin resources whose access is governed by voting outcomes, not individuals.
- Modular Contracts Split critical logic from variable logic. This keeps upgrades focused and reduces risk.
The Emerald City Stack
If you’re building on Flow, don’t start from scratch. The Emerald City DAO is doing the heavy lifting.
It’s the de facto home for:
- Cadence contract templates
- Wallet integration guides
- Voting + delegation modules
- A functioning on-chain DAO governed by FLOW holders
Visit the GitHub: https://github.com/emerald-dao
Looking Ahead
As Flow continues to scale, across gaming, identity, NFTs, and beyond, DAO tooling will evolve from nice-to-have to non-negotiable. The ability for communities to govern protocols, manage treasuries, and control IP without relying on centralized intermediaries will define the next era of digital organization.
Future integrations will likely include:
- Flow-native identity systems like Flowns
- NFT-gated proposal access
- Token staking as a voting mechanism
Cadence’s resource model, access control, and composability give it an edge here. If you’re thinking about on-chain governance, you won’t find a more secure or expressive foundation than Flow.
DAO logic often feels theoretical. On Flow, it’s becoming tangible, modular, testable, and composable.
Now is the time to build.
