Most DAO design attention goes to how votes are counted – quorum and threshold design, token weighting, quadratic schemes. A throttle acts one stage earlier: it decides which proposals get to exist. Quorum rules answer "did enough weight participate?"; throttles answer "may this proposal be put in front of anyone at all?"
The distinction matters because the two failure modes are different. A badly-set quorum produces the wrong outcome. A missing throttle produces no outcome at all: an open proposal queue is a channel any address can write to, and a governance system whose voters are exhausted has effectively lost quorum without ever changing the number. The proposal lifecycle describes the stages a proposal passes through; this page covers the gates on the entrance.
Four costs are being rationed, and a given mechanism usually targets one of them:
The oldest throttle is a floor on the proposer. Compound's Governor Bravo – the template most token-weighted DAOs inherited – gates propose() on comp.getPriorVotes(msg.sender, block.number - 1) > proposalThreshold, measured one block back so the threshold cannot be met with a flash loan taken in the same block. The threshold is itself bounded: governance may set it anywhere between MIN_PROPOSAL_THRESHOLD of 1,000 COMP and MAX_PROPOSAL_THRESHOLD of 100,000 COMP, so no vote can raise the drawbridge past a hard ceiling or lower it to zero.
Bravo also ships the exemption that every threshold eventually needs. isWhitelisted(account) returns true while whitelistAccountExpirations[account] > block.timestamp, letting governance grant a named address time-limited permission to propose below the threshold – the standard remedy for the case where the people best placed to write proposals are not the people holding the most tokens. See voting power activation and delegation thresholds for how that floor interacts with delegation.
The Moloch lineage draws the line at membership rather than magnitude. In Moloch v2 any address can submit a proposal, but it sits inert until a member sponsors it into the voting queue – submitProposal and sponsorProposal are separate functions, the second carrying an onlyDelegate modifier, and the proposal struct records the sponsor's address alongside a sponsored flag. The queue is member-curated by construction. Baal, the v3 rewrite, makes the same idea numeric: sponsorThreshold is documented as a "minimum number of shares to sponsor a proposal (not %)", and a submitter above it self-sponsors, skipping the queue and starting its own voting clock in the same transaction.
Off-chain governance reaches the same design by social means. Long COVID Labs' own governance framework, LCL DP-1, requires a proposal to spend four days in the DAO's public Telegram and collect at least ten 👍 reactions including at least one from a named core-team member before it may go to a binding Snapshot vote. That is a sponsor threshold with a human quorum and a core-team veto, implemented entirely in emoji.
A price on proposing is the throttle most often reached for and most often mis-specified, because two different things get called the same thing.
A refundable deposit prices bad faith, not proposing. Moloch v2 holds a proposalDeposit – the deployed default was 10 ETH, roughly $1,000 at the time – and returns it when the proposal is processed. What it does not return is the processingReward (default 0.1 ETH), which _returnDeposit pays out of escrow to whoever calls the processing function, with the remainder going back to the sponsor. The contract enforces the relationship at construction: require(_proposalDeposit >= _processingReward). The deposit exists to fund the conclusion of the proposal, and only the leftover is a returnable bond.
A non-refundable offering prices access. Baal's proposalOffering is charged only to submitters below the sponsor threshold – the code comments call it an "Optional anti-spam gas token tribute" – so members propose free and outsiders pay. That is a deliberate two-tier entrance, and worth naming as such: a fee framed as anti-spam is frequently a membership boundary wearing a price tag.
The distinction has a practical test. Ask what the money is for. If it funds the work of concluding the proposal, it is a settlement pre-payment and it should be sized to that work. If it is returned on good behaviour, it is a bond and should be sized to the harm. If it is neither returned nor spent on the proposal, it is a toll, and the honest question is who it is meant to keep out.
Thresholds bound who; the rest of the throttle family bounds how much.
One proposal at a time. Governor Bravo enforces a per-proposer concurrency cap of exactly one, and does it twice – propose() reverts with "one live proposal per proposer" if the caller's latest proposal is in either the Active or the Pending state. Checking both matters: a cap that only looked at Active could be defeated by queueing proposals during the voting delay.
A cap on the whole queue. A per-proposer limit does nothing against many proposers, so systems that automate proposal creation tend to add a global one. DAOhaus's agent runbook, AGENT_TASKS.md, instructs an autonomous member to open no new proposal while three are already in voting – a queue-depth cap chosen because the constraint being protected is human review capacity, not chain capacity. The same document tells the agent to read process-readiness from the contract's own state(id) rather than an indexer's flag, which is the operational half of the same discipline.
Payload caps. Bravo sets proposalMaxOperations = 10, bounding how many actions one vote can authorize – a limit on blast radius as much as on cost, and a close relative of typed versus arbitrary execution. Baal takes the storage-side route and persists only hashOperation(proposalData), keeping the payload off-chain entirely and the hash as the commitment.
Expiry. Baal proposals carry an expiration field, required to be either zero or later than block.timestamp + votingPeriod + gracePeriod, so a proposal can be written to die rather than linger. An expiring queue is self-cleaning; a permanent one accumulates.
The subtle members of the family apply after a proposal is already live, and they exist because eligibility can change mid-flight.
Governor Bravo lets anyone cancel a live proposal once its proposer's voting power has fallen below proposalThreshold – for a whitelisted proposer, only the whitelistGuardian may do it. The effect is that the threshold is a continuing requirement, not an entry test: a proposer who borrows or is delegated enough weight to propose and then gives it up loses the proposal too.
Moloch's jailed field is the membership analogue. A member with a passing guild-kick proposal against them is barred from both voting and sponsoring, and several code paths refuse to act on a jailed applicant at all – the throttle prevents a member on the way out from filling the queue on the way.
Baal's minRetentionPercent is the most interesting of the three because it throttles on the voters' behaviour rather than the proposer's: a proposal auto-fails if more than (1 − minRetentionPercent) of total shares exit before it is processed. It is a rate limit on governing a membership that is leaving, and a structural answer to the ragequit-then-execute problem that governance timelocks address from the other end.
Snapshot ships the Moloch idea as a space setting rather than a contract, which makes it the cheapest throttle in this family to deploy and the easiest to leave in place unexamined. A space's proposal validation, in Snapshot's own words, “determines who is allowed to create a proposal”, and an admin picks one of two shapes: basic validation, which checks a proposer's voting power against a minimum threshold, or restricting proposals “to authors only” – a named allowlist, in which the Admin, Moderator and Author roles each carry permission to create proposals and no other address has it. The public API exposes the choice as filters.onlyMembers. There is no threshold to tune, no deposit to size and no contract to deploy, and it stops spam completely.
What it costs shows up only over time, so it is worth measuring rather than arguing about. Bio Protocol's BioDAO cohort makes an unusually clean test set: the organizations are independently governed and separately funded, but they describe their governance in identical terms, because Bio Protocol's own documentation supplies the description – token holders “use their tokens to vote on key proposals, such as which projects to fund, changes to the DAO's strategy, and how to manage the community treasury”. Every Snapshot space belonging to a decentralized science organization covered by this wiki was read off the public Snapshot hub on 18 August 2026.
| Snapshot space | Proposals | Followers | Proposal gate | Authorized proposers | Last proposal closed |
|---|---|---|---|---|---|
| vote.vitadao.eth (VitaDAO) | 129 | 1,554 | authors only | 13 | 16 Sep 2025 |
| hairdao.eth (HairDAO) | 33 | 62 | authors only | 3 | 14 Jul 2026 |
| vote.cryodao.eth (CryoDAO) | 30 | 115 | authors only | 6 | 31 Jul 2026 |
| psydao.eth (PsyDAO) | 29 | 51 | authors only | 2 | 14 Jul 2026 |
| researchhub.eth (ResearchHub) | 29 | 89 | authors only | 4 | 22 Jan 2026 |
| genomesdao.eth (GenomesDAO) | 21 | 123 | basic validation | any address above the threshold | 18 Feb 2025 |
| cerebrumdao.eth (Cerebrum DAO) | 20 | 91 | authors only | 3 | 31 Dec 2025 |
| athenadao.eth (AthenaDAO) | 18 | 56 | authors only | 5 | 3 Sep 2025 |
| longcovidlabs.eth (Long COVID Labs) | 6 | 12 | authors only | 6 | 7 Oct 2025 |
| vitarna.eth (VitaRNA IP token) | 5 | 11 | authors only | 1 | 19 May 2025 |
| rejuveai.eth (Rejuve.AI) | 2 | 10 | authors only | 2 | 18 Dec 2025 |
| labdao.eth (LabDAO) | 0 | 20 | basic validation | any address above the threshold | never |
Ten of the twelve restrict proposal creation to an author allowlist, and the allowlists are small: between one and thirteen addresses, median three and a half, across spaces carrying 2,051 followers between them. VitaDAO, the largest DeSci DAO on every other measure, has the largest allowlist at thirteen. VitaRNA, the governance space for a fractionalised IP-NFT, has one, and it has opened nothing since that allowlist's sole address moved the asset's holding company in May 2025.
Nine of the twelve have not opened a proposal in more than two hundred days. The correlation is not the finding, and it should not be read as one: the three spaces still holding votes are allowlisted too, and an open gate rescued neither of the two spaces that has one. What the gate changes is the failure mode.
A space whose proposal rights sit with token holders can go quiet and be restarted by any holder who cares enough to write something; the bar may be set high, but there is a bar and it is public. A space whose proposal rights sit with five named addresses stops when those five stop, and a holder who wants to restart it has no procedure to follow – not a threshold too expensive to reach, but no threshold at all, because the gate is an identity check and identities cannot be acquired.
Two pages on this wiki record what that looks like from inside. AthenaDAO cleared quorum on all eighteen proposals it ever ran, then stopped: its last closed on 3 September 2025, a fortnight before the organization announced the equity vehicle that superseded it, and the space has stood silent ever since, behind a five-address allowlist. VitaDAO has closed exactly one proposal since February 2025 while its own token page still sells VITA, in the present tense, as the way to vote on which research gets funded. In neither case did holders decline to propose. In both cases no holder could.
The mirror image sits at the other end of the same dial, where an ungated space fills with airdrop-phishing posts until genuine proposals are a minority of the record – measured on proposal spam and the governance denominator. Between the two lies the trade-off below, and a sector that has answered it in one direction almost unanimously without appearing to have deliberated about it.
Every throttle listed here works, and every one of them raises the floor on who can participate. A 100,000 COMP proposal threshold makes spam impossible and makes independent proposing the preserve of large holders and whitelist grantees. A member-sponsorship gate keeps the queue serious and makes the member set the gatekeeper of what the DAO is allowed to consider. A non-refundable offering deters drive-by proposals and charges exactly the people who are not yet inside.
Two rules of thumb survive contact with the implementations above. First, price the work, not the person: a charge sized to the cost of concluding a proposal is defensible at any wealth level, while a charge sized to deter is a wealth test by construction. Second, cap the queue, not the proposer, where you can – a depth cap on proposals in voting protects reviewer attention without asking who wrote them, whereas a per-proposer cap is trivially defeated by using two addresses.
The honest reading of the record is that most DAOs adopt throttles reactively, after a queue fills or a treasury is griefed, and inherit whichever numbers their framework shipped with. The parameters are rarely revisited even as the token distribution that made them reasonable changes underneath them.
A caper carries three throttles and leaves a fourth off on purpose.
Opening a proposal costs a fee, paid at creation and kept by the caper it was proposed to whether the proposal passes or fails; an over-payment comes back as change. The fee rises with the value of the largest option, because the winner is unknown at creation, so a large ask cannot shelter behind a cheap decoy. Carrying out a passed proposal costs nothing more.
The proposer must also hold at least one of the caper’s own tokens, which sets the sponsor threshold at membership rather than magnitude. Titles and descriptions have size caps and a proposal takes a limited number of options, because every unbounded field is a cost imposed on each later read of the proposal.
The throttle left off is a cap on voters. The count runs in chunks across several transactions rather than in one pass over every ballot, so a large turnout cannot stall it. Several throttles in this family exist only because concluding a proposal is a single unbounded loop; a count that can resume where it stopped needs no such limit.