What a throttle is, and why it is not a quorum
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:
- Attention — voters and delegates can only read so much. This is the cost holographic consensus attacks by making prediction markets triage the queue.
- Gas and settlement work — someone has to pay to conclude every proposal, whether or not it passes.
- Storage — proposal metadata is written to a substate or contract that later operations must traverse.
- Legitimacy — a queue full of unserious proposals makes the serious ones harder to see, and makes low turnout look normal.
Sponsor thresholds: who may open a proposal
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.
Deposits, offerings, and who is really being charged
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.
Concurrency, size, and expiry caps
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.
Throttles that reach backwards
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.
The allowlist throttle, measured across one sector
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.
The trade-off nobody escapes
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.
How Caper approaches this
A caper carries four throttles, and the interesting one is a fee that was a settlement pre-payment until 11 September 2026 and is now simply a price on the agenda.
Opening a proposal costs a flat 500 XRD, paid in XRD at creation and banked by the caper it was proposed to rather than burned. The call takes exactly the fee out of the bucket it is handed and returns the remainder, so an over-payment comes back as change rather than tipping the treasury or aborting the call; what does not come back is the fee itself, which the caper keeps whether the proposal passes or fails. Winning a ballot and then executing costs a further 10% of the winning action's XRD-equivalent value, but that is a separate, later leg charged at the trigger and waived outright when the ballot itself answers “treasury pays”. The price of proposing is the flat 500 and nothing else.
Until the redeploy of 11 September 2026 that flat fee was set equal to the per-proposal settlement-gas allowance the treasury reimbursed cranks from — 500 XRD either way — so a proposal pre-funded the permissionless work of concluding it: Moloch's require(_proposalDeposit >= _processingReward) invariant reached independently, though held only as two constants written equal rather than asserted. The redeploy removed the allowance and the reimbursement with it, so each crank now pays its own network fee, and the 500 prices proposing and nothing else.
The proposer must also hold at least one of the caper's own tokens, checked as a proof at creation, which is a sponsor threshold set to the minimum non-zero value: membership, not magnitude. Metadata is capped at 512 bytes of title and 16,384 of description, and the source names the reason plainly — unbounded, the meta blob "is a free griefing lever on every write that touches its substate."
The fourth is a throttle deliberately left off. A caper sets no cap on the number of voters in a proposal, because settlement is chunked across transactions rather than iterating every ballot in one, so a large turnout cannot brick the settle path. It is worth stating as its own point: several throttles in this family exist only because concluding a proposal is a single unbounded loop, and making that loop resumable removes the need for the limit rather than tuning it.