When the decentralised organisation already had hierarchy

A top-10 L1 by market cap hired FinDaS to design DAO governance for a flagship ecosystem protocol. The first useful insight was structural: the organisation already operated through layered review.

What problems did the governance design have to solve?

Decentralised in principle, hierarchical in practice

Even at L1 scale, the protocol's policy and design decisions moved through a review chain that more closely resembled corporate compliance than the flat-DAO ideal. Multiple layers, named approvers, sign-offs at each step. None of this was hidden, it just was not part of how the organisation talked about itself externally. Any governance design that ignored this structure would not survive the first internal review. Once it was clear that the design needed to be defensible to both a decentralisation-first community narrative and a corporate-style internal review process, the rest of the work followed from there.

A blockchain-native audience that defaulted to "one token, one vote"

Most DAO governance at the time of the engagement ran on the simplest possible model: tokens-as-votes, simple majority, no roles, no quorum thresholds. The audience expected this. The L1's scale and the protocol's economic surface area required something more layered, and the design had to make that case without being read as centralisation in disguise. As Hristo put it during one of the review sessions, asking blockchain-native people to consider corporate governance mechanisms is most of the work in any engagement of this kind.

Mechanisms with no precedent in the L1's own ecosystem

Continuous approval voting came from MakerDAO. Time-weighted voting power came from Curve. Hierarchical proposal classification with proportional quorum echoed corporate governance more than crypto practice. None of these had been deployed inside the L1's ecosystem before. Each one required the design to argue not just for the mechanic, but for the principle behind it. The pattern in those arguments was always the same: people accepted the mechanism when they accepted the principle, and they did not accept the mechanism until they did.

A design that had to work today and in three years

Most DAOs launch with one governance system and either ossify or rewrite it later under crisis conditions. The brief was a two-stage architecture: an early-stage process to ship quickly while the community formed, and a mature-stage process to handle complex policy without slowing the protocol down. The early stage had to be simple enough to be operable on day one, see FinDaS on token launch sequencing. The mature stage had to be expressive enough to handle the policy questions a top-10 L1's flagship application would eventually face.

How did FinDaS approach the problem?

The first sessions mapped who actually held authority over what: the protocol's core team, the L1's foundation, the ecosystem council, the eventual DAO community. Each was a distinct stakeholder with distinct review rights, and the governance design had to be legible to each one. What emerged from those sessions was not a list of features but a flowchart of approvers, and the rest of the design followed from that. The corporate-process observation surfaced here and shaped every subsequent choice in the design.

Each proposed mechanism was assessed by what it would deliver to each stakeholder. A staking lock on voting power would create real friction for short-term token buyers, see FinDaS on token staking for the underlying logic. A multi-stage proposal funnel would slow some decisions, which is useful for executive votes and harmful for routine ones. The four proposal types, Temperature Check, Governance, Executive, and Grant, emerged from this exercise as the smallest set that could distinguish low-stakes from high-stakes decisions without being read as bureaucratic.

For governance design, the modelling work is participation modelling and adversarial scenario analysis rather than emission curves. The questions are different: at what quorum thresholds does a determined minority lose, what happens to a single whale's influence under time-weighted voting power versus raw token count, where do the principal-agent problems show up when special roles can veto. Each mechanism was tested against capture scenarios: bribery, vote-buying, coordinated minority sabotage, single-actor delegation takeover.

The result of the modelling was a set of failure modes for each mechanism, paired with the mitigation built into the design. The 12-month voting power vesting curve answered the "buy tokens overnight to swing one vote and dump" scenario. The 2-day timelock on executive proposals answered the "rush a malicious smart-contract change through during a quiet week" scenario. The Security Council's near-unanimous multisig requirement answered the "single insider veto" scenario. For more on FinDaS's simulation approach, see tokenomics simulation.

Two deliverables shipped together. The governance design paper covered all four proposal types, the role definitions, the voting systems chosen for each kind of decision, and the full governance cycle from forum thread to on-chain execution. The supporting voting-systems research deck, prepared by the FinDaS research team, documented why each voting mechanism was chosen and what tradeoffs it carried. Both deliverables moved through the L1 ecosystem's multi-layer review chain, which is part of how the corporate-process observation was confirmed: design that does not survive that review does not reach the community vote.

What did FinDaS design?

1. A two-stage governance architecture

The early stage and the mature stage of the DAO had different goals, and the design treated them as different systems. Early-stage governance used a single-vote process: 100 voting power required to submit a proposal, 2% locked voting power required for quorum, 3-day vote, 1-day timelock, and only the Security Council role active. Mature-stage governance used the full process: separate Temperature Check and binding vote phases, 1% to 5% quorum thresholds depending on proposal type, 5-day mature-stage votes, 2-day timelocks, and both Stewards and the Security Council active. The mature stage also introduced continuous approval voting for the most consequential executive decisions. The transition between stages was not automatic. It was itself a governance decision the community could ratify when it judged that the conditions for the mature stage had been met.

2. Four proposal types with proportional voting overhead

Temperature Check proposals signalled willingness to consider a change. They required 1% voting power participation and resolved as a simple yes-or-no on Snapshot. Governance proposals covered process changes, addition of new features, and changes to special-role membership. They required 2.5% voting power participation and passed off-chain by simple majority. Executive proposals covered smart-contract changes, fee parameter adjustments, and treasury policy. They required 5% voting power participation, on-chain voting, and code audit by at least two unbiased parties for material changes. Grant proposals released treasury funds against a vesting schedule and required 2.5% participation with the beneficiary excluded from the vote. The principle: the more consequential a decision was, the more voting power had to be present for the decision to bind. Process changes did not require the coordination effort of smart-contract upgrades. The DAO could move fast on low-stakes decisions and slow on high-stakes ones, and the framework made it impossible to slip a smart-contract change through with the quorum threshold of a forum poll.

3. Time-weighted voting power

Tokens locked in the governance contract started at 25% of their full voting power and reached 100% after 12 months. The mechanism was an adaptation of Curve's ve-model, compressed from 4 years to 12 months because the protocol's expected first-year governance velocity was higher than DeFi's. LP tokens received a multiplier to encourage liquidity provision into governance positions. The intent was simple: voting power should reflect sustained commitment to the protocol, not short-term token accumulation. Anyone could buy a thousand tokens on the open market the morning of a vote, but those tokens would carry only 250 voting power at the moment of submission, not 1,000. Mass-buying to swing a specific vote was structurally discouraged, and the discouragement scaled with the size of the attempted swing.

4. A two-tier role architecture with separation of duties

Two roles, neither one able to act unilaterally. Stewards moderated the governance process: validating proposal compliance, prioritising community discussion, enforcing forum hygiene, rejecting malformed or trolling proposals with stated reasons. They could be voted in or out by simple majority. The Security Council executed on-chain decisions and held veto power for security-critical proposals, with a multisig requiring all-but-one signatures to cancel a malicious proposal. Council members needed coding qualifications, because the role included last-mile code audit. The structure was adapted from Decentraland's DAO Committee and Security Advisory Board pattern.

5. Continuous approval voting for the highest-impact executive decisions

Continuous approval voting was adapted from MakerDAO. The mechanism: for key smart-contract parameters such as fee rates, reward distribution rates, and buyback rates, a vote was never closed. The current state held only as long as it outvoted any challenging proposal. A new proposal could replace the current state only by exceeding the tally that established it. Voters supporting an active proposal received non-transferable support tokens that let them vote on other matters while keeping their continuous-approval position in place. The point of continuous approval voting is that the most expensive decisions to reverse get the highest defensive bar to change. A malicious executive proposal cannot pass with thin support during a quiet week, because the current state has the standing tally of the original decision behind it.

What were the results?

The engagement closed with two complete deliverables. The governance design paper covered the full architecture: principles, proposal types, voting systems, special roles, governance cycle, suggested early-stage proposals, and an explicit limitations section. The voting-systems research deck, prepared in parallel by the FinDaS research team, surveyed seven voting methods (single-choice, plurality, approval, instant runoff, cumulative, quadratic, and continuous approval) with worked examples from MakerDAO, Decentraland, GitcoinDAO, Uniswap, and others. The deck documented why each method was chosen or rejected for each kind of decision in the design.

The framework introduced into the L1's ecosystem a set of governance mechanisms that were not standard there at the time of the engagement: continuous approval voting, time-weighted voting power on a compressed curve, four-tier proposal classification with proportional quorum thresholds, and a two-role architecture with explicit separation between moderation and execution. None of these mechanisms were novel inventions. Each one was a proven pattern from a leading DAO, imported on the argument that the principle behind it transferred even when the protocol vertical did not.

The case for the engagement is not which mechanisms ultimately shipped in their original form. The case is that a decentralised organisation with substantial scale and a layered internal review process needed governance designed to be defensible at every layer, and the framework that emerged was structurally rigorous enough to be that. The two deliverables together formed the artifact: a complete, internally consistent governance design and the research that justified it.

What's next

FinDaS has applied the layered-governance approach to subsequent engagements where the client's organisation does not fit the flat-DAO ideal: large ecosystems with internal review chains, foundations governing multi-protocol portfolios, established institutions adding governance layers to existing operations. The two-stage architecture in particular has become a default starting point when the engagement involves an organisation that already has substantial scale before introducing on-chain governance. The principle holds across verticals: governance design has to be defensible to the organisation that already exists, not the one a clean-sheet DAO architecture would imagine.

Discuss your project with us