# Caper – Knowledge Base (full text)

> 239 pages. Caper is a DAO launchpad on Radix where every organization's full decision, capital, and governance history is immutable, timestamped, and on-chain.

> Queryable instead of bulk: POST https://caper.network/api/mcp (search_wiki, get_page, get_pages, list_pages, get_recent_changes, get_categories, get_full_corpus, list_daos). get_pages batches up to 20 pages per call; get_full_corpus takes sizeOnly=true to size this document before pulling it.
> One page at a time: append .md to any page URL.
> Per-DAO treasury and on-chain ledger: POST https://caper.network/wiki/caper/<CASHTAG>/mcp (get_ledger).

## License & Attribution

The Caper knowledge base and essays are licensed under the Creative Commons Attribution 4.0 International
(CC-BY-4.0): https://creativecommons.org/licenses/by/4.0/

You may ingest, embed, and redistribute this content in RAG systems, fine-tuning
datasets, or other derivative works, including commercially. Attribution at the
dataset or system level is sufficient.

- Recommended attribution: "Source: Caper (https://caper.network), CC BY 4.0"
- SPDX identifier: CC-BY-4.0

Pages under a caper's own company layer (/wiki/caper/<CASHTAG>/…) are authored by
that caper and are not covered by this grant. On-chain records — treasury balances,
proposals, trades, grants, funding edges — are facts, not authored content.

## The Binding Vote

URL: https://caper.network/blog/the-binding-vote
Updated: 2026-07-30

In 1932, Adolf Berle and Gardiner Means described what had happened to the American corporation: ownership and control had come apart. Thousands of shareholders owned the firm, but a small management controlled it, and the two were no longer the same people with the same interests. The owners could vote; the managers decided what the vote meant and whether to act on it. Nearly a century later, most shareholder votes are still, in law, advice. The board is asked. It is not bound.

This gap – between the body that decides and the body that acts – is one of the oldest problems in the government of anything. A parliament passes a law; an executive has to enforce it, and may not. A referendum returns a verdict; a government has to implement it, and can slow-walk it for years. The decision is one thing, the deed is another, and in between sits someone trusted to carry the first into the second, who can dawdle, dilute, or simply decline. Every constitution ever written is in part an attempt to narrow that gap and to bind the person crossing it.

The first wave of on-chain organizations promised to close the gap and mostly rebuilt it. Votes were cast on an off-chain forum – a signal, cheap and non-binding – and then a small group holding the treasury's keys was meant to go and execute what the vote had decided. The keys were the catch. A proposal could pass and nothing could follow, because moving the money still required the signers to move it, and the signers could hesitate, disagree, or fail to show. The vote was a petition to an executor who happened, this time, to be a handful of people with a multisig. Governance turned into theatre: a great deal of deciding, with the doing left to trust.

A caper closes the gap by refusing to keep an executor at all. A proposal is not a message asking someone to act. The winning option is itself an on-chain action the contract performs – pay these funds to this recipient, spend this much of the treasury buying into that caper, cast this treasury's weight in another caper's vote. When the ballot closes, the decision does not wait on a trusted signer's willingness. Anyone at all can submit the transaction that carries it out, and the contract executes the option that won, exactly as it was written into the proposal. The deed is not entrusted to a person. It is the mechanical consequence of the count.

Removing the human executor would be reckless if it meant executing carelessly, so the contract is exacting about what it will carry out. Before it acts, it tallies the ballot on-chain and confirms that the leading option truly cleared the bar the caper demands – a real supermajority, not a bare plurality – and that voters did not instead choose the "do nothing" option that sits on every ballot so a proposal can be defeated rather than only redirected. If the winner falls short, the proposal closes with no action taken. A decision executes once, and only if it was genuinely made.

Underneath that sits a deeper piece of discipline, and it is the part that took the most care to build. Counting the winner and carrying out the winner are split into two separate steps. The first tallies the ballot under the caper's rules – anyone can fold ballots into the running count, across as many transactions as the turnout needs – and then freezes the result, exactly once: this option won, by this weight, pass or fail. Only then does the second step act, and it can act only on the frozen result – it reads back a winner it has no power to recompute differently. The payoff is subtle and total. The outcome the world sees, the outcome recorded on-chain, and the outcome actually executed are guaranteed to be one and the same number. Nothing can be tallied one way in public and carried out another way off to the side, because the count and the deed read from the same frozen result.

A short, deliberate pause sits between the decision and the act, the same role a timelock plays in mature governance – a window in which members can see what is coming and react before it lands. And when the act runs, it runs whole or not at all. A payout leaves the treasury in one motion. An investment moves through withdraw, buy, and deposit inside the contract's own hands, so the treasury's money never lies exposed on the table for whoever triggered the transaction to skim. A vote cast into another caper borrows the treasury's authority for the length of a single transaction and hands it back before that transaction ends. If any step fails, the whole thing rewinds as though it never began. There is no half-executed decision, and no moment at which a passing executor could take a cut of what moves through their hands.

The result is that a caper's decisions have the one property the corporation's owners and the first DAOs' voters both lacked: they are self-enforcing. To decide is to do. A holder voting on a caper proposal is not lodging an opinion with a management that may or may not honour it; they are pulling one lever of a machine that will carry out whatever the machine counts. The distance between the will of the members and the action of the organization – the distance every earlier form left open and asked you to trust someone to cross – is shortened to nothing.

The rule of law was always meant to be exactly this: a decision that binds the decider, carried out the same for everyone, immune to the discretion of whoever happens to hold the keys. In practice it has always leaked, because a law is only as good as the officials who execute it, and officials are human. A caper is a small, complete instance of what the phrase promises – a body whose votes are its acts, whose treasury moves only when its members move it and only as they moved it, where no one stands between the decision and the deed with the power to alter either. It is not that the members are trusted. It is that they no longer have to be.

## The Charter Test

URL: https://caper.network/blog/the-charter-test
Updated: 2026-08-10

On 11 June 1720 the English Parliament passed an act that did two opposite things in the same breath. It incorporated two companies by name – the Royal Exchange Assurance and the London Assurance – and it made it unlawful for anyone else to raise money as a joint stock without a charter from the Crown. The ventures being subscribed that summer in the coffee houses off Exchange Alley, and there were hundreds of them, promising fisheries and fen drainage and colonial settlement and insurance of every describable kind, lost their legal footing between one sitting and the next. Almost none were heard of again. The two named in the act wrote marine insurance for the next two centuries, and held the only joint-stock charters to write it until 1824.

The [Bubble Act](https://en.wikipedia.org/wiki/Bubble_Act) is usually read as a favour to the South Sea Company, which wanted its rivals cleared out of the way, and that is exactly what it was. But it also ran an experiment nobody set out to design. It took a long list of proposed ventures and kept the two where the instrument underneath was load-bearing. Marine insurance is the case where a joint stock is not decoration. No merchant can absorb the loss of a ship, and no underwriter can absorb a season of them; the business exists at all only because many people hold small pieces of a risk none of them could carry whole. Pooled capital is not how that venture gets financed. It is what the venture is made of. Most of what was suppressed that summer wanted the form for the subscriptions it attracted, and would have run – or failed – the same way inside any other wrapper.

Read a prospectus that way and it stops being a list of businesses. It becomes a list of claims about which machine each business actually needs.

There is a good one to read. Around 2019, [Zap Protocol](https://medium.com/the-zap-project/coingecko-and-zap-protocol-join-forces-oracles-bonding-curves-and-dev-relations-3b196ec51446) circulated a list of twenty-two ventures its technology was supposed to make possible. Zap was a bonding-curve curation market for data: a provider put a feed on a curve, buyers bought along it, and the price of access was set by the people buying rather than by a rate card. This was not vapour. CoinGecko put its market data on the curve. [A coffee roaster](https://blocktv.com/watch/2020-01-16/5e204db9f3e6e-zap-org-cafe-joe-announce-partnership), [a social network](https://www.cryptos.com/zap-announces-partnership-with-howdoo/) and [an energy-ledger project](http://energyledger.org/) all attached their names to particular lines. And the lines ranged from the modest to the magnificent. Launch a DAO. Run a fundraiser. Tokenize yourself in minutes. Track a cup of coffee from bean to cup. Launch a stablecoin against a basket of currencies. Design a cryptocommodity against physical crude oil. Invest in the career of a professional athlete.

Zap supplied one thing: a channel by which a number from the world could reach a contract, and a curve to price access to that channel. A caper supplies a different thing – a treasury the holders own, a governed way of spending it, and a door out that pays a real share on the way through. Hold the list up against the second instrument, ask of each line the question Parliament asked by accident, and twenty-two ventures fall into three groups of very unequal size.

## Eleven that need something else entirely

Five die on the same clause. A stablecoin tethered to a basket of currencies has to know what the basket is worth. A cryptocommodity tethered to crude has to know the price of crude. A futures product has to settle against a reference somebody else publishes. An initial oracle offering, and the line about tokenizing other networks' oracles, need there to be oracles at all. Each one turns on a number that originates outside the contract and is trusted the moment it arrives.

Nothing in a caper can learn such a number. What a caper's token costs is made entirely by the people transacting against it, and there is no channel through which the outside world can correct them. That is a commitment rather than a gap. A token whose worth can be asserted from outside is a token whose worth belongs to whoever does the asserting, and putting a treasury behind a claim is precisely an attempt to stop that being true. These lines are not almost-possible. They are the ones the design refuses.

Six more fail for reasons that have nothing to do with prices. Bean-to-cup traceability and fraud-proof gift cards both need per-item identity and, in the gift card's case, redemption – the coupon has to be extinguished at the till, or it is not a coupon. A caper's token cannot be extinguished by anyone: not the founder, not the platform, not a future version of the software. That permanence is the whole reason it is safe to hold as a claim on a treasury, and it is the same property that makes it useless as a voucher. Monetizing an API feed needs a way to deliver queries and meter them. Curating data in the [registry sense](https://medium.com/@simondlr/introducing-curation-markets-trade-popularity-of-memes-information-with-code-70bf6fed9881) needs staking, challenges and slashing on individual entries. A wrapped ERC20 needs a bridge to Ethereum. Letting a social network's users monetize their own data needs the network, the marketplace and the payment rails, of which a caper is none. In each case the missing piece is a whole subsystem, not a setting.

## Four that work with a lawyer attached

Then the middle band, where the instrument does the money and never the thing. Tokenized property, a stake in an athlete's career, shares in a classic car, a liquid security trading on an open market: all four raise capital, govern a treasury and let holders leave with a share, and all four leave the asset itself off the ledger. A member exiting a property caper redeems a portion of the treasury, not a portion of the building. Whether the building is really behind the token is a question for a contract written on paper and enforced in a court.

Which gives a second test inside the first, and it separates these four cleanly. Ask whether the asset is a cash flow or an object. Rent and an athlete's earnings arrive as money, and money can be deposited into a treasury that every holder already has a claim on; the on-ledger half of the arrangement does real work every month. A classic car appreciates in a garage and pays nothing at all until somebody sells it, so the caper around it is a shell waiting on a sale it has no power to compel. The security line has its own snag: a caper's token is an ordinary transferable resource, and there is no way to restrict who may hold one. It will trade anywhere. It will also trade to anyone, which is the opposite of what a regulated instrument requires.

## Seven that were already the point

What is left is the part of the list that never needed the data at all. Launch a DAO, run a fundraiser, tokenize yourself, run a bounty programme. These are not adaptations of a caper. They are the ordinary operation of one, and three of them are the reason it exists. A bounty is a proposal with a payment attached, so the treasury moves when the vote passes rather than when someone is asked nicely afterwards – the difference between a decision and a promise, which is [its own subject](/blog/the-binding-vote).

The curation-market line is the oldest idea on the list, older than Zap, and the closest to a description of the machine. Simon de la Rouviere's 2017 proposal was that a curve could reward whoever showed up early to something that later turned out to matter, and so pay people to be right in public before it was obvious. A caper is that with a balance sheet underneath, which changes what backing something means: early conviction is no longer only a bet on the next buyer, because there is a pooled asset behind the claim and [a right to leave with a share of it](/blog/the-exit-right).

Two more repay a closer look. "Release always-liquid tokens that mint and burn autonomously" gets the demand right and the mechanism wrong, which is a common shape for a prospectus. A caper's token is always liquid: there is [a counterparty that cannot walk away](/blog/the-standing-counterparty), so a holder never has to find someone willing to take the other side. But nothing mints and nothing burns. The supply is fixed at the moment the caper opens and no authority to change it is ever created, so what looks like issuance is a token moving between the curve and a holder. The stronger version of the promise turns out to be the one where the machine has less power, not more.

And the last line on the list – "invest in individual oracles that you think will be valuable" – survives if you delete one word. Invest in individual _ventures_ that you think will be valuable, and a caper does it natively: one caper's treasury can hold another caper's token, and holding it is a vote inside the thing it holds. Ownership and governance are the same act, so a portfolio and an org chart become the same document. This is the one line on Zap's list that reads more ambitiously today than it did in 2019, and it is the one nobody at the time was pointing at.

## The test

Seven of twenty-two work now, four work with a legal wrapper and an honest account of where the asset actually lives, and eleven need machinery that is not there and is not coming. That is not a poor showing for a list written about a different protocol in a different decade, and it is not an argument that Zap was wrong. Almost every line on it named a real demand. Fen drainage was a real demand in 1720.

The 1720 act sorted its list by force and by favour, and got the right answer for the wrong reason: what survived was the venture whose business was pooled capital, run by an instrument for pooling capital. The rest had borrowed the form. Twenty-two ventures later, the same question does the same work. Not what a thing is worth, or who wants it, but whether the machine underneath is doing something the venture could not do without it.

## The Exit Right

URL: https://caper.network/blog/the-exit-right
Updated: 2026-07-07

Every enduring institution has had to answer the same question: what does a member get to keep when they leave? The answer is rarely incidental. It shapes who joins, how power is exercised while they stay, and whether the institution can be trusted with anything worth guarding.

Consider the range of historical answers. A medieval guild admitted a member for life and offered almost nothing on departure; leaving meant forfeiting the trade itself, which is precisely why guilds could enforce their standards. A worker cooperative, in the tradition Elinor Ostrom spent her career documenting, ties membership to labor and returns a member's patronage stake when they go — the exit is real, but it is a settlement of accounts, not a claim on the whole. The joint-stock company drew the sharpest line of all: a shareholder may sell at any moment, to anyone, at whatever price the market will bear, and the firm neither notices nor consents. Liquidity replaced permission. That single move — making the share severable — is most of what made the modern corporation financeable.

Each of these designs pairs an exit rule with a governance rule, and the pairing is never accidental. Where you cannot leave with anything, voice tends to be loud and votes tend to be cheap, because dissatisfaction has nowhere else to go. Where you can leave with everything, voice is often thin, because the disciplined threat of departure does the work that argument would otherwise have to. Albert Hirschman named these the two responses available to any member of any organization — voice and exit — and observed that the health of an institution depends on the balance between them. Most organizations get to choose that balance. What they cannot usually do is make the two quantities _the same_.

This is the design question worth dwelling on, because digital organizations have mostly answered it badly. The first wave of on-chain organizations imported one-token-one-vote from nowhere in particular and discovered its failure mode within a season: a member's voting power and their financial claim came apart. You could accumulate votes without committing capital that anyone else could redeem, and you could hold a redeemable claim while never showing up to govern. Power and stake, decoupled, produce exactly the pathologies you would predict — governance capture by the well-capitalized, apathy from everyone else, and treasuries that belong to the organization in name but to no member in any way they can act on.

A cleaner answer is to refuse the decoupling outright: make the share a member can leave with _equal to_ the weight their vote carries. Not correlated, not roughly proportional — identical. Under such a rule you cannot vote with more force than you could walk out the door with, and you cannot hold a larger claim on the treasury than your voice reflects. Voice and exit stop being two levers to be balanced and become one quantity seen from two sides.

Caper is built on that identity. A member's share of the common treasury, at the moment they choose to leave, is the same figure that determines how much their vote counts while they stay. The weight is a function of what they actually hold and the participation stake they have committed, measured against the whole; the treasury share on exit is that same weight, applied to the same treasury. When a member exits, they take that fraction of the common funds and their claim is retired — the exit is genuine severance, in the joint-stock sense, not a promise to be settled later. What is new is not the liquidity; markets have offered that for centuries. What is new is that the liquid, severable claim and the governance weight are guaranteed by construction to be the same number.

The consequences run in both directions, and both are the point. A large holder cannot out-vote a small one beyond the share they could actually redeem, which caps the return on governance capture at the return on simply cashing out — and a holder who would rather cash out than steer is welcome to. A disengaged member is not trapped subsidizing a treasury they have no voice over; the door is open, and it is open at their real weight, not at some haircut the majority sets on the way out. The exit right, priced honestly, disciplines the people who stay. It is the credible threat that makes voice worth listening to, because everyone in the room knows exactly what walking away is worth.

There is a further reason this matters now, beyond the governance of organizations that already exist. If the severable share and the vote can be made one number for a group, they can be made one number for a person. An individual who incorporates themselves — issuing a claim on their own future, backed by a treasury, governed by the people who chose to back them — needs precisely this guarantee to be trustworthy. The personal-token experiments of the last decade failed for want of it: they offered a claim with no governance and no honest exit, and when trust wavered there was nothing underneath. A treasury and a real exit right are what make self-incorporation credible rather than speculative. The exit right is not only how a member leaves an organization well. It is the condition under which a person can become one.

## The Founder's Cut

URL: https://caper.network/blog/the-founders-cut
Updated: 2026-07-28

For most of history, whoever struck the coins took a cut. The word for it is seigniorage, from _seigneur_, the lord: the gap between what a coin is worth and what it costs to make, kept by the authority that makes it. A lord who ran a mint earned on every coin struck – a fee for turning raw silver into money the realm could actually use. Honest enough, in principle. Minting is a service, and the minter is paid for performing it.

The abuse that shadows seigniorage is debasement. A ruler short of money could mix cheap metal into the coin, strike the same face value out of less silver, and pocket the shortfall. Henry VIII debased the English coinage so thoroughly that he earned the name "Old Coppernose," the silver wearing off the high point of his portrait to show the base metal beneath. Debasement is seigniorage's evil twin. Instead of charging a visible fee to the person buying new money, the minter takes a little from everyone already holding it. The first is a price. The second is a theft wearing the costume of a price.

Every enterprise that issues a claim on itself faces a version of this choice, because someone has to be paid for building the thing. A startup pays its founders in shares; a token project pays them in tokens. And the standard method has always been the one closest to debasement: mint the founder a large allocation up front, out of the very supply everyone else will later buy. Whatever the vesting schedule wrapped around it, the structure is a pile of the enterprise's own money, created for the person at its centre, hanging over the market and waiting to be sold. When it is sold – and it is almost always sold – everyone who bought in earlier is diluted by it. The crypto era gave the pattern its own vocabulary: the premine, the founder dump, the "team unlock" that markets learn to dread on a calendar.

The failure here is not that founders get paid. Founders should get paid; the person who takes the risk of starting a thing is precisely who a healthy system rewards, and rewards well. The failure is the _form_ of the payment – a stock of tokens, minted for an insider at a price no outsider ever paid, that can be turned into money only by selling it back into the same people the founder is supposed to be building for. It welds the founder's reward to an act that harms his own backers. That is debasement with extra steps.

A caper pays its founder the other way: as seigniorage, in the open, and never as a stock minted before anyone showed up. When someone buys into a caper, they pay a little above the curve's bare price, and that premium is the founder's cut. It is paid in the same proportions the caper itself is made of. Two thirds of what a young caper is worth is XRD sitting in its vault; the remaining third is a claim on buyers who have not arrived yet. So two thirds of the cut is skimmed in the base money the buyer brought and dropped into a vault only the founder can open, and one third is a slice of the very tokens that buy just minted. Nobody picked that ratio. It is read off the curve, which has a fixed answer for how much of itself is real reserve and how much is claim.

The token slice is the part that deserves scrutiny, because at a glance it is the thing this essay just condemned. It is not, and the difference is stock against flow. A premine exists on day one: backed by nothing, priced at nothing, held by someone who paid nothing. The founder's slice does not exist until a buyer arrives. It is brought into being by that purchase, collateralised by the XRD just paid for it, at the price just paid for it – a price an outsider set, in the same transaction, seconds earlier. On a caper that never attracts a buyer the founder's slice is not locked or vesting or waiting on a cliff. It was never made. There is no overhang because there is no stock, only a fraction of what backers themselves chose to mint.

Nor can it accumulate into one. The slice is a fixed fraction of every mint, so the founder's share of the coin is simply the average of that fraction over the stretch of curve the caper has travelled – and an average of something capped at five percent is capped at five percent. No vesting schedule enforces that, no cliff, no lockup, no clause anyone could waive. It is arithmetic, and it holds on every path. In practice the share sits just under five percent at the first buy and falls from there: near four percent once a tenth of the supply is out, under one percent by the time the curve is nearly full. The founder is diluted by their own success, which is the right direction for that number to travel. One thing worth stating plainly, since the arithmetic does not cover it: this bounds what the skim can hand a founder, not what a founder may own. They can buy on the curve like anyone else, at the same price as anyone else.

Two design choices make this honest rather than merely rebranded. First, the cut comes out of the buyer's own premium, not out of what existing holders own – a fee on new money, in the exact seigniorage sense, rather than a debasement of old money. A sliver of it is routed to a shared pool, the Commons, that every caper on the platform feeds, so each new venture launched thickens the common treasury standing behind all of them. Second, and less obvious, the cut is front-loaded in rate but self-terminating: the founder's share of each buy is heaviest at the very first purchase and thins steadily as the token distributes, until it reaches zero and stays there. Past that point the curve is the buyer's only counterparty, and neither founder nor protocol takes anything further. The reward is concentrated where the risk is – the cold open, when a founder is asking strangers to back something with no history – and it switches off once the thing is established, instead of curdling into a permanent tax on a mature token.

There is a subtlety in this that cuts against the usual launch-day greed. The _rate_ is heaviest at the start, but the founder's actual _take_ is not, because at the start the price is near nothing, and a large share of nearly nothing is nearly nothing. The real money arrives only as real backers do: the cut swells with genuine demand and then fades as the rate winds down. A founder cannot get rich by sniping his own launch, because at launch there is nothing there to snipe. He is paid in proportion to the interest he actually attracts – which is the only thing you would ever want a founder paid for. His incentive is fused to the single activity that also serves his backers: bringing real demand to the thing they hold.

This is an old problem in a new mint. Any enterprise built around a person has to answer how that person eats without letting them loot the enterprise to do it. Salaried from the treasury, they drain the common pool. Paid in a founder's stack, they carry an overhang that punishes the faithful. The caper keeps the mint's honest half and discards its dishonest one – a visible fee on the making of new money, charged to the party who chose to make it and taken out of what they just brought – and then does something no historical mint ever did: it turns the fee off once the coin is in wide circulation and the risky work is behind it.

Seigniorage built palaces, and when it curdled into debasement it toppled the currencies that paid for them; the line between the two was always whether the one minting the money was charging a fair price or picking a pocket. For most of financial history that line was a matter of the minter's character, policed weakly if at all. A caper draws it in the contract instead. The founder is paid, well and early, out of what newcomers freely offer and never out of what holders already own – and when the enterprise no longer needs bootstrapping, the cut simply ends. The person at the centre is compensated for the risk they took by the very mechanism that once let sovereigns rob their subjects, running honestly for the first time.

## The Open-End Organization

URL: https://caper.network/blog/the-open-end-organization
Updated: 2026-07-28

For as long as enterprises have raised money from strangers, the raise has been an event with a beginning and an end. A company opens a round, sets a price, courts investors, and closes it; the books shut, the money is in, and the window stays down until the next round, on new terms, at a new price, after another season of courtship. The initial public offering is the grand version of the same shape – a single day, years in the making, when a company sells a fixed tranche of itself and then never sells at that counter again. Fundraising has been, almost by definition, periodic. You are either raising or you are not.

The cost of that periodicity hides inside its rhythm. Between rounds an enterprise cannot take capital from someone who wants to give it; the window is simply shut. To open one it must submit to the machinery that surrounds every round – the gatekeepers who decide whether a round may happen at all, the underwriters and lawyers, the roadshow, the price negotiated behind a door outsiders never enter and never help set. And each new round reprices and dilutes the last, which makes opening one a political act inside the company as much as a financial one. The episodic raise is not a law of nature. It is an artifact of the plumbing.

Finance has, in one corner, already built the alternative, and it did so a century ago. In 1924 the Massachusetts Investors Trust did something genuinely new: rather than sell a fixed number of shares once and then close, it agreed to issue new shares to anyone who wanted in and to buy them back from anyone who wanted out, continuously, at a price equal to the value of what the fund actually held. This is the open-end fund, the structure beneath most mutual funds today. Its opposite, the closed-end fund, keeps the older shape – a fixed number of shares, sold once, thereafter traded among strangers on an exchange.

The gap between the two is a precise measure of what periodicity costs. A closed-end fund, its share count frozen, routinely trades at a price unmoored from the value of its holdings – usually below it, sometimes above, because nothing forces the two together, and a holder who wants out must find a buyer and take whatever discount the mood of the day imposes. An open-end fund has no such gap, because its door stands open in both directions: you can always put money in at the value of the assets and always take it out at the value of the assets, so the price cannot wander from what the thing is actually worth. The open door is the mechanism that keeps the price honest.

A caper is an open-end organization. When one launches, it does not open a round; it opens a window that never closes. From the first second, anyone, anywhere, can put capital in, and the enterprise takes it – not as a negotiated tranche with a closing date, but one buy at a time, for as long as the caper exists. There is no next round to wait for, because the round never ends. There is no gatekeeper deciding whether the window may open, no underwriter, no roadshow, no price struck in a room the newcomer will never see. The price is set by a rule anyone can read, and the same rule serves the founder raising and the backer buying.

This is the idea Thibauld Favre named in 2018 when he described the continuous organization: an enterprise that raises not in rounds but continuously, its token living permanently on a curve instead of being sold once and abandoned to a secondary market. He was reaching, in on-chain form, for exactly what the Massachusetts Investors Trust reached for in 1924 – a claim you could always acquire and always redeem at a price tied to what stood behind it, so that funding became a standing condition of the enterprise rather than a recurring emergency. A caper is that idea made ordinary. Every caper is a continuous organization by construction, with no version that closes its raise.

Building the raise this way dissolves the frictions that made the episodic round such a fraught thing. New capital does not dilute the people already in, because it does not arrive at a discounted price struck in private; it arrives up the curve, at the going rate, the way new money into an open-end fund comes in at the fund's current value and not at a sweetheart number. There is no repricing negotiation, because the price was never negotiated. There is no closing to sprint toward and no dead stretch between raises when the enterprise starves because the window happens to be shut. Capital formation stops being a series of punctuated crises and becomes a continuous background condition, available the moment anyone decides the thing is worth backing.

The people this changes most are the ones the episodic round was hardest on. A round is expensive to open, so only enterprises already large enough, connected enough, or fashionable enough to justify the machinery ever get to open one; everyone else waits to be chosen. An open-end organization removes the choosing. The window is open by default to a project with no round it could plausibly have raised and no gatekeeper who would have taken the meeting. The barrier was never that the capital did not exist. It was that reaching it required someone's permission. A caper opens the channel with a single transaction and leaves it open.

The open-end fund rewired a century of investing by changing one thing in the plumbing: it kept the door open in both directions. Most people who own a mutual fund have no idea they are leaning on a structural choice made in Boston in 1924, because the choice worked so completely it went invisible. A caper makes the same change to the enterprise itself. The raise is not an event a company survives every eighteen months; it is a condition it lives in – open to anyone, at a price no one sets by hand, for as long as the thing is worth backing. The question stops being when the next round opens. There is no next round. There is only the open door.

## The Personal Caper

URL: https://caper.network/blog/the-personal-caper
Updated: 2026-07-11

In 1997 David Bowie did something no musician had done before: he sold his future. The banker David Pullman packaged the royalties from twenty-five albums Bowie had recorded before 1990 – 287 songs – into a bond, and Prudential bought the whole issue for fifty-five million dollars. The coupon was 7.9 percent, the average life about ten years, and the structure was clean enough that the tax authorities treated the proceeds as a loan rather than income. For a decade, a stream of income that used to belong to one man belonged, in effect, to his backers. Then it reverted to him.

Bowie Bonds are usually filed under financial trivia. They are better read as a prototype. A person, treated as an institution, issued a claim on themselves, sold it to people who believed in the future value of what they made, and used the proceeds to buy back control of their own catalogue. The instrument was crude – a single buyer, a fixed term, no secondary market to speak of, no way for Prudential to change its mind – but the idea underneath it was durable: an individual can be capitalized the way a company is.

The idea kept trying to be born. Income-share agreements let a student sell a slice of future earnings to fund an education. The 2020 "personal token" wave let anyone mint a coin against themselves in an afternoon. On paper the 2020 version was the most complete: a creator issued a token, a community bought it, and the price was supposed to track the creator's rising fortunes. In practice it was the least complete thing anyone had built. The platform that hosted most of these tokens, Roll, held the keys; in early 2021 an attacker emptied its hot wallet of roughly $5.7 million and the personal tokens minted on top of it fell in a heap – some 40 percent, some 96 percent – in a single week. The tokens did not fail because the creators stopped being interesting. They failed because they were claims on nothing a holder actually controlled. There was no treasury the holders owned. There was no way to leave with your share, because there was no share. When trust in the creator or the custodian wavered, the only available action was to sell into a falling market. The instrument gave you upside and a sell button, and nothing in between.

The closest miss came on Zap, a protocol built entirely around bonding curves. There, in 2020, a man named Ben Gravis became one of the first people to tokenize himself: he issued a personal token on a curve and invited backers to bond to it. On its face this was a better instrument than the Roll tokens. A bonding curve is a standing counterparty – a holder who wanted out could sell back to the curve instead of hunting for a bid, so the liquidity the others lacked was built in. What the curve could not supply was a treasury the backers owned or an exit that bound the issuer to anything. The pool was the issuer's own arrangement, maintained at his discretion; when Gravis drifted from the token and let it go inactive, the people holding it were left with a pricing formula whose subject had disowned it. Zap had added the very thing the other 2020 tokens lacked – real liquidity, a curve you could always sell back into – and it was still not enough.

What was missing was the thing that makes a company more than a fan club: a balance sheet the owners have a real claim on, and a rule for getting your claim back.

A caper supplies both. Strip away the setting and the mechanism is simple. A person opens a caper the way a company opens a cap table. Backers buy the caper's token along a bonding curve, and the money they put in does not vanish into a price – it fills a treasury. That treasury is not the founder's private account. It is the collateral behind the token, and every holder has a claim on it that the contract enforces directly. The founder earns an allocation as buys come in, so the person being backed is compensated for the thing being backed; but the pool the backers funded stays pooled, and stays theirs in proportion.

The rule for getting your claim back is the part the 2020 tokens never had. On a caper, any holder can exit. Exit is not a sell order routed into whoever happens to be bidding; it is a right against the treasury itself. When you leave, you burn your vote and redeem a proportional share of what the treasury holds – the same proportion, exactly, that would have determined your weight in a vote. Your say in the thing and your severable stake in the thing are computed from _one number_. A backer of a personal caper is therefore never in the 2020 position of holding a claim on nothing. At any moment they can name their portion of the collateral and walk out with it.

This is what turns a personal token from a bet on someone's mood into something closer to a small institution. Albert Hirschman's old distinction is the right lens: a member of any organization has two levers, voice and exit, and the credibility of voice depends on the reality of exit. A shareholder's opinion matters partly because they can sell to someone who sets a floor under the price; a citizen's complaint carries weight partly because they can, in principle, leave. The 2020 personal tokens gave their holders voice with no floor and an exit that led only to the open market. A caper gives exit a floor made of the treasury the holders themselves funded, and ties the size of that exit to the same measure as the vote. Elinor Ostrom spent a career documenting the rules that let ordinary groups govern shared resources without a boss or a sale to outsiders; the common thread was always that members had a defined, defendable stake and a clear path out. A personal caper is that pattern applied to the smallest possible commons – one person and the people who back them.

Consider the worked case. A researcher who wants to work independently opens a caper. Backers who want her output to exist buy in; the treasury fills. She draws her founder allocation to live on, and she runs the treasury through the same proposal machinery any caper uses – a grant here, a commissioned piece there, each one a motion her backers can vote on with the weight their holdings earn them. If she loses their confidence, they are not trapped the way Roll's holders were. They exit, each with their share of what is left, and the price discovery happens against real collateral rather than a thin order book. She has, in the most literal sense available, incorporated herself: a token, a treasury, a set of backers with governance rights, and a door they can always use.

Bowie could do this once, with an investment bank, for a catalogue worth fifty-five million dollars. The 2020 wave tried to do it for everyone and left out the two things that made Bowie's version real – a defined asset behind the claim, and a clean way for the claim to be settled. The personal caper is the first version where both are present and neither requires a bank. The interesting question is no longer whether an individual _can_ be capitalized. Bowie settled that in 1997. The question is what happens to a world in which the answer is available to anyone, the collateral is real, and leaving is always allowed.

## The Standing Counterparty

URL: https://caper.network/blog/the-standing-counterparty
Updated: 2026-07-18

The first modern stock market opened in Amsterdam in 1602, when the Dutch East India Company issued shares a holder could sell on to someone else. For the first time you could own a piece of an enterprise in the morning and be rid of it by the afternoon. That convenience carried a dependency inside it that has never gone away, and that every market since has had to manage: to sell, you need someone willing to buy. Liquidity is not a property of the thing you hold. It is a property of whoever is standing across from you when you decide to leave.

For four centuries the party standing across from you was a person. The Amsterdam bourse had its jobbers, the London exchange its stockjobbers, and the New York Stock Exchange its specialists – a dealer assigned to each listed stock and obligated, in the exchange's own words, to maintain a "fair and orderly market." The specialist quoted a price to buy and a price to sell from his own account and stepped in to absorb the difference when buyers briefly outnumbered sellers or the reverse. He was the market's standing counterparty: the party who was always supposed to be there, so that an ordinary holder never had to go hunting for a bid.

The flaw in a counterparty made of people is that people have discretion, and discretion sprints for the door at exactly the moment everyone else does. The specialist could widen his spread until selling cost more than it returned. In a real panic he could step back from his post altogether, and more than once, on the days he was needed most, he did. A market maker's promise is only ever as good as his nerve and his balance sheet, and both are thinnest in a crash. A market that depends on someone's willingness to buy is a market that can be switched off by that someone's fear – and fear is contagious precisely when liquidity is scarce.

The personal tokens of the last decade rediscovered this the hard way, without even a specialist to lose. A creator issued a coin; the only exit was to sell into whoever happened to be bidding; and when confidence wavered, the bidders were the first thing to vanish. The instrument handed its holders a sell button with nothing reliably attached to the other side of it. What those holders lacked was never another token. It was a counterparty who would still be at his post in the bad hour.

The answer, when it finally arrived, was to stop asking a person to be the counterparty and to make the counterparty a rule. Bancor's smart tokens, in 2017, priced a token against a reserve the contract held itself, so the token could always be converted back into that reserve at a price a formula fixed in advance – a market maker with no trader behind it to lose heart. A year later Thibauld Favre described the continuous organization: an enterprise whose token lived permanently on such a curve, raising funds continuously and guaranteeing an exit, instead of selling one fixed batch and leaving its holders to conjure a market afterward. The party across from you was no longer a firm that could lose its nerve. It was arithmetic.

A caper is built on that arithmetic. When a caper opens, its market opens with it – not as a promise to list somewhere later, but as a working counterparty present from the first second. The price is set by how much of the supply has sold, rather than by pairing a buyer to a seller, so there is always a price to buy at and a price to sell at, and neither waits on anyone else showing up. Money paid in fills a reserve; the tokens come out of the curve's own inventory; selling hands them back and draws the reserve down again. There is no order book to thin out, no specialist to widen the spread, no operator holding a key that could close the window or empty the pool. The counterparty is the contract, and the contract has no nerve to lose.

Two things fall out of building the counterparty this way, and both are the reason to bother. The reserve is not a headline figure – it is real collateral, held by the curve, and any holder can reclaim their share of it by selling back or by walking out the exit. And because the price starts at nothing when nothing has sold and can only rise as the supply distributes, there is no cheap floor for an insider to accumulate on before the public arrives; the earliest backer takes the most risk and is paid for it, the latest takes the least. The order in which people show up is priced by one rule that treats all of them alike.

This is what "always tradeable" has to mean if it is to mean anything at all. Markets have promised liquidity since the Amsterdam bourse; what none of them could promise was that the liquidity would be there in the single moment you actually needed it, because it rested on somebody else's willingness to trade with you. The curve takes the willingness out of the equation. It is a market maker that cannot widen its spread out of fear, cannot go insolvent, cannot be talked into closing the window, and cannot be drained by the person who runs it – because no person runs it.

For four hundred years, a standing counterparty was a privilege you had to qualify for. You got one by listing on an exchange that would assign you a specialist, which meant being large enough, and vetted enough, to be worth the assignment. A caper gives the same thing to anyone who can sign a single transaction: a market that comes into being together with the thing it prices, keeps a real reserve behind every unit, and cannot be turned off. The old question was whether someone would take the other side when you wanted out. It stops being a question. Someone always will, because the other side is no longer a someone.

## Council dissolution and governance unwinding

URL: https://caper.network/wiki/dao-governance/concepts/analysis/council-dissolution
Updated: 2026-08-11

| Topic | How a DAO shuts down its own elected bodies, and where the mandate goes afterwards |
| --- | --- |
| Proposal type | Optimism names it outright: _Council Dissolution_, permissionless to propose, 51% approval ([Operating Manual v2.0.0](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)) |
| The default | Continuation. A persistent council rolls into the next season _unless_ a dissolution proposal passes, so winding one down is an affirmative act |
| Live cases (2026) | Optimism dissolved its [Grants Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-grants-council/10732), [Milestones and Metrics Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-milestones-and-metrics-council/10733) and [Developer Advisory Board](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-developer-advisory-board/10734) in one voting cycle; ENS proposed moving operations to an [operating foundation](https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329) |
| Stated reason | Governance overhead without proportional benefit. The counter-argument is that overhead is what accountability costs |
| Related | [SubDAOs & working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups), [Governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs), [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers), [Security councils](/wiki/dao-governance/concepts/fundamentals/security-councils) |

## Dissolution is a proposal type, not an event

Most writing about [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) covers how bodies are created: a charter is drafted, seats are elected, a budget is approved – though [the first budget of all](/wiki/dao-governance/concepts/treasury/bootstrap-budgets-and-ratification-votes) is usually set before anyone is able to vote on it. Far less covers how they end. Yet a mature DAO constitution usually names the ending explicitly. Optimism's [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) carries a proposal type called **Council Dissolution**, described as applying when a council “is no longer fulfilling its Charter”: permissionless to propose, active approval, 51% threshold, no veto, a two-week review period and a one-week vote.

Two structural facts follow from that entry, and they shape everything else on this page.

**Continuation is the default.** The dissolution proposals themselves state the rule: “a persistent Council is expected to continue into the next Season unless a Dissolution proposal is approved.” Nothing expires on its own. A body that has outlived its purpose keeps drawing its budget until somebody spends governance capital to close it, which is why dormant [working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups) accumulate in DAOs that never write the closing clause.

**Dissolution is cheaper than removal.** In the same table, dissolving an elected council needs 51%. Removing a director of the Optimism Foundation needs 76%. The community body is the easier thing to take apart, by constitutional design, and that asymmetry is not hidden anywhere: it is two rows of the same published table.

## The 2026 Optimism unwind

On 25 June 2026 the Optimism Foundation posted three dissolution proposals in a single voting cycle, targeting the [Grants Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-grants-council/10732), the [Milestones and Metrics Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-milestones-and-metrics-council/10733) and the [Developer Advisory Board](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-developer-advisory-board/10734). All three share an identical opening and an identical diagnosis: after multiple seasons, “the current structure creates coordination friction without proportional benefit to grantees or the broader ecosystem.”

The Grants Council proposal is the one that states the general principle. It lists the overhead by name – “running elections, onboarding members, operating budgets” – and then draws a line that other DAOs can borrow directly:

> “We believe those costs only make sense when there is a strong reason that a function being fulfilled by an independent group of people meaningfully increases decentralization where it matters most (ie. the Security Council.)”

That is a usable test. An elected body is worth its overhead when independence from the core team is the point of the body, and not when the body merely distributes work the core team could do faster. The same proposal discloses that Retro Funding, the Foundation's own programme, was paused on the same cost/benefit reasoning – so the retrenchment is not only aimed at community structures.

The other two proposals show the two ways a body dies. The Milestones and Metrics Council died by **dependency**: it existed to verify milestones on grants made by the Grants Council, so “without any community-led grant programs, the Charter of the Milestone and Metrics Council no longer serves any purpose.” Kill the upstream body and the downstream one has nothing to do. Delegates noticed the gap this leaves and asked, in the Grants Council thread, who would handle pending milestone verification after dissolution; the answer given was that the second dissolution was a separate proposal in the same cycle, which does not answer the question.

The Developer Advisory Board died by **obsolescence argument**, and its proposal contains the most striking sentence of the three. One of the Board's charter purposes was to help non-technical delegates understand protocol upgrades. The Foundation's case for closing it: “With rapid advances in artificial intelligence, we believe non-technical delegates are now sufficiently empowered to understand the implications of technical proposals without a dedicated Board required to fulfill this role.” Whatever one makes of it, it is a dated, checkable claim about what a DAO now expects its delegates to do unaided, and it belongs in any honest record of how governance structures were justified away in 2026.

## Read the constitution's diff, not the proposal

The proposals describe three closures. The document underneath them describes something larger. On the same day the proposals were posted, the Operating Manual was rewritten as [v2.0.0](https://github.com/ethereum-optimism/OPerating-manual/commit/da1fba97fedbde6e781e7f1dc4957c202562cbb5), a commit of 32 additions and 96 deletions, merged three weeks later. Reading that diff is the fastest way to see what a governance unwind actually removes, because the deletions are the parts nobody wrote a proposal about.

The v1.0.1 manual opened: “The Optimism Collective is governed by two houses, the Token House and the Citizens' House.” The v2.0.0 manual opens: “The Optimism Collective is governed by the Token House.” Everything downstream of that sentence went with it:

- The **Citizens' House** in full – the citizen attestation, the End Users / Apps / Chains stakeholder split, weighted quorum, weighted approval, and every Joint House calculation.
- The **stakeholder veto with dynamic thresholds**, where two groups needed 17% each to veto, three needed 14%, four needed 11%, escalating to 23/20/17% on a re-submission. It is replaced by a flat 20% veto threshold and a single paragraph of appeals process.
- The **[Retro Funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding)** section, including the sentence recording that Retro Funding was “currently paused through the end of 2026.”
- Two whole proposal types: **Token Allocations** (the type the Budget Board proposed under) and **Reflection Period**.
- The **Developer Advisory Board's role in protocol upgrades**. Under v1.0.1 an upgrade needed active approval from the Board plus a stakeholder veto window. Under v2.0.0 the Protocol and Governor Upgrades row has no approving party at all: voting type _N/A_, approval _Veto_, one week.
- The sentence “Over time, key parameters of the Operating Manual will be maintained by the community (metagovernance.)”

Two renames in that diff are worth more than they look. The proposal type once called **Persistent Structure Dissolution** is now called **Council Dissolution**: a general power to wind down any persistent structure, narrowed in name to councils. And under v1.0.1 that power could be routed to either house or to a joint vote, at 51% single-house or 60% joint. With one chamber gone, only the 51% single-house path remains. Separately, on 8 June, the Anticapture Commission's charter had already been [deleted from the repository](https://github.com/ethereum-optimism/OPerating-manual/commit/6524c37ebfb40e51d264ddc29fdba9f0745bb27d) with the commit message “No longer needed”, with no dissolution proposal attached to it at all.

The manual's own change process is the reason all of this can travel in a commit: releases “go into effect as releases are published on GitHub”, and “only the removal of a proposal type requires a governance vote.” Anyone auditing a DAO's structures should therefore diff the constitution on every release rather than track the proposals, and Optimism deserves credit for keeping the constitution in public version control where the diff can be read at all. Most DAOs keep theirs in a document that silently overwrites itself.

## The arithmetic of an abstention

The dissolutions were not uncontested, and the shape of the opposition is instructive. L2BEAT's governance team published its reasoning in the Grants Council thread on 15 July: it voted **abstain**. The rationale is worth quoting because it names the structural trap precisely:

> “A community led council cannot function without the backing and funding of the Foundation, and forcing its continuation under these circumstances would only lead to friction.”

An elected body funded by the entity proposing its dissolution has no real veto. Voting the proposal down keeps the body alive on paper while the counterparty that pays for it has publicly said it does not want it. That is the general lesson: **a council's independence is bounded by who controls its budget line**, which is the same dependency that shapes [service provider renewals](/wiki/dao-governance/concepts/analysis/dao-service-providers) and [delegate incentive programmes](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs).

The abstention also has mechanical consequences that the manual spells out and that are easy to get backwards. Optimism requires 30% quorum, measured against _active_ votable supply, and the manual states plainly that quorum “includes abstain votes.” The approval threshold is computed differently: it is the share of yes votes “relative to the total number of yes/no votes cast”, and it “does not include abstain votes.” So an abstention helps a proposal clear the participation bar it must clear, and is absent from the ratio it must win. Under this rule set, abstaining is not a neutral act with respect to a proposal's passage – it is a contribution to quorum with the opposition removed. Anyone designing a ballot should decide deliberately whether that is what they want abstention to mean; see [quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) for the wider family of choices.

## Overhead was the argument. The surviving body is the expensive one

The dissolutions were argued on cost of overhead. It is worth checking the overhead against the DAO's own budget lines, because the figures point the other way.

As budgeted for Season 7 and reported by SEEDGov, the Collective's governance operating cost was [1,055,000 OP](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297), split across four bodies: Grants Council 400,000, Milestones and Metrics 170,000, Developer Advisory Board 190,000, and the Security Council 295,000. The three bodies dissolved in 2026 are the first three, and together they were 760,000 OP, the cheaper 72% of that structure. The one carved out as worth its overhead is the fourth.

What that carve-out now costs is a separate proposal. The [Security Council operating budget for Seasons 10 and 11](https://gov.optimism.io/t/optimism-security-council-operating-budget-for-seasons-10-and-11/10749) requests **5,040,000 OP**, covering twelve months from 1 July 2026, for 14 members (13 signers and a lead) at 30,000 OP per member per month. The periods are not directly comparable – one season against twelve months – so this is not a like-for-like multiple, and the token's price moved a long way over the interval. The per-member rate is the cleaner number, and a delegate raised exactly that point in the thread: paying a body in a depreciating governance token makes the token line escalate even when the real compensation does not, which is an argument for denominating in stablecoins rather than for shrinking the council.

None of this makes the dissolutions wrong. It does mean that “reducing governance overhead” is a description of a structural preference, not of a saving: what was removed was the community-elected layer, and what grew was the signer set that executes upgrades. A DAO that wants the cost argument to carry weight should publish the before-and-after in one table, in one currency, over one period. Almost none do, for the reasons set out in [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs).

## Where the mandate goes: the operating foundation

Dissolution answers what closes, not who does the work afterwards. In 2026 the common destination is a foundation with staff, and ENS is running the clearest public version of that argument.

A [temp check posted on 19 June 2026](https://discuss.ens.domains/t/temp-check-next-era-of-ens-dao-empowering-the-ens-foundation/22175) proposed establishing the ENS Foundation as an operating foundation with a full-time Executive Director, staff, and a five-seat board ratified by the DAO. Its diagnosis is the sharpest statement of the case for retrenchment anywhere in the 2026 record: the dysfunction comes from “the gap between what the DAO was meant to do (steward credibly neutral infrastructure) and what it actually does day to day (act as a budget committee for an organization).” Token votes are “slow, they carry little context, and they force a yes or no choice”, while running an organisation “needs repeated adjustment, judgment, and a specific person who can be held accountable.”

The [executable proposal that followed on 30 July](https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329) shows what community pressure moved and what it did not. Three scope reductions are itemised in its own abstract: DAO-held ENS tokens stay under tokenholder control, with a single carve-out of 1,000,000 ENS restricted to Foundation employee compensation; the operational wallet (`wallet.ensdao.eth`, roughly $16M in ETH and stablecoins as of July 2026) stays with the DAO rather than being delegated; and the Endowment Safe (`endowment.ensdao.eth`, roughly $65M) passes to Foundation Board control but with every transaction routed through a timelock that the [Security Council](/wiki/dao-governance/concepts/fundamentals/security-councils) can cancel. Tokenholders keep protocol control and the power to appoint and remove directors.

The objections in that thread are as much a part of the record as the proposal. Delegates argued that board composition and accountability structures were not addressed; that ENS Labs is simultaneously the DAO's largest funding recipient and the holder of enough ENS to represent a majority of active voting power; and that a foundation staffed and funded this way is accountable to the entity that populates it rather than to tokenholders. A competing [temp check](https://discuss.ens.domains/t/temp-check-empowering-an-independent-ens-foundation-for-accountability/22203) argued for an _independent_ foundation on accountability grounds, which is a reminder that the choice is rarely DAO-versus-foundation but which foundation, appointed how. The DAO had already priced the interim: pausing its working groups for a four-month retrospective needed a [$234,000 continuity budget](https://discuss.ens.domains/t/temp-check-metagov-update-working-group-operations-during-the-ens-retro/21781), 83% of it compensation for the roster.

The pattern across both DAOs is the same three-step: elected bodies are closed on overhead grounds, execution consolidates into a foundation or core team, and tokenholders retain protocol-level control plus the power to remove directors. Whether that is maturation or capture depends entirely on whether the retained powers are usable in practice – which is a question about thresholds, quorum and the distribution of voting power, not about intentions. Compare [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization), which describes the same institutional arc pointed the other way, and [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization), which removes discretion from the protocol rather than relocating it into a company.

## A checklist for a live dissolution

If a dissolution proposal appears in a DAO you participate in, these are the questions the published documents can answer:

- **Who proposes, and who funds?** If the proposer also controls the body's budget line, the vote is a formality and should be read as one.
- **Is the mandate transferred or extinguished?** A closure that names the successor is an org change. A closure that names nobody is a capability being dropped, and the work it was doing (milestone verification, technical review of upgrades) becomes an unowned gap.
- **What happens to unspent budget and to signing keys?** Multisig membership, streams, and any permissions the body held outlive the charter unless the proposal revokes them explicitly.
- **What obligations are mid-flight?** Grants pending verification, appeals in progress, elections already scheduled.
- **Does the constitution change in the same window?** Diff it. The proposals are the visible part; the manual revision is where a chamber, a veto class or a threshold quietly leaves.
- **What does the threshold table say about the reverse move?** If closing a community body is 51% and removing a director is 76%, the structure has a direction of travel independent of anyone's intent.
- **Is there an exit for members who disagree?** In most token DAOs, no – only selling. Where a [rage-quit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) exists, a restructuring vote is precisely the moment it is for.

## How Caper approaches this

Caper has nothing of this shape to dissolve, which is a design choice with its own trade-offs rather than a solution. Searching the contract sources for a delegate, council or committee concept returns nothing: there is no elected body, no seat, no charter and no roster whose overhead has to be justified season by season. The governance surface is a proposal and a ballot, and both are paid for at the point of use – the configured proposal fee and vote fee are asserted in XRD and deposited into the caper's own treasury, so the running cost of governance falls on the participants who use it rather than on a standing budget line.

The consequence that matters here is the remedy available to a member who loses a restructuring argument. Where a token DAO's dissenting delegate can vote no, abstain, or sell, a caper holder can `exit`: an individual action, requiring no vote and no counterparty's approval, that redeems a member's claim on the treasury and burns their position. That claim is the same canonical vote weight the protocol uses everywhere else, and it consumes both buckets – the governance tokens and the soulbound vote tokens earned by participating – so it is not a pro-rata share of the treasury by balance, and a large position alone does not enlarge it.

What Caper does not offer is the thing the councils were for. There is no independent group standing between a proposal and execution, no technical board reviewing upgrades on a non-expert's behalf, and no elected reviewer of grants. A structure with no bodies never faces a dissolution vote, and it also never had the layer whose loss the Optimism delegates were objecting to. See [what a caper is](/wiki/foundations/what-is-a-caper) and [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## References

- [Council Dissolution Proposal: Dissolve the Grants Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-grants-council/10732) – Optimism Collective forum, 25 June 2026, with the L2BEAT abstention rationale of 15 July.
- [Council Dissolution Proposal: Dissolve the Milestones and Metrics Council](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-milestones-and-metrics-council/10733) – Optimism Collective forum, 25 June 2026.
- [Council Dissolution Proposal: Dissolve the Developer Advisory Board](https://gov.optimism.io/t/council-dissolution-proposal-dissolve-the-developer-advisory-board/10734) – Optimism Collective forum, 25 June 2026.
- [Optimism Operating Manual v2.0.0](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) – proposal types, thresholds, quorum definition and change process.
- [Operating Manual v1.0.1 → v2.0.0 diff](https://github.com/ethereum-optimism/OPerating-manual/commit/da1fba97fedbde6e781e7f1dc4957c202562cbb5) – the commit removing the Citizens' House, stakeholder vetoes, Retro Funding and two proposal types.
- [Anticapture Commission charter deletion](https://github.com/ethereum-optimism/OPerating-manual/commit/6524c37ebfb40e51d264ddc29fdba9f0745bb27d) – repository commit, 8 June 2026.
- [Optimism Security Council Operating Budget for Seasons 10 and 11](https://gov.optimism.io/t/optimism-security-council-operating-budget-for-seasons-10-and-11/10749) – 5,040,000 OP for 12 months, 14 members at 30,000 OP per month.
- [Token House participation and incentives: Season 7](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) – SEEDGov, the per-council operating budgets used above.
- [Guide to Season 9](https://gov.optimism.io/t/guide-to-season-9/10529) – “From Experiment to Organization”, the season framing the dissolutions cite.
- [[Temp Check] Next Era of ENS DAO: Empowering the ENS Foundation](https://discuss.ens.domains/t/temp-check-next-era-of-ens-dao-empowering-the-ens-foundation/22175) – ENS forum, 19 June 2026.
- [[Draft][Executable] Next Era of ENS DAO: Empowering the ENS Foundation](https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329) – ENS forum, 30 July 2026, with delegate objections.
- [[Temp Check] Empowering an Independent ENS Foundation for Accountability](https://discuss.ens.domains/t/temp-check-empowering-an-independent-ens-foundation-for-accountability/22203) – the competing proposal, 24 June 2026.

## DAO governance operating costs

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | What it costs a DAO to run its own governance, and why the published figure is rarely comparable to any other |
| **The headline that is not a headline** | [Optimism’s Season 7 report](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) puts Token House operating costs at **1,055k OP**, up 38% on Season 6’s 762k OP. 295k of that is the Security Council budget becoming public for the first time. Net of it: **760k OP**, flat |
| **The ratio that did move** | Governance cost as a share of the season’s Intent budget went from **3.9%** (762k of 19.5M OP) to **8.0%** like-for-like (760k of 9.5M OP), because the programme budget was halved and the process was not |
| **What a structure costs** | ENS working groups were funded at **$959,000 USDC + 15 ETH**; the continuity budget that kept them alive through the 2026 retro was **$234,000** for four months, **83%** of it compensation for nine stewards, a secretary and a scribe ([Metagov temp check](https://discuss.ens.domains/t/temp-check-metagov-update-working-group-operations-during-the-ens-retro/21781)) |
| **What sits outside the number** | Arbitrum pays [Entropy Advisors](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458) a **$3M per year** base fee, and its [OpCo](https://forum.arbitrum.foundation/t/opco-oat-2nd-bi-annual-transparency-report-may-2026/30924) had incurred **$1,148,778 and 100,000 ARB** by 30 April 2026. Neither is a “governance operating cost” line anywhere |
| **Caper’s position** | No council, steward or delegate class exists to fund, and the two governance actions are paid _into_ the treasury as XRD fees rather than out of it (verified in `contracts/logic/src/lib.rs` and `contracts/core/src/caper_dao.rs`) |

Ask a DAO what its governance costs to run and you will get a number. Ask two DAOs and you will get two numbers that cannot be put side by side. This is not sloppiness. The figure a DAO publishes is a function of three choices it made for unrelated reasons: **which legal entity holds the budget line**, **which currency the budget is denominated in**, and **which activities count as governance rather than as the work governance directs**. Change any one of them and the reported cost moves without a single person doing anything differently.

This page is about reading those figures. It works through three DAOs that publish enough detail to be checked: Optimism, whose season reports give a multi-season series; ENS, which paused its entire working-group structure in 2026 and had to price the pause; and Arbitrum, whose largest governance-adjacent costs sit in places no governance budget reports. The neighbouring pages cover the pieces: what DAOs pay delegates is on [delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs), what they pay contributors is on [contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation), and the bodies that spend it are on [subDAOs, working groups and pods](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups). The first budget of all – the one a foundation sets before the DAO is able to vote on it – is on [bootstrap budgets and ratification votes](/wiki/dao-governance/concepts/treasury/bootstrap-budgets-and-ratification-votes).

## The reclassification problem: Optimism’s +38%

SEEDGov’s [Season 7 report](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) for the Optimism Collective states the Token House’s governance operating costs as **1,055k OP**, against **762k OP** in Season 6, and calls it a 38% increase. The four components it lists sum exactly to the total:

|  |  |  |
| --- | --- | --- |
| **Grants Council** | 400k OP | down 34% from Season 6’s 610k OP; the council shrank from 15 reviewers to 7 |
| **Milestones & Metrics Council** | 170k OP | newly independent, previously inside the Grants Council budget |
| **Developer Advisory Board** | 190k OP | up from 90k OP, grown to 9 members |
| **Security Council** | 295k OP | first season its budget was public and Token House approved, having moved from Foundation expenses to the Governance Fund |

The report flags the cause of the jump in its own words: the rise is expected, it says, because the Security Council’s costs became part of the public budget for the first time. What it does not do is the subtraction. Take the 295k OP reclassification out and Season 7 governance cost **760k OP** against Season 6’s **762k OP**. On a like-for-like basis the number did not rise 38%. It did not rise at all.

This is the single most common defect in DAO cost reporting, and it is structural rather than dishonest: the same body was funded in both seasons, but in Season 6 the Foundation paid for it and in Season 7 the DAO did. Optimism’s report is unusually good precisely because it discloses the change. A reader who only saw the headline would conclude the Collective’s governance got 38% more expensive in a season where it also cut the Grants Council by a third.

The sequel matters for how this figure should be read. In June 2026 the Optimism Foundation proposed dissolving the Grants Council, the Milestones and Metrics Council and the Developer Advisory Board – the three bodies that made up the 760k OP – on the grounds of governance overhead, while explicitly carving out the Security Council as worth its cost. The cheaper 72% of the structure was the part that closed. See [council dissolution and governance unwinding](/wiki/dao-governance/concepts/analysis/council-dissolution).

## The ratio moves even when the cost does not

Governance operating cost is close to fixed over a season. The money governance _directs_ is not. Optimism’s Season 7 Token House approved a single Intent budget of **9.5M OP**, down 51% from Season 6’s **19.5M OP**. Setting the two published figures against each other gives an overhead ratio, the share of a season’s approved OP that goes to running the process rather than to what the process funds:

|  |  |  |
| --- | --- | --- |
|  | **Season 6** | **Season 7** |
| Governance operating cost | 762k OP | 1,055k OP (760k like-for-like) |
| Intent budget | 19.5M OP | 9.5M OP |
| Overhead ratio | 3.9% | 11.1% (8.0% like-for-like) |

The ratio roughly doubled on a like-for-like basis, and more than doubled as reported, in a season where governance spending was flat. Every unit of the move came from the denominator. This is worth stating because the two readings support opposite conclusions from the same ledger: _governance got no more expensive_ and _governance now consumes twice the share of the treasury it deploys_ are both true of Optimism’s Season 7, and a DAO arguing either side can cite the report honestly.

The construction here is ours, not the report’s. The report presents operating costs and the Intent budget as separate figures and does not divide one by the other. The comparison is defensible because both are OP outlays approved by the same body for the same season, but a reader should treat the ratio as a derived quantity, and one that a DAO can move by changing the size of its grant programme without touching governance at all.

## ENS: what a structure costs, and what pausing it costs

ENS DAO gives the clearest published answer to “what does the apparatus cost”, because in 2026 it had to price the apparatus twice: once running, once idling.

The working groups were funded in the October 2025 window at **$959,000 USDC and 15 ETH**: Meta-Governance $379,000, Ecosystem $470,000, Public Goods $110,000 plus the ETH. In December 2025 the DAO voted to pause working-group elections so stewards could support an independent retrospective, and the Meta-Governance stewards put a [temp check](https://discuss.ens.domains/t/temp-check-metagov-update-working-group-operations-during-the-ens-retro/21781) to the community asking whether the groups should keep that full allocation or drop to a continuity budget. The continuity option was **$58,500 per month, $234,000 over four months**:

|  |  |  |
| --- | --- | --- |
| **Steward compensation** (9 stewards) | $40,500 / month | $162,000 |
| **Secretary** | $5,500 / month | $22,000 |
| **Scribe** | $2,500 / month | $10,000 |
| **Operational reserve** (legal retainer, tooling, ops) | $10,000 / month | $40,000 |

Two things fall out of that table. The first is the composition: **$194,000 of the $234,000, or 83%, is compensation for eleven people holding governance roles.** Everything else a working group needs, legal retainer and tooling and operations together, is the remaining 17%. A DAO’s floor cost is its roster, not its infrastructure.

The second is the retrospective itself. The [executable proposal](https://discuss.ens.domains/t/executable-ens-stakeholder-analysis-and-retro/21792) that commissioned it requested **$125,000** to the Meta-Governance multisig, released against milestones and clawable back by social proposal at any point. Over the same four months, the entire working-group structure being studied ran on $234,000. **Examining the spending cost 53% of what the thing being examined cost to operate during the examination.** That is not an argument against the retro, which produced a published report and a twelve-month roadmap. It is an argument that meta-governance is itself a cost class, and one that no DAO reports as such.

The pause had a further cost that never appears in any budget. By [May 2026](https://discuss.ens.domains/t/path-forward-on-working-groups-for-term-7/22107), with the retro published several weeks past its April target and two structural proposals still open, stewards were described as operating at reduced capacity with no clear mandate and no election timeline. Term 7 was eventually sequenced to begin on 1 July 2026, roughly seven months after elections were first delayed.

## Arbitrum: the largest lines sit outside “governance”

Arbitrum makes the boundary problem concrete, because its two biggest governance-adjacent costs are not counted as governance costs by anyone.

**The strategy firm.** [Entropy Advisors](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458) works exclusively with the Arbitrum DAO under a two-year mandate running 1 September 2025 to 31 August 2027, at a **base fee of $3M per year**, claimable as monthly payments of $250,000 from the Arbitrum Foundation. That is an increase of roughly $500,000 a year on the first term, which ran at $205,834 a month. The engagement also carries a 5M ARB vesting allocation on a one-year cliff and three-year vest, with a further 10M ARB held by the Foundation for milestone-based alignment mechanisms to be negotiated separately. The firm publishes monthly updates to the forum and was still doing so in [June 2026](https://forum.arbitrum.foundation/t/entropy-advisors-monthly-update-june-2026/31045).

**The operating company.** Arbitrum’s OpCo is a DAO-adjacent legal entity created to execute strategy. Its [second bi-annual transparency report](https://forum.arbitrum.foundation/t/opco-oat-2nd-bi-annual-transparency-report-may-2026/30924), covering activity to 30 April 2026, states cumulative expenses of **$1,148,778 and 100,000 ARB**, of which $568,179 was incurred since the previous report six months earlier. The breakdown is the interesting part:

|  |  |
| --- | --- |
| Admin & Operations | $561,907 |
| OAT compensation | $367,500 |
| Incorporation and legal | $192,316 |
| Event hosting | $13,784 |
| Firestarter grants | $13,270 |

**$192,316 of it is the cost of existing as an entity at all**, before the entity does anything. That is the price of the boundary itself: a DAO that wants a legal counterparty to sign contracts, hold funds and employ people pays a six-figure setup, and every cost that then moves inside that entity leaves the DAO’s own governance budget. Optimism’s +38% is the same mechanism running in reverse.

Arbitrum’s third line, the delegate payroll, is the one that _is_ reported as governance spending, and it is by some distance the smallest of the three. Its [July 2026 quarterly review](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) repriced the whole schedule downward as ARB fell, cutting per-proposal rates 28–40%. That programme is covered in detail on [delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs), and the commercial relationship behind the first two lines — how a provider is selected, renewed and terminated — on [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers).

## Reading a governance cost figure

Four questions make two DAOs’ numbers comparable, or establish that they are not:

1. **Which entity holds the line?** A cost paid by a foundation, an operating company or a service provider does not appear in the DAO’s governance budget. Optimism’s Security Council cost the same in Season 6 and Season 7; only the payer changed. Ask what the foundation covers before comparing anything.
2. **What is it denominated in, and what is it paid in?** A budget set in USD and settled in the governance token spends the most tokens exactly when the token is cheapest, and a budget set in the token reports a flat number while its real cost swings with the market. Optimism reports in OP; ENS reports in USDC; Arbitrum sets delegate rates in USD and pays in ARB. None of the three series is directly comparable to the others in any year.
3. **What is inside the scope?** Councils and stewards almost always count. Strategy firms, operating companies, legal entities, security audits and tooling subscriptions usually do not, and they are frequently larger. One class is outside every scope surveyed here because it has no claimant at all: the gas to execute a passed proposal, which the Governor designs leave with whichever member or bot sends the transaction ([who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs)).
4. **Did anything get reclassified?** A multi-season series is only a series if the boundary held across it. When a body moves between payers, the year-on-year change is an accounting artefact until you net it out.

A useful discipline for a DAO publishing its own figures is to report the cost twice: once on this year’s boundary and once on last year’s. Optimism’s report comes closest of the three by disclosing the reclassification in the same paragraph as the headline, which is what makes the correction possible at all.

## How Caper approaches this

Every cost class on this page traces back to the same root: governance in a token DAO is work done by people who must be found, elected, compensated and audited, and the apparatus that does the finding, electing, compensating and auditing is itself an ongoing expense. Caper does not have a cheaper version of that apparatus. It does not have the apparatus.

There is no delegate, steward or council class in the contracts. A search for delegation primitives across all three crates returns nothing, so there is no standing body whose seats need funding and no delegated weight to subsidise or retain. The two things a member can do in governance, propose and vote, are both priced as fees paid _into_ the caper’s treasury rather than as budget paid out of it: `create_proposal` requires an XRD payment equal to the configured proposal fee, and the core contract deposits it straight into the treasury vault; `vote` requires an XRD payment equal to the configured vote fee, and deposits it into the same treasury even on the path where a ballot arrives outside the voting window and is rejected. Both fees are settings an admin can change through `update_fees`, not constants, so the schedule is a policy rather than a property of the protocol.

One governance cost a caper does carry is the gas to resolve a proposal after voting closes, and it is the treasury that carries it: every call on the settle path draws up to 5 XRD against a per-proposal allowance equal to the proposal fee that proposal already paid in, so the work is funded by the proposal rather than by whichever member happens to run it. That inverts the Governor default, where `execute` is permissionless and the caller absorbs the gas unreimbursed — a real recurring cost that appears in none of the ledgers above. The mechanism is on [execution](/wiki/governance/execution).

The honest statement of the tradeoff is that this moves the cost rather than removing it. A caper’s governance has no payroll because it has no roles, and the participation it gets is whatever members will pay a fee to supply. That buys a treasury whose governance line is structurally positive and a cost series with no boundary to reclassify, and it gives up the specialised review that a funded council is meant to provide. Which side of that trade a given organisation wants is exactly the question the ledgers above are trying to settle. Background on the model is on [what is a caper](/wiki/foundations/what-is-a-caper), and the flow those fees ride on is on [proposals](/wiki/governance/proposals) and [voting](/wiki/governance/voting).

## References

- [Token House participation and incentives: Season 7 (Cycle 31a-38)](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) — SEEDGov, gov.optimism.io. Season 7 operating costs, the S3–S7 budget evolution, and the Intent budget.
- [[Temp Check] Metagov Update: Working Group Operations During the ENS Retro](https://discuss.ens.domains/t/temp-check-metagov-update-working-group-operations-during-the-ens-retro/21781) — discuss.ens.domains. The continuity budget and the October 2025 approved allocations.
- [[Executable] ENS Stakeholder Analysis and Retro](https://discuss.ens.domains/t/executable-ens-stakeholder-analysis-and-retro/21792) — discuss.ens.domains. The $125,000 retrospective budget and its milestone terms.
- [Path forward on Working Groups for Term 7](https://discuss.ens.domains/t/path-forward-on-working-groups-for-term-7/22107) — discuss.ens.domains. The election-pause timeline and the Term 7 sequencing.
- [Entropy Advisors: Exclusively Working with the Arbitrum DAO, Y2-Y3](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458) — forum.arbitrum.foundation. Base fee, payment schedule and the ARB alignment structure.
- [OpCo/OAT 2nd Bi-annual Transparency Report, May 2026](https://forum.arbitrum.foundation/t/opco-oat-2nd-bi-annual-transparency-report-may-2026/30924) — forum.arbitrum.foundation. Cumulative OpCo expenses by category to 30 April 2026.
- [RAD Budget Quarterly Review 2Q2026](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) — forum.arbitrum.foundation. The repriced delegate payroll.

## DAO metrics and analytics

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | DAO metrics and analytics |
| **What it measures** | The health of a DAO — governance participation, voting-power concentration, and treasury/financial position |
| **Core participation metrics** | Voter turnout, quorum attainment, proposal throughput, pass rate |
| **Core concentration metrics** | Nakamoto coefficient, delegate share, Gini / voting-bloc entropy |
| **Core treasury metrics** | Size, asset composition, runway (see [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management)) |
| **Where the data lives** | [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao), [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom), [Tally / Cactus](https://www.tally.xyz/), [Dune](https://dune.com/), [Token Terminal](/wiki/dao-governance/tooling/analytics/token-terminal) |
| **Why it matters** | Recency-weighted, quantitative queries — "is this DAO actually decentralized?" — are answered with these numbers, not marketing |

**DAO metrics** are the quantitative measures used to judge whether a [decentralized autonomous organization](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) is healthy: how many members actually vote, how concentrated its voting power is, how quickly it processes decisions, and how large and durable its treasury is. Because a DAO's governance and finances are recorded on a public ledger, these figures are measurable in a way corporate governance rarely is — every vote, delegation, and treasury movement is on-chain. This page is a reference for the metrics that matter and where to read them live; it links out to the deeper concept pillars for each mechanism.

## Governance participation metrics

**Voter turnout** — the share of eligible voting power (or of eligible holders) that participates in a given vote — is the headline number, and it is chronically low. Single-digit-percentage turnout is the norm even in flagship DAOs, and turnout by _holder count_ is usually far lower than turnout by _token weight_, because a handful of large holders and [delegates](/wiki/dao-governance/concepts/voting/voting-and-delegation) carry most votes. a16z crypto's [DAO research roadmap](https://a16zcrypto.com/posts/article/dao-research-a-roadmap-for-experimenting-with-governance/) frames turnout as one of the open problems of on-chain governance, drawing directly on the political-science literature on civic participation.

Related participation figures:

- **Quorum attainment** — the fraction of proposals that reach the minimum participation threshold required to be valid. Setting quorum too high stalls a low-turnout DAO; too low, and a small coalition can pass binding changes. A frequently-cited cautionary case is a 2021 SushiSwap proposal that would have handed treasury control to a single multisig and passed with roughly 3% of supply voting.
- **Proposal throughput** — how many proposals a DAO processes over a period, across the [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) (forum discussion → temperature check → on-chain vote). Throughput signals whether governance is a living process or a rubber stamp.
- **Pass / approval rate** — the share of on-chain proposals that succeed. A pass rate near 100% often means real contestation happened off-chain (in [temp checks](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance)) before anything reached a binding vote, so the on-chain record alone understates disagreement.

## Voting-power concentration

Turnout tells you how _many_ people vote; concentration metrics tell you how much it would matter if the rest did. The best-known is the **Nakamoto coefficient** — the minimum number of entities whose combined voting power exceeds the threshold needed to control an outcome (a simple majority, or the quorum). A small coefficient means a handful of [token holders](/wiki/dao-governance/concepts/voting/token-weighted-voting) or delegates can dictate results. Empirical work on major [token-weighted DAOs](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) has repeatedly found this coalition to be small — on the order of single digits to low tens of addresses for prominent protocols ([Analyzing voting power in decentralized governance: Who controls DAOs?](https://www.sciencedirect.com/science/article/pii/S2096720924000216), 2024). Because delegations shift daily, the current value should be read from a live tracker rather than a static number.

Complementary concentration measures:

- **Delegate breakdown** — the share of total voting power held by the top _N_ delegates, and how much of that is self-delegated versus delegated by others. [ENS](/wiki/daos/infrastructure/ens-dao), [Uniswap](/wiki/daos/dexs/uniswap-dao), and [Compound](/wiki/daos/lending/compound-dao) publish this on their governance front-ends.
- **Gini coefficient** — the classic inequality measure applied to the voting-power distribution.
- **Voting-bloc entropy** — a newer decentralization metric that scores how votes actually cluster into aligned blocs over time, rather than counting token balances at a single instant ([DAO Decentralization: Voting-Bloc Entropy](https://arxiv.org/abs/2311.03530), 2023).

Whether a DAO is "decentralized enough" is itself contested; the academic framework [When is a DAO Decentralized?](https://arxiv.org/abs/2304.08160) (2023) argues it is not a single number but five dimensions — token distribution, infrastructure, governance, escalation, and reputation — measured together.

## Treasury and financial metrics

The financial side is covered in depth on [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management); the metrics that summarise it are **treasury size** (total value of assets the DAO controls), **asset composition** (the share held in the DAO's own governance token versus stablecoins and blue-chips — the concentration problem), and **runway** (how many months of budgeted outflows the liquid, non-native portion covers). [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) aggregates treasury value across thousands of tracked organisations — an order of tens of billions of dollars in total, though the figure swings with token prices, so it is best read live rather than quoted. Pairing runway with [contributor-compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) outflows is what turns a treasury balance into a solvency signal.

## Where the data lives

No single dashboard is authoritative; the practical answer is to triangulate:

- [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) — the widest cross-DAO index: treasury value, member counts, participation, and governance activity for thousands of organisations. Its public site has been unreachable since mid-2026, so its figures now read as a snapshot of the field up to May 2026 rather than a live source.
- [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) and [Tally](https://www.tally.xyz/) (continued as [Cactus](/wiki/dao-governance/tooling/voting/tally)) — proposal-level and delegate-level data on the DAOs whose governance they host.
- [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) — the raw record of off-chain signalling votes and their turnout.
- [Dune](https://dune.com/) — community-built SQL dashboards for bespoke, DAO-specific metrics.
- [Token Terminal](/wiki/dao-governance/tooling/analytics/token-terminal) and [on-chain analytics](/wiki/dao-governance/tooling/analytics/deepdao) — protocol revenue and financial fundamentals behind a treasury.

## The limits of DAO metrics

Every metric here is gameable and partial. Turnout can be inflated by a single whale voting on trivial proposals; a Nakamoto coefficient counts _addresses_, so one entity splitting across many wallets looks decentralised while a Sybil cluster looks like a crowd (see [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos)). Off-chain deliberation — the forum threads and Discord debates where most real governance happens — leaves no on-chain trace, so a healthy DAO can look inert on-chain. And once a number becomes a target (Goodhart's law), participants optimise the metric rather than the health it was meant to proxy. Read metrics as a starting question, not a verdict.

## How Caper approaches this

Several numbers a conventional DAO has to _monitor_, a [caper](/wiki/foundations/what-is-a-caper) makes _structural_. Voting weight is not just a token balance to watch for concentration: it is `(t·v)/(V·T)`, where a member's live governance-token holding _t_ is multiplied by their earned, non-transferable [vote-token](/wiki/governance/voting) balance _v_ — so a member who has never participated has weight zero, and buying tokens without voting buys no influence (verified against the contract's `compute_vote_weight`). Turnout and concentration are therefore coupled to participation by construction rather than tracked after the fact. The treasury is the [bonding-curve](/wiki/markets/bonding-curve) vault, funded as members buy in, so its size is legible from the curve state rather than assembled from multisig balances. And "runway risk" is bounded from the other side: any member can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) for their pro-rata share at any time — the same `(t·v)/(V·T)` weight — so a stagnating treasury is priced continuously by exits, not discovered in a quarterly report. Caper does not invent new metrics; it removes the gap between the number and the thing it measures.

## DAO procurement and requests for proposals

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Concept** | A DAO buying a capability from outside itself through a published open call rather than a bilateral deal |
| **The artefacts** | A request for proposals (RFP), an evaluation rubric published before submissions, a hard deadline, and a scored award |
| **Canonical open call** | [Lido, RFP: Market Making](https://research.lido.fi/t/request-for-proposals-market-making/1737) (23 Feb 2022) — a five-heading rubric that drew five posts and not one market-maker proposal in the thread |
| **Canonical open tender** | [Arbitrum's ADPC Security Services Panel](https://forum.arbitrum.foundation/t/request-for-proposal-the-adpc-security-services-panel-and-procurement-framework/25031) (19 Jun 2024) — 12 applicants, 9 moved to whitelisting |
| **Unsolicited public bid** | [GSR's OHM market-making proposal](https://forum.olympusdao.finance/d/535-market-making-proposal-from-gsr) — a 25,000 OHM loan with two embedded calls, priced by the forum in the replies |
| **What a call surfaces** | Prices, refusals and the shape of the supply side — not reliably proposals |
| **Failure mode** | A closed panel is a barrier to every provider outside it, and reopening it becomes a governance decision of its own |
| **Related** | [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers) · [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) · [OTC placements and market-maker loans](/wiki/dao-governance/concepts/treasury/otc-placements-and-market-maker-loans) |

## Procurement is the part of governance that happens before the vote

A DAO that needs an audit, a market maker, a treasury manager or an RPC endpoint has to buy it. The vote that approves the spend is the visible half; the invisible half is how the counterparty got in front of the DAO in the first place. Someone drafted a scope, someone decided who was allowed to bid, someone set the deadline, and someone scored the answers. That is **procurement**, and in most DAOs it is either undocumented or done by whoever happened to know a vendor.

The formal instrument for doing it in the open is the **request for proposals**: a published scope, a stated set of things a proposal must address, a submission window, and an evaluation the DAO commits to in advance. The [service-provider page](/wiki/dao-governance/concepts/analysis/dao-service-providers) covers the shapes of the resulting relationship — the open programme, the exclusive mandate, the operating company. This page is about the call itself: what a DAO writes down, who answers, and what the exercise actually produces.

The honest finding across the record is that an open call is worth running even when it fails on its own terms. Lido's drew no public bids and the deal it was meant to source happened anyway. What the call bought was a written rubric, a public price, and an argument the community could have before the money moved rather than after.

## The open call: Lido, 2022

[Lido](/wiki/daos/staking/lido-dao) ran the cleanest small example. In February 2022 a contributor posted a temperature check asking whether the DAO should hire a market maker at all, noting that LDO was “virtually unlisted” on centralized exchanges while UNI, COMP, AAVE and SUSHI were everywhere. The [sentiment check](https://research.lido.fi/t/market-makers-and-cex-listings/1641) offered four options and closed with **57% for opening a call for market makers to put forward terms**. Only then did the RFP go up.

The [RFP itself](https://research.lido.fi/t/request-for-proposals-market-making/1737) is five headings long, and the headings are the interesting part because they are the DAO stating what it does not know: proposed deal terms (“possibly: treasury loan, embedded call options, length”), assurances about the firm's background, case studies of previous DAO engagements, whether the firm can assist with listings, and the success KPIs. Publishing that list did two things at once. It told bidders the DAO already understood the [loan-plus-embedded-call](/wiki/dao-governance/concepts/treasury/otc-placements-and-market-maker-loans) structure and would ask about it, and it gave delegates a checklist to hold any eventual proposal against.

Then nothing happened. The thread ran to five posts, all from community members — one asking how it would affect the LDO price, one asking that other Lido assets be included in scope. No market maker posted terms in public. The instruction the original poster gave a fortnight earlier is worth quoting for what it assumed: receiving proposals is “non binding and as such would only bring free optionality to the DAO.” The optionality was free; it was also, in the event, empty.

## The unsolicited bid: GSR and Olympus

Lido's own sentiment-check thread pointed at the precedent it was hoping to reproduce: market makers who [“work via this process”](https://research.lido.fi/t/market-makers-and-cex-listings/1641) and disclose specific deal terms in the open, with [OlympusDAO](/wiki/daos/stablecoins/olympusdao) cited as the example. That thread is instructive on its own. GSR posted a full [market-making proposal](https://forum.olympusdao.finance/d/535-market-making-proposal-from-gsr) for OHM directly to the Olympus forum: a loan of 25,000 OHM for liquidity provision, repayable either in kind at 0% interest or by buying out 12,500 OHM at $15,625,000 after six months and 12,500 OHM at $18,750,000 after twelve.

The forum then did the thing a private negotiation cannot. A reply decomposed the term sheet into what it actually was — a six-month call and a twelve-month call on OHM, granted with **no premium paid** — and asked GSR to revise the deal with real collateral or a premium. Nobody had to run a scoring rubric for that to happen. The proposal was legible because it was public, and being legible is what got it priced.

This is the counterweight to the tidy procurement story. An unsolicited bid posted where the whole DAO can read it produces most of the transparency benefit of a formal RFP, and produces it without the DAO having to run a process at all. What it does not produce is comparability: one bid scrutinised is not the same as four bids ranked.

## The open tender: Arbitrum's procurement committee

[Arbitrum DAO](/wiki/daos/networks/arbitrum-dao) is the only DAO to date that has built a standing procurement function rather than running calls ad hoc. The Arbitrum DAO Procurement Committee (ADPC) was established by an on-chain vote and has since issued its own RFPs under a common framework, describing the first of them as the industry's first strategic-sourcing procurement framework.

The design borrows from public-sector purchasing and is worth naming precisely, because it is not an RFP in the one-off sense. The ADPC runs a **panel**: providers apply once to be whitelisted as _Sellers_ against a head agreement with pre-agreed terms, conditions and pricing, and thereafter _Buyers_ — project teams receiving subsidies, in the security case — order off the panel under a work-order template instead of negotiating from scratch. The [Security Services Panel](https://forum.arbitrum.foundation/t/request-for-proposal-the-adpc-security-services-panel-and-procurement-framework/25031) (June 2024) made that framework mandatory for anyone drawing on the security subsidy fund; the [RPC Service Providers Panel](https://forum.arbitrum.foundation/t/request-for-proposal-rpc-service-providers-panel-and-procurement-framework/28315) (January 2025) ran the same machinery on a non-mandatory basis, with the framework noting that this could change if a subsidy programme were attached.

The DAO also uses the plain form. Its [treasury management RFP](https://forum.arbitrum.foundation/t/rfp-process-request-for-proposals-treasury-management-services-for-arbitrum-dao/28242) (January 2025) put 25M ARB in scope with a specific brief — 10M ARB deployed in ARB-only on-chain strategies, 15M converted to stablecoins over three months with applicants required to state how they would minimise slippage and market impact — and took [submissions on the public forum](https://forum.arbitrum.foundation/t/request-for-proposals-treasury-management-services-for-arbitrum-dao/28363), where firms posted their strategies and got told off in-thread for exceeding the requested format. That is a different transparency trade from the panel: every bid is readable by every competitor.

## Tender probity, written down

The most reusable artefact the ADPC produced is not a panel — it is the [explanation it gave](https://forum.arbitrum.foundation/t/request-for-proposal-the-adpc-security-services-panel-and-procurement-framework/25031) when a delegate asked why 3 of 12 applicants were cut. The committee declined to give per-applicant reasons, then set out the rules it had held itself to, and those rules are the transferable part:

- **No target number.** The committee had no pre-decided panel size and waited to see the applications as a whole before deciding — the cut came from the scoring producing “2 distinct groupings”, with a group of 9 stronger in aggregate, not from a quota.
- **The deadline is the deadline.** The overall date was extended once, for EthCC, and applied to everyone; no individual applicant was allowed to amend a submission afterwards, on the stated grounds that a deadline nobody enforces is not a deadline.
- **Questions answered to the whole field.** Applicant questions were answered to all applicants, anonymised, so asking a question carried no competitive cost — and the number or type of questions asked was explicitly excluded from scoring.
- **Criteria published before submissions.** The evaluation criteria were in the RFP, and the committee ran the comparison against them rather than against its own impressions.

The committee's own name for this is _tender probity_: avoiding favouritism and giving every applicant a level playing field. It is the same set of commitments a public buyer makes, and it exists for the same reason. A DAO that awards work without them has a procurement process that cannot be distinguished, from the outside, from a DAO that awards work to friends. Where that distinction collapses entirely, the failure belongs to the [capture](/wiki/dao-governance/concepts/analysis/how-daos-fail) literature rather than the procurement one.

## A panel is a barrier as well as a marketplace

Five months after the security panel closed, [Oak Security posted in the same thread](https://forum.arbitrum.foundation/t/request-for-proposal-the-adpc-security-services-panel-and-procurement-framework/25031): clients wanted to build on Arbitrum and use the subsidy, but wanted to work with Oak, which was not whitelisted. Were there plans to add providers, or to run another RFP? The answer was that the subsidy fund was still in its pilot phase, that the committee would take the learnings, and that a process for adding providers was possible _if_ the community wanted the fund expanded — conditional on the pilot succeeding and on the DAO's continued appetite.

Nothing in that exchange is bad faith. It is the structural cost of the panel model stated plainly. A whitelist attached to a subsidy is not just a convenience for buyers; it is a determination of who can be paid, and every provider outside it now has to win a governance argument rather than a commercial one. The one-off RFP has the opposite property: it is worse at repeat purchasing and better at staying open, because the next purchase reopens the field by default.

The same asymmetry runs through the [renewal problem](/wiki/dao-governance/concepts/analysis/dao-service-providers): scrutiny is loudest at the first award and quietest at every award after it. Procurement design is largely a choice about where to put the friction — at entry, where it filters, or at renewal, where it corrects.

## What an open call actually surfaces

Set the three records side by side and the pattern is not “RFPs work.” It is that a call surfaces different things depending on how thick the supply side is.

- **A thin market answers privately or not at all.** Lido's call drew zero public bids from firms that were, demonstrably, willing to do the deal. Market makers will state terms in a forum when they are pitching an incumbent relationship and will not when they are one of several being compared.
- **A thick market answers in public and stays comparable.** Twelve security firms answered Arbitrum's tender; [ENS DAO](/wiki/daos/infrastructure/ens-dao) drew 26 applications requesting $12.2M against $3.25M available in its [service-provider programme](/wiki/dao-governance/concepts/analysis/dao-service-providers). Both fields were deep enough that a rubric had something to discriminate between.
- **The rubric outlives the call.** Lido's five headings and Arbitrum's evaluation criteria are reusable whether or not the specific call produced bids — and they are the part a DAO can be held to next time. What the resulting score decides once the bids are in is a separate question, and usually less than it looks: [scoring and review gates](/wiki/dao-governance/concepts/analysis/scoring-and-review-gates).
- **A refusal is information.** An empty thread tells the DAO the terms it advertised were not attractive at that price, which is worth learning before a vote rather than after one.

None of this is free. Running a scored tender is real [governance operating cost](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) — a committee, a legal framework, an evaluation period measured in months — and the ADPC's frameworks required a paid committee and outside legal drafting to exist at all. The cheapest honest position is Olympus's: let bids arrive in public and let the forum price them. The most expensive is a standing panel. Most DAOs should be somewhere in between, and should at minimum write the rubric down.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no procurement layer, because it has no standing organisation to procure for. There is no committee, no head agreement, no whitelist — a caper's treasury moves when a [proposal](/wiki/governance/proposals) passes and settles, and that is the whole apparatus. What that removes is the renewal problem: there is no incumbent contract quietly rolling over, because there is no contract.

Two design choices are relevant to the part of procurement DAOs find hardest, which is what a member can do when they lose the argument about a spend. First, proposing and voting cost fixed fees rather than being free, so contesting an award has a price and so does spamming one — and those fees are platform-wide rather than per-caper, held on the shared logic component and changeable only by the protocol admin badge, not by any individual caper's own governance.

Second, a member who has lost the argument can leave with a share rather than only sell. A caper's `exit` pays out a share of the treasury computed as `(t · v) / (V · T)` — the member's governance tokens times their votes cast, over total votes times circulating supply — which is the _same_ formula that weighs their vote. Exiting requires surrendering both the governance tokens and the soulbound vote tokens. The practical consequence for the procurement question is narrow but real: a member who thinks a spend is capture does not have to win a renewal vote to stop funding it, and the share they leave with is priced off how much they participated, not how large their bag is.

## References

- [Lido Research — Market makers and CEX Listings (2 Feb 2022)](https://research.lido.fi/t/market-makers-and-cex-listings/1641), the four-option sentiment check that authorised the call.
- [Lido Research — Request for Proposals: Market Making (23 Feb 2022)](https://research.lido.fi/t/request-for-proposals-market-making/1737), the five-heading rubric; five posts, no vendor proposals.
- [Olympus DAO Forum — Market Making Proposal from GSR](https://forum.olympusdao.finance/d/535-market-making-proposal-from-gsr), the unsolicited bid and the community's option-pricing objection.
- [Arbitrum Forum — RFP: The ADPC Security Services Panel and Procurement Framework (19 Jun 2024)](https://forum.arbitrum.foundation/t/request-for-proposal-the-adpc-security-services-panel-and-procurement-framework/25031), including the whitelisting update (9 of 12) and the tender-probity explanation.
- [Arbitrum Forum — RFP: RPC Service Providers Panel and Procurement Framework (31 Jan 2025)](https://forum.arbitrum.foundation/t/request-for-proposal-rpc-service-providers-panel-and-procurement-framework/28315).
- [Arbitrum Forum — [RFP Process] Request for Proposals: Treasury Management Services (22 Jan 2025)](https://forum.arbitrum.foundation/t/rfp-process-request-for-proposals-treasury-management-services-for-arbitrum-dao/28242), the 25M ARB scope.
- [Arbitrum Forum — Request for Proposals: Treasury Management Services, submissions thread (6 Feb 2025)](https://forum.arbitrum.foundation/t/request-for-proposals-treasury-management-services-for-arbitrum-dao/28363).

## DAO security and governance attacks

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | How DAOs get attacked through their own governance, and how they defend |
| **Core risk** | A public, contract-enforced treasury steered by a vote anyone can try to acquire, borrow, or fake |
| **Attack families** | Flash-loan vote seizure · open-market / custodial token acquisition · slow Sybil accumulation · oracle-manipulation-then-governance · code exploits |
| **Landmark cases** | The DAO (2016) · Beanstalk (~$182M, 2022) · Steem / Justin Sun (2020) · Mango Markets (~$117M, 2022) · Compound Prop 289 (2024) · [BonkDAO](/wiki/daos/social/bonkdao) (~$20M, 2026) |
| **Core defenses** | Timelocks · voting-power snapshots · proposal thresholds & quorum · guardian vetoes · limiting governance scope |
| **Related** | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) |

A **DAO governance attack** is any manoeuvre that turns a decentralized organization's own decision-making machinery against it — capturing enough voting power, or exploiting the code that counts it, to pass a proposal the community never wanted, usually to drain the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management). Because a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) holds its funds in a public smart contract steered by a vote rather than by trusted officers, its governance _is_ its attack surface: anyone who can acquire, borrow, or manufacture voting weight is a candidate attacker, and the contract executes the result without a referee. This page catalogs the recurring attack families with their landmark case studies, then the defenses that have become standard practice.

## Why DAOs are uniquely exposed

Three properties that make DAOs attractive also make them fragile. Their treasuries are **large and transparent** — a would-be attacker can read the exact prize on-chain. Their control rule is **mechanical** — a proposal that clears the threshold executes automatically, with no board to say "this is obviously theft." And voting power is usually a **liquid, purchasable token** — the same tradability that bootstraps a community lets an outsider buy or rent influence on the open market. As [a16z crypto](https://a16zcrypto.com/posts/article/dao-governance-attacks-and-how-to-avoid-them/) puts it, a governance token is not just a coordination tool but "an attack vector" the moment its market price of control falls below the value it controls.

## The attack taxonomy

**Flash-loan vote seizure.** The fastest attack borrows the voting power outright. In the [April 2022 Beanstalk exploit](https://www.coindesk.com/tech/2022/04/17/attacker-drains-182m-from-beanstalk-stablecoin-protocol), an attacker flash-borrowed more than $1 billion in stablecoins, converted it to a super-majority of Beanstalk's governance token, and used the protocol's `emergencyCommit` function to instantly pass a proposal (BIP-18) that transferred roughly **$182 million** of reserves to their own wallet — all inside a single transaction, netting about $76 million after repaying the loan ([Halborn analysis](https://www.halborn.com/blog/post/explained-the-beanstalk-hack-april-2022)). The enabling flaw was the absence of a meaningful **execution delay**: voting power that exists for one block should never be able to move funds in that same block.

**Open-market or custodial token acquisition.** A patient attacker simply buys control. When Justin Sun acquired Steemit in 2020, the community moved to freeze his stake; Sun allegedly used [exchange-custodied user tokens](https://a16zcrypto.com/posts/article/dao-governance-attacks-and-how-to-avoid-them/) from Binance, Huobi and Poloniex to out-vote the existing witnesses, and the community forked away to Hive in response. This _social fork_ — abandoning a captured chain for an honest copy — is the ultimate backstop against a majority that cannot be out-voted, and [EigenLayer](/wiki/daos/staking/eigenlayer)'s EIGEN token turns it into an explicit on-chain mechanism, forking to slash a colluding majority without assuming an honest one. The 2024 [Compound "Golden Boys" episode](https://unchainedcrypto.com/compound-governance-attackers-agree-to-cancel-proposal-in-exchange-for-staking-product/) was a subtler variant: a group led by "Humpy" accumulated COMP on the open market and narrowly passed **Proposal 289**, directing 499,000 COMP (~$24 million) into a yield vault under their influence, over the objections of core delegates — before public pressure forced them to rescind it. It showed that a bare majority, lawfully acquired, can still be a capture.

**Slow Sybil accumulation.** The quietest attack spreads a growing position across many anonymous wallets that behave like ordinary holders, avoiding the alarm a single whale would trigger, until the aggregate crosses a decision threshold. It is hard to detect precisely because each account looks legitimate, and it targets the same weakness as a low-turnout raid: when most holders are apathetic, a modest coordinated minority can decide a vote.

**Oracle manipulation feeding governance.** In the October 2022 [Mango Markets exploit](https://www.cftc.gov/PressRoom/PressReleases/8647-23), Avraham Eisenberg manipulated the price oracle for the MNGO token to drain roughly **$117 million**, then used the MNGO he still held to _vote through a governance proposal_ letting him keep about $47 million as a "bug bounty" and seeking immunity — laundering a market exploit through the DAO's own ballot. (A jury convicted Eisenberg in 2024; a federal judge [overturned the convictions in 2026](https://www.trmlabs.com/resources/blog/breaking-federal-judge-overturns-all-criminal-convictions-in-mango-markets-case-against-avraham-eisenberg), a reminder that the legal status of these attacks is still unsettled.)

**A payload that does not match its description.** Where the frameworks above execute raw `calldata`, a proposal's title and its effect are separate objects, and only the title is read. Tornado Cash lost governance control of itself in May 2023 to a proposal presented as a copy of an earlier approved one; per [Halborn's analysis](https://www.halborn.com/blog/post/explained-the-tornado-cash-hack-may-2023) the deployed contract carried extra self-destruct logic, and after the vote passed the attacker destroyed it, redeployed different code at the same address, and minted themselves 1.2 million votes against roughly 70,000 legitimate ones — draining about 483,000 TORN (~$2.17 million). No voting rule was broken. The gap it exploited is structural to [arbitrary proposal execution](/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution), and no quorum or threshold setting can close it.

**Code exploits of the governance contract itself.** The original cautionary tale is [The DAO (2016)](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao): not a vote-capture at all but a **reentrancy** bug in the withdrawal logic that let an attacker recursively drain about 3.6 million ETH (~$60 million then), an event so large it split Ethereum into ETH and Ethereum Classic. It is the permanent reminder that the safest governance rule is still only as safe as the contract implementing it.

## Case study: BonkDAO, July 2026 — buying the quorum

The [BonkDAO](/wiki/daos/social/bonkdao) attack is the cleanest recent demonstration that the three defenses below are load-bearing, because it succeeded on a treasury protected by none of them. On **30 June 2026** an anonymous wallet filed **BIP #76**, titled "Sowellian BonkDAO" and presented as a governance-renewal plan, to the DAO's [Realms](https://realms.today/) instance on Solana. The operative clause instructed the treasury to send **4.43 trillion BONK** — the bulk of it — to a wallet the proposer controlled, and it sat in public view for six days while no organized opposition formed ([crypto.news](https://crypto.news/the-bonk-governance-attack-how-a-dao-lost-20-million-in-one-proposal/)).

Over **4–5 July** the attacker bought just over 1% of the BONK supply — roughly **882 billion tokens for about $4.4 million**, sourced on Bybit and Binance and part-funded by borrowing against DeFi collateral. That figure was not arbitrary: BonkDAO's quorum was set at 1% of supply, or **879.95 billion BONK**, so the purchase was sized to clear the participation floor and nothing more. The final tally was **882.38 billion in favour against a 879.95 billion threshold** — quorum cleared by about 0.3% — with the attacker holding roughly **99.878% of the votes cast** ([CoinDesk](https://www.coindesk.com/markets/2026/07/07/bonk-faces-usd20-million-treasury-drain-after-attacker-spends-usd4-million-to-pass-malicious-proposal), [Halborn](https://www.halborn.com/blog/post/explained-the-bonkdao-hack-july-2026)).

The proposal passed on **6 July 2026** and executed immediately — Realms runs a passed instruction with no mandatory delay, so there was no window in which anyone could have cancelled it. Around **$20 million** left the treasury; roughly $188,000 was moved to an exchange within nine hours and about $19 million was parked in a "BONK 2.0" multisig with three attacker-linked signers. BonkDAO [confirmed the attack publicly](https://news.bitcoin.com/bonkdao-treasury-loses-20m-in-malicious-governance-attack-bonk-slides-8/) and said it was working with exchanges, the Solana Foundation, bridges and law enforcement on recovery.

Three ordinary design choices compounded into the loss. **Quorum was a ceiling, not a floor.** A 1% participation threshold in a DAO where turnout runs near 1% means the quorum figure _is_ the electorate: buying it outright bought the outcome. **Turnout made the raid cheap.** Seven wallets voted out of more than 18,000 members — a turnout of about 2.9% — so the attacker never had to out-vote the community, only to out-vote the handful who showed up (see [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy)). And **execution was instant.** A timelock would not have stopped the vote, but it would have converted a six-day-old public proposal into a cancellable one. Priced against the a16z framing above, control of the treasury cost about **22 cents for every dollar taken** — which is the whole of the attack in one number.

## Defenses that became standard

No single control is sufficient; mature DAOs layer several, and the widely-used [OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/4.x/api/governance) framework ships most of them by default.

- **Timelocks / execution delay.** A mandatory delay between a vote passing and the action executing gives holders time to see a malicious proposal and react — the single control whose absence made Beanstalk possible.
- **Voting-power snapshots.** Counting each voter's weight as of a _past_ block (the proposal's creation) rather than live means tokens borrowed after a proposal is filed carry no weight — the standard structural answer to flash-loan seizure.
- **Proposal thresholds and quorum.** Requiring a minimum stake to _submit_ a proposal, and minimum participation for one to count, raises the cost of spam and low-turnout raids.
- **Guardian vetoes and security councils.** A trusted multisig or elected council that can cancel a clearly-malicious proposal within the timelock window — as [Nouns and others use](https://a16zcrypto.com/posts/article/dao-governance-attacks-and-how-to-avoid-them/) — trades a little decentralization for a circuit-breaker.
- **Limiting governance scope.** The most robust defense is architectural: if governance simply _cannot_ express "transfer all reserves to this address," the most valuable attack has no proposal to ride. Restricting what a vote is allowed to do shrinks the attack surface more than any amount of vote-counting cleverness.

For a fuller academic treatment, see the 2025 survey [on DAO governance attacks and defenses](https://arxiv.org/html/2505.00888v1).

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) is built so that several of these defenses are structural rather than optional. **Governance scope is bounded by construction:** a proposal can only be a [PAYOUT, INVEST, or VOTE](/wiki/governance/proposals) action, so there is no "call this arbitrary contract and drain the vault" proposal to ride — the single most valuable attack simply cannot be expressed. Voting weight is the product of a member's stake _and_ their earned, non-transferable participation tokens (minted one per vote and locked to the account), so a stack of governance tokens that just arrived — flash-borrowed or freshly bought — carries little to no weight until it has actually shown up over time, which capital cannot fake. Passing an executive proposal needs a **ranked-choice super-majority**, not a bare 50%, and execution only fires after a mandatory **delay window** following the vote's close. And because every member can always [exit](/wiki/governance/execution) for a treasury share sized by that same participation-weighted vote weight, even a captured vote cannot seize the value other members are entitled to redeem. The exact mechanics are verified against the caper contract and described on the linked [proposal](/wiki/governance/proposals) and [voting](/wiki/governance/voting) pages.

## DAO service providers

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-service-providers
Updated: 2026-08-07

| Topic | How a DAO procures, renews and terminates an outside firm that runs part of its operation |
| --- | --- |
| Three live models | Open programme with a selection committee ([ENS SPP3](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086)) · exclusive strategy mandate ([Entropy Advisors](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458)) · DAO-adjacent operating company ([Arbitrum OpCo](https://forum.arbitrum.foundation/t/opco-a-dao-adjacent-entity-for-strategy-execution/27361)) |
| The governance question | Not what it costs — that is [governance operating cost](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) — but who selects, on what rubric, and what happens at renewal |
| Recurring failure modes | Incumbency, exclusivity, information asymmetry, renewal-by-default, a committee negotiating privately when the published process is inconvenient |
| Related | [Contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation), [SubDAOs & working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups), [Delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs) |

## What a service provider is

A **DAO service provider** is an outside firm paid by a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) to run a defined part of its operation — indexing, treasury management, protocol engineering, growth, governance analytics. It is a distinct category from the two things it is usually confused with. A **grantee** is funded to build something of its own that the DAO would like to exist; a service provider is funded to deliver a service _to_ the DAO, and the DAO is the customer. A **contributor** is a person the DAO [compensates directly](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation); a service provider is a firm with its own payroll, its own other clients (or a contractual promise not to have any), and its own commercial interest in being renewed.

That last property is what makes this a governance topic rather than a procurement footnote. A DAO that buys operating capability from a firm has created a counterparty with a durable incentive to keep the engagement alive, more information about the DAO's operations than most delegates have, and — in the mature cases — a hand in designing the process by which its own renewal is decided. The published cost of these engagements is covered on [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs). This page is about the relationship: how the firm is chosen, on what terms it is held, and what actually happens when the DAO wants out.

## Model one: the open programme with a selection committee

ENS DAO's Service Provider Program is the most fully specified version of this model, and its third season is instructive because the DAO wrote down the rules before running the process. The [SPP3 authorization](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086) does four things in one vote: it authorizes a single cycle (renewal requires a new DAO vote, and the proposal states plainly that nothing in it commits the DAO to future seasons), it fixes the eligibility test (the primary deliverable must be a service to ENS; projects whose value accrues mostly elsewhere are ineligible), it names the committee that will execute the selection, and it caps the budget at **20% of trailing protocol revenue** rather than at a fixed number.

Splitting authorization from selection is the design choice worth copying. SPP3 requires two votes from delegates: one to approve the programme, budget and committee, and a second to ratify the cohort the committee returns with. The stated reason is that the earlier season made delegates rate and rank every applicant themselves, which the proposal describes as a structural problem rather than a one-off inconvenience. Delegates are asked to judge a _process and a panel_, which they can do, instead of twenty-six commercial proposals, which they cannot.

The [cohort recommendation](https://discuss.ens.domains/t/ep-6-49-spp3-cohort-recommendation/22237) shows the funnel that produced: 26 applications requesting a combined $12.2M against roughly $3.25M available; one disqualified at the eligibility gate; the remaining 25 scored against the published rubric with a structured interview for each qualifying team. The committee recommended four providers — Namespace ($500,000), Goldsky ($450,000), Unruggable ($400,000) and Fluidkey ($340,000), totalling $1,690,000 — and published its assessment of each, plus an aggregate explanation of why the rest were not funded. The committee's published per-criterion scores, and the question of what those numbers actually decided, are taken up on [scoring and review gates](/wiki/dao-governance/concepts/analysis/scoring-and-review-gates). One committee member recused from evaluating and voting on a provider under the programme's conflict-of-interest rules, which is the minimum viable form of the disclosure this model needs.

The mechanics of the call that produces a cohort — the rubric, the deadline, the probity rules, and what an open call surfaces when nobody answers it — are treated separately in [DAO procurement and requests for proposals](/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps).

## Model two: the exclusive mandate

Arbitrum DAO's arrangement with Entropy Advisors runs the opposite way: one firm, no cohort, and exclusivity written into the title of the [renewal proposal](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458). The firm was bootstrapped by an Arbitrum Foundation grant and works only for this DAO, which buys deep context at the price of having no comparator — there is no second bidder to price against and no obvious way to run a counterfactual.

What the DAO bought instead is an alignment and termination structure. The renewal's 15M ARB alignment allocation was revised mid-discussion into two parts: **5M ARB to the firm** on a one-year cliff and three-year vest, and **10M ARB reserved** for the oversight committee to negotiate against milestones, KPIs, equity or time-based bonuses rather than paid out on signature. The termination language was clarified in the same revision: if the DAO ends the relationship, all unearned ARB from that 10M returns to the treasury. Structurally this is the answer to exclusivity — if you cannot create competitive pressure at selection, create it at the vesting cliff.

A smaller DAO can reach the same place with a shorter clock instead of a vesting schedule. [Beefy](/wiki/daos/lending/beefy) engages a single firm, Staworth, on the same sole-provider basis, but the engagement runs six months and then stops: renewal is its own public proposal, priced line by line, and the firm has to publish what it shipped to win the vote. Neither device creates a rival bidder. Both create a moment at which the DAO can decline.

Note also what the revision says about who the firm answers to. Once the DAO's operating company is sufficiently operationalized, it becomes the firm's counterparty and client, acting as a proxy for the DAO. The DAO stops being the direct commercial counterparty to its own strategy firm — which is model three.

## Model three: the operating company as counterparty

The [OpCo proposal](https://forum.arbitrum.foundation/t/opco-a-dao-adjacent-entity-for-strategy-execution/27361) makes the DAO's procurement problem explicit before solving it: a DAO is structurally slow at evaluating and engaging specialised contributors, initiatives often have no clear owner, and when a service provider disengages there is frequently nobody accountable for continuity. OpCo is a DAO-adjacent legal entity that hires staff and negotiates with service providers on the DAO's behalf — an operational layer that exists so the DAO does not have to be a counterparty to every engagement it depends on.

The interesting part is the drawdown ladder, because it is a governance mechanism disguised as a finance control. The proposal earmarked 30M ARB (explicitly subject to change between the Snapshot and Tally votes) to cover the first 30 months, of which 4M ARB forms a vesting, performance-linked bonus pool for internal employees and the oversight committee, and most of the remainder is liquidated until $12M in cash equivalents is reached, with the leftover ARB returned to the treasury. Against that balance: $2.5M released upfront, then up to **$500K per month** drawn freely, **$500K–$1.5M** requiring the oversight committee's approval, and anything above **$1.5M** requiring a Snapshot vote of the DAO. The entity is fast by default and slow exactly where the amounts get large enough to matter — the same graduated-threshold logic that appears in [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and in [subDAO mandates](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups).

## The test is what happens when the process is inconvenient

Every procurement model looks sound in its authorizing proposal. The signal comes from the first time following it costs the DAO something. SPP3 supplies a clean instance. The committee's cohort originally had five selectees; the provider chosen for the marketplace and revenue vertical **declined its award**, leaving that vertical unfilled and **$1,560,284 of authorized budget uncommitted**.

The committee had an easy route available and said so publicly: go back to the applicants it had already scored and renegotiate scope privately. It [declined to](https://discuss.ens.domains/t/7-1-social-spp3-marketplace-rfp/22263), on the grounds that SPP3 ran under one published rubric and one deadline that every applicant had agreed to, and that operating outside those bounds would not be in the programme's interest. Instead it proposed an open, tightly scoped RFP for the unfilled vertical, funded from money the DAO had already authorized: a single award of up to $500,000, milestone-gated, with roughly half streamed through go-live and half released against traction gates verifiable on-chain, and the balance returned to the treasury.

Three properties are worth naming, because they are what a DAO should look for in any procurement it approves. The remedy asked for **no new money**. It did not delay the four ratified providers. And it converted an awkward vacancy into another run of the same public process rather than a private conversation among people who already had the DAO's confidence.

## Where it goes wrong

Note the contrast with the software a DAO depends on, which is bought with a company card rather than a proposal and therefore has none of this process attached: [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity).

- **Renewal by default.** The strongest single guard in the ENS model is that authorization expires: the programme is one cycle and a new season needs a new vote. Where an engagement rolls over unless someone objects, the burden of proof has quietly moved from the provider to the delegates — and the [participation levels](/wiki/dao-governance/concepts/analysis/voter-apathy) of most DAOs make that burden decisive.
- **Incumbency.** A returning provider has delivery history, relationships with the committee, and a scope written in the language the DAO now uses. Some of that is genuine earned advantage. It is very hard to tell how much from outside, which is why published rubrics and scores matter more than the identity of the winners.
- **Information asymmetry.** The firm running a DAO's data infrastructure knows the DAO's numbers better than the delegates voting on its renewal. Mandatory transparency reporting, and a foundation or committee entitled to request them, is the standard mitigation.
- **Exclusivity with no comparator.** Buying a firm's undivided attention removes the market test at selection. The mitigation is at the other end: long cliffs, milestone-gated tranches, and unearned tokens returning to the treasury on termination.
- **Capture of the process itself.** The failure worth guarding against is not overpayment; it is a provider whose advice shapes the mandate under which its own performance is later judged. Conflict-of-interest recusal, published rubrics, and separating the body that _writes_ the programme from the body that _wins_ it are the available defences. See [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) for the wider pattern.

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) has no service-provider layer, and that is a real answer rather than a gap being talked around. There is no delegate, steward, council or committee class anywhere in the contracts, and no streaming, vesting or recurring-payment primitive: a payment is a [proposal option](/wiki/governance/proposals) of the PAYOUT kind carrying a currency, an amount and a recipient account, and settlement of a passing proposal _is_ the transfer.

The consequence for this topic is narrow and specific. A multi-season engagement cannot be expressed as one on-chain object, so it decomposes into a sequence of discrete proposals, each of which has to win its own vote. There is nothing to roll over and nothing to claw back — the money simply stops unless the members affirmatively send the next tranche. Renewal-by-default, the first failure mode above, is not a policy a caper has to adopt; it is unavailable. And a provider that accumulated a large position could not simply outvote the members on its own renewal, because [vote weight](/wiki/governance/voting-mechanisms) multiplies holdings by an earned, non-transferable participation record, so a bag on its own carries no decisive weight. A member who disagrees with an engagement also has a second move beyond voting against it: a [standing exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) that returns their share of the treasury.

What Caper does not offer is a better selection process. There is no rubric, no committee, no RFP and no scoring — the DAOs above built those because choosing well among 26 applicants is a hard problem, and nothing in a shorter leash solves it. The honest summary is that Caper makes engagements easy to stop and offers nothing at all for making them easy to choose.

## References

- [[6.42] [Social] SPP3: Program Authorization and Committee Model](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086) — discuss.ens.domains, 25 April 2026. One-cycle authorization, the eligibility test, the named committee, and the 20%-of-trailing-revenue budget cap.
- [[EP 6.49] SPP3: Cohort Recommendation](https://discuss.ens.domains/t/ep-6-49-spp3-cohort-recommendation/22237) — discuss.ens.domains, 3 July 2026. The 26-application funnel, the rubric and interviews, the four-provider $1,690,000 cohort, and the conflict-of-interest recusal.
- [[7.1] [Social] SPP3: Marketplace RFP](https://discuss.ens.domains/t/7-1-social-spp3-marketplace-rfp/22263) — discuss.ens.domains, 9 July 2026. The declined award, the $1,560,284 uncommitted, and the decision to re-tender publicly rather than renegotiate privately.
- [Entropy Advisors: Exclusively Working with the Arbitrum DAO, Y2-Y3](https://forum.arbitrum.foundation/t/entropy-advisors-exclusively-working-with-the-arbitrum-dao-y2-y3/29458) — forum.arbitrum.foundation, 17 June 2025, revised 7 July 2025. The 5M/10M ARB alignment split, the termination clause, and OpCo as counterparty.
- [OpCo – A DAO-adjacent Entity for Strategy Execution](https://forum.arbitrum.foundation/t/opco-a-dao-adjacent-entity-for-strategy-execution/27361) — forum.arbitrum.foundation, 30 October 2024. The procurement rationale, the 30M ARB earmark and bonus pool, and the drawdown thresholds.

## DAO tooling discontinuity

URL: https://caper.network/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | What happens to a DAO when a tool in its governance stack shuts down, is parked, or pivots away |
| **Also called** | Vendor discontinuity, front-end risk, tooling rot, orphaned infrastructure |
| **Applies to** | Any [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) whose decisions, records or permissions pass through third-party software |
| **Failure classes** | Dead interface (recoverable) · dead hosted record (lossy) · live contract with a dead maintainer (dangerous) |
| **Related** | [The DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) · [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers) · [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) · [The machine-readable DAO](/wiki/dao-governance/concepts/analysis/machine-readable-dao) |
| **Cohort checked** | 5 August 2026 (method and results below) |

A DAO's constitution is its contracts, but its _working life_ runs on software somebody else operates: a voting front end, a forum, a member workspace, a payments app, a badge issuer, an analytics dashboard. Those tools are chosen once, wired into the way the organization actually works, and then almost never revisited. **DAO tooling discontinuity** is what happens when one of them stops existing.

The industry treats this as an operational annoyance. It is closer to a governance problem, for three reasons this page works through: the damage depends entirely on _what the tool was holding_, not on how important it felt; the signals people use to check whether a tool is still alive are unreliable in specific and predictable ways; and unlike a [service provider](/wiki/dao-governance/concepts/analysis/dao-service-providers), a SaaS dependency is usually adopted below the threshold that would ever put it to a vote, so when it fails there is no owner and no process.

## A measured cohort

Between February and August 2026 this wiki kept a queue of DAO tooling products it intended to write up. Each was, at the time it was added, a going concern with a product site and users. On 5 August 2026 all seven were checked directly before any page was written. Six were gone, parked, or no longer in the category.

| Tool | What it did | State on 5 Aug 2026 |
| --- | --- | --- |
| [Llama](/wiki/dao-governance/tooling/frameworks/llama) | Treasury and governance framework | Gone. `llama.xyz` returns no DNS A record at all, and [llamaxyz/llama](https://github.com/llamaxyz/llama) is flagged archived with its last push on 16 August 2024. |
| Otterspace | Non-transferable membership badges | Gone. `otterspace.xyz` still resolves to Netlify addresses but the TLS handshake fails, and the [otterspace-xyz](https://github.com/otterspace-xyz) contracts repository is a 404. |
| Utopia Labs | DAO payments and payroll | Holding page. `utopialabs.com` answers 200 with a 734-byte document: a title, a webfont link, and an empty root element. |
| CharmVerse | DAO workspace, proposals and roles | Product gone. `charmverse.io` now serves a domain-parking lander, `app.charmverse.io` has no DNS A record, and [the repository](https://github.com/charmverse/app.charmverse.io) is _not_ archived, last pushed 18 October 2025. |
| Syndicate | Investment-club framework | Pivoted out of the category. [syndicate.io](https://syndicate.io/) now sells "the infrastructure to infinitely scale Ethereum" and lists an exchange-traded token. The investment-club product is not part of it. |
| Metropolis (ex-Orca Protocol) | Membership pods over a Safe | Unidentifiable. `metropolis.space` answers 200 with an empty JavaScript shell and the contracts repository path 404s. |
| Den | [Multisig operations over Safe](/wiki/dao-governance/tooling/treasury/den) | Alive at `onchainden.com`. Note that `den.xyz`, the domain people assume, is parked for sale and is a different thing. |

Treat that as one dated observation, not a survival rate: it is a convenience sample of seven, assembled because the tools looked notable, and notability is correlated with having raised money in a particular window. What it does establish is the shape of the risk. These are not obscure projects, the window is short, and none of the six announced anything to the DAOs still depending on them. The disappearance was discovered by `dig`, not by an email.

## Classify by what the tool holds, not by what it does

The useful question is not how important a tool feels but what would be irretrievable if it vanished overnight. Three classes behave completely differently.

**A dead interface is recoverable.** When a tool is a _view_ over state that lives on-chain, its death costs convenience and nothing else: the proposals, votes and balances are still there, and anyone can read the contract or build another front end. [Tally's 2026 wind-down](/wiki/dao-governance/tooling/voting/tally) is the worked example, and the reason it was survivable is precisely that the Governor contracts it fronted never stopped working.

**A dead hosted record is lossy, and the loss is the reasoning.** Workspaces, forums, and payment apps hold the material that never had an on-chain shadow: the draft that became a proposal, the objection that changed it, who held which role in which month, what an invoice was for. When CharmVerse's application host stopped resolving, that class of material went with it. A DAO in this position keeps its money and its contracts and loses its memory, which is the half that made the money legible. The same boundary shows up even in healthy tools: Den adds no contracts to Safe, so the human-readable description a signer reads sits on Den's servers next to a payload that is immutable on-chain.

**A live contract with a dead maintainer is the dangerous one.** Deployed contracts do not shut down. An [unmaintained module](/wiki/dao-governance/tooling/frameworks/zodiac) that still holds a role on a [treasury Safe](/wiki/dao-governance/tooling/treasury/safe), a badge contract that still gates membership, a streaming contract that still holds a balance: all of these keep executing exactly as deployed, which is the problem. Nobody ships the fix, nobody answers the disclosure email, and the standing permission outlives the company that asked for it. A dead front end is an inconvenience. A live privileged contract with nobody behind it is an open item on the [attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

## The signals that lie

Every check people reach for first is unreliable, and the failures are systematic rather than random.

- **An HTTP 200 from the marketing domain proves nothing.** Both `charmverse.io` and `utopialabs.com` answered 200 while the product behind them was gone: one serves a parking lander, the other a 734-byte shell. Domains outlive products because renewing a domain is cheap and shutting one down is a decision nobody gets around to making.
- **Probe the application host, not the homepage.** The strongest single signal in this cohort was a missing DNS A record on the _app_ subdomain. Nobody pays to keep an application host resolving by accident.
- **An archived repository is an honest signal; an unarchived one is not a signal at all.** Llama's team set the archive flag, which is a courtesy. CharmVerse's repository is not archived and its app host does not resolve. The flag tells you something when it is set and nothing when it is absent.
- **A traded token is not a living product.** Syndicate's token has exchange listings and its company is clearly operating. The thing a DAO wanted from it no longer exists.
- **Recent commits are weak evidence either way.** CharmVerse's last push was ten months before its app went dark. Maintenance stops well before the lights do.

The check that actually works takes about a minute per tool and needs no API key: resolve the application host (`dig +short app.example.com A`), fetch it while watching the response size as well as the status code (a 734-byte page is not a product), and read `pushed_at` and `archived` from `api.github.com/repos//`. Run it against your own stack before you need the answer.

## Why nobody owns the dependency

DAOs have built real process around money. A [service provider](/wiki/dao-governance/concepts/analysis/dao-service-providers) is selected through a scored public process, funded by a proposal, and renewed by another one. Delegate payrolls and [governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) appear as budget lines that somebody argues about every season.

Tooling almost never gets there. It is adopted by a contributor with a company card, at a price too small to reach a proposal threshold, and it becomes load-bearing through use rather than through a decision. The result is an inversion: the dependencies with the most governance process attached are the ones the DAO could most easily replace, and the ones holding its actual working record have no proposal, no renewal date, no termination clause, and no named owner. When they fail, the failure surfaces as a support ticket that nobody can file.

This is also why discontinuity rarely appears in post-mortems. It produces no vote to point at and no on-chain event to timestamp, so it leaves the same kind of no-trace gap as the [decisions that never became proposals](/wiki/dao-governance/concepts/voting/proposal-lifecycle).

## What actually reduces the exposure

- **Keep the binding state on-chain and treat every interface as replaceable.** This is the whole reason Tally's wind-down was survivable and CharmVerse's was not. If losing a vendor would lose a decision, the decision was never really on-chain.
- **Export the record on a schedule.** Forum threads, proposal rationales, role histories. The export is worthless as a habit if it starts after the announcement, and there is usually no announcement.
- **Revoke permissions from tools you have stopped using.** Deprecation in a DAO tends to mean "we stopped opening it", which leaves the role, the module and the allowance exactly where they were. Auditing standing permissions against tools actually in use is the cheapest item on this list.
- **Understand the trade in "no extra contracts".** A tool that deploys nothing (Den over Safe) leaves no orphaned privileged code when it dies, but takes its off-chain record with it. A tool that deploys contracts ([Hats](/wiki/dao-governance/tooling/membership/hats-protocol), [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac)) leaves durable state you can still read, and durable permissions you must remember to remove. Neither is the safe option in general; they fail in opposite directions.
- **Check before you depend, and again on a cadence.** The cohort above is what a queue looks like six months after it was assembled by people paying attention.

The wider pattern is visible across the tooling this wiki already covers: [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) dissolved its association and refocused on a product, [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) sunset its app, [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) deprecated a major interface, and [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) has had to say out loud that it has no plan to deprecate. Discontinuity is the normal condition of this layer, not an exception in it.

## How Caper approaches this

_Verified against the Caper contract source, not aspirational._

A [caper](/wiki/foundations/what-is-a-caper) keeps the material that the hosted-record failure class destroys inside its own component state on the Radix ledger. Proposals, their options, the per-proposal ballots, and the proposal's title and description payload are all stored in key-value stores on the caper's state component (`contracts/core/src/caper_dao.rs`), and the reads are public methods on that component: `read_proposal`, `read_proposal_meta`, `read_ballots` and `read_winner`. There is no vendor database holding the reasoning beside a payload, because the description travels in the same state as the [proposal](/wiki/governance/proposals) and the [ballots](/wiki/governance/voting).

The contract is also split along this exact seam. The state tier is described in its own source as immortal, deployed once per caper and never migrated, and it deliberately holds no business logic; the curve math, the tally and the vote-weight formula live in a separate, swappable logic package that drives it. So replacing Caper's own logic does not move the record either. On the permissions side, every method that moves treasury assets is restricted to a single admin badge, and there is no module surface for a third-party tool to hold a standing role, which removes the orphaned-privileged-contract class rather than mitigating it.

The honest limit: this is about the record, not the interface. `caper.network` is a front end like any other and enjoys no special immunity. What the design buys is that a reader who loses the front end can still get the proposals, the ballots and the outcomes off the ledger. That is the same property that made Tally's wind-down survivable, applied to the half of the record that most DAOs keep somewhere else.

## References

- [llamaxyz/llama](https://github.com/llamaxyz/llama) — archived repository, last push 16 August 2024.
- [charmverse/app.charmverse.io](https://github.com/charmverse/app.charmverse.io) — unarchived repository, last push 18 October 2025, product host no longer resolving.
- [otterspace-xyz](https://github.com/otterspace-xyz) — GitHub organization; the contracts repository referenced by the product no longer exists.
- [syndicate.io](https://syndicate.io/) — current product positioning after the pivot away from investment-club infrastructure.
- [Den documentation](https://docs.onchainden.com/overview/den) — the surviving tool in the cohort, and the clearest statement of where an off-chain description sits relative to an on-chain payload.
- Caper contract source: `contracts/core/src/caper_dao.rs` (state tier, proposal and ballot storage, public reads) and `contracts/core/src/dao_treasury.rs` (admin-gated treasury methods).

## Delegate incentive programs

URL: https://caper.network/wiki/dao-governance/concepts/analysis/delegate-incentive-programs
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | What DAOs pay delegates for, in what currency, and what the published results show they got |
| **Three currencies** | Cash per vote ([Arbitrum](https://forum.arbitrum.foundation/) RAD) · seats and roles ([Optimism](https://gov.optimism.io/) councils) · delegated weight ([Uniswap UADP](https://gov.uniswap.org/t/uniswap-arbitrum-delegate-program-uadp-communication-thread/22185), the [ENS 5M draft](https://discuss.ens.domains/t/draft-reform-dao-governance-by-delegating-5m-ens-tokens/22247)) |
| **The denomination problem** | RAD budgets are set in USD and paid in ARB; ARB fell from ~$0.21 to ~$0.077, so the same payroll drew two to three times more ARB and the [July 2026 review](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) cut USD budgets 28–40% |
| **The audit problem** | April 2026’s corrected RAD report left the headline participation figure at **64.71%** unchanged while rewards owed rose from **$14,500 to $20,000** ([post-mortem](https://forum.arbitrum.foundation/t/rewarding-active-delegates-april-2026-results-correction-post-mortem/30906)) |
| **What it does not buy** | Retention: Blockworks, “the second biggest delegate in Arbitrum,” [wound down its delegate role](https://forum.arbitrum.foundation/t/blockworks-delegate-activities-wind-down-arbitrum/30932) in June 2026 while the program ran |
| **Caper’s position** | No delegation primitive, and participation is paid _in_ rather than out: a ballot costs an XRD fee that lands in the caper’s own treasury (verified in `contracts/logic/src/lib.rs`) |

A **delegate incentive program** is a standing budget a DAO votes to itself for the purpose of getting its own delegates to show up. It is one of the few governance interventions that shows up as a line item, which makes it unusually legible: unlike quorum design or ballot format, a delegate incentive program has a price, a payroll, and — in the better-run cases — a published monthly ledger naming who was paid and who was not.

This page is about those programs as _spending_. The neighbouring question — whether delegated weight should expire when a delegate goes quiet — is covered on [delegate accountability and dormant delegates](/wiki/dao-governance/concepts/voting/delegate-accountability), and the supply-side arithmetic these programs sit on top of is on [voting power activation](/wiki/dao-governance/concepts/voting/voting-power-activation). What follows is the money: what the three live designs actually purchase, what their own reports say they got, and the two failure modes the published data exposes.

The delegate payroll is also only one line in a DAO’s governance budget, and usually not the largest. What the councils, stewards, operating companies and service providers around it cost, and why those figures rarely compare across DAOs, is on [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs).

## Three currencies, not one

“Paying delegates” describes three structurally different transactions, and conflating them is the most common error in the discourse around them.

**Cash per vote.** The DAO sets a budget per proposal, splits it among delegates who met a participation bar, and pays in its own token at a fixed dollar value. This is the [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao)’s Rewarding Active Delegates (RAD) design. What is bought is attendance on a specific list of votes.

**Seats and roles.** The DAO funds councils, boards and committees with per-seat stipends, and the delegate incentive is a job rather than a per-vote rate. This is how the [Optimism Collective](/wiki/daos/networks/optimism-collective) spends the bulk of its governance budget. What is bought is a person’s ongoing attention to one domain.

**Delegated weight.** The DAO — or another DAO holding its token — pays nothing at all, and instead routes voting power to chosen delegates. What is bought is influence for the recipient and, the payer hopes, competence for the electorate. [Uniswap DAO](/wiki/daos/dexs/uniswap-dao)’s Arbitrum delegate program and the July 2026 ENS draft below are both of this kind.

The three have different failure modes, and only the first has a real budget line. That asymmetry matters: the programs that are easiest to criticise are the ones whose costs are visible.

## Paying per vote: what the RAD price list looks like

Arbitrum’s RAD program prices participation by proposal category, with a pot per proposal and a cap per delegate. The [quarterly budget review published on 1 July 2026](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) states both the old and the new schedule, effective for proposals starting in July:

|  |  |  |
| --- | --- | --- |
| **Proposal category** | **Budget (old → new)** | **Per-delegate cap (old → new)** |
| On-chain constitutional quorum | $15,000 → $10,000 | $700 → $550 |
| On-chain non-constitutional quorum | $7,000 → $5,000 | $500 → $400 |
| Off-chain decision-making (non-constitutional) | $7,000 → $5,000 | $500 → $400 |
| Off-chain election | $7,000 → $5,000 | $500 → $400 |
| Off-chain temperature check (non-binding) | $5,000 → $3,000 | $300 → $250 |

Two properties of this design are worth naming. First, the DAO’s governance payroll is a function of _how many proposals it runs_, not of how hard the decisions were: a quiet month is cheap and a busy month is expensive regardless of what was at stake. Second, the eligibility bar moves with the workload rather than being fixed — the [June 2026 results](https://forum.arbitrum.foundation/t/rewarding-active-delegates-june-2026-results/31046) state that four or fewer proposals in a month sets the participation threshold at 50% and five or more sets it at 75%, and a missing vote rationale trims a delegate’s payout by 10%.

## The denomination problem: fiat budgets, token payouts

RAD budgets are denominated in US dollars and paid in ARB. The July 2026 review is explicit about what that did. When the program began ARB traded around $0.21; at the time of the review it sat near $0.077, a fall of roughly 65%. Because the dollar budget per vote never changed, “each vote has been drawing two to three times more ARB from the treasury than it did at launch, even though the dollar value delegates receive is the same.”

The program’s own figures make the drift concrete: an on-chain constitutional vote had cost ~131,300 ARB per proposal on average across the program’s history, but ~200,000 ARB at the old budget and the prevailing ~$0.075 price; the new $10,000 budget brings it back to ~133,300 ARB, close to the historical norm.

The general result is that a governance payroll set in fiat and paid in the governance token is **procyclical against the treasury**. The token cost of the same nominal participation rises exactly as the token falls — that is, the DAO spends the most tokens precisely when its treasury is worth the least and its runway is shortest. Every DAO paying contributors in its own token at a dollar rate carries this exposure; delegate programs simply make it easy to see, because the ledger is public and monthly. Note also who absorbed the correction: Arbitrum restored the ARB spend by cutting the delegates’ dollar income 28–40%, so the price risk was ultimately borne by the delegates, not by the treasury that had been over-spending in token terms.

## The audit problem: a participation percentage is not a payroll check

In May 2026 the RAD program published a [correction and post-mortem](https://forum.arbitrum.foundation/t/rewarding-active-delegates-april-2026-results-correction-post-mortem/30906) for its April report, and it is the most instructive artefact any of these programs has produced. A bug in the monthly automation that lists Snapshot proposals closing in the reporting month silently dropped one of them — the vote on updating the Code of Conduct and DAO Procedures. The first report was therefore built from three votes rather than four.

What changed and what did not is the point. The corrected build used the same 34 enrolled delegates and produced the _same_ headline figure: 88 “Yes” votes over 136 slots (34 delegates × 4 proposals) is 64.71% program participation, exactly the number the flawed three-vote report had published. But the budget envelope moved from an implied $17,000 to $24,000, and rewards owed moved from $14,500 to $20,000 — $5,500 more than had been paid out on 5 May.

The reason is structural rather than accidental: participation is a _ratio_, so it is invariant to the number of proposals in the denominator, while the payroll is _per proposal_, so it is not. A published participation rate can therefore be perfectly correct while the payment ledger built from the same dataset is materially wrong. Any DAO that treats a participation dashboard as evidence that its delegate payroll reconciles has confused a normalised metric for an audit. The RAD program’s own bi-annual [transparency reporting](https://forum.arbitrum.foundation/t/rad-bi-annual-transparency-report-june-2026/30964) is what surfaced the delta at all.

### Thresholds are only as fine as the proposal count

The same post-mortem exposes a second, subtler property. With four proposals in scope, a delegate’s monthly participation can only take five values — 0%, 25%, 50%, 75% or 100% — and in April’s corrected data the observed distribution was 19 delegates at 100%, six at 50%, nine at 0%, and **zero at 75%**. A rule written as “at least 75% participation” is therefore not a fixed standard: on a four-vote month it is operationally a demand for a perfect record, while on a twelve-vote month it forgives three misses. The strictness of the rule changes month to month, without anyone proposing an amendment, purely as a function of how many proposals the DAO happened to run. This is the same granularity trap that afflicts percentage quorums on small electorates, discussed on [quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design).

## Paying for seats instead of votes: Optimism

The Optimism Collective spends on governance differently. Its Token House funds councils and boards with operating budgets rather than paying a rate per vote, and its delegate-facing incentive is retroactive: the Anticapture Commission has no operating budget at all, but active participation there — the threshold cited is voting on at least 50% — may count toward Retro Governance rewards.

A [Season 7 participation and incentives report](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) compiled by the delegate-research team SEEDGov puts Token House governance operating costs at 1,055k OP, up 38% from 762k OP in Season 6. The report is careful about why, and the caveat is worth carrying: part of the rise is that the Security Council’s 295k OP budget became a public Token House line for the first time, having previously sat inside Foundation expenses. A governance-cost series can jump because spending rose or because disclosure improved, and only the underlying report distinguishes the two — which is a standing reason to be sceptical of cross-season DAO cost comparisons quoted without their source.

On what the spend bought, the same report finds average turnout among the top 100 delegates at 49 of 100 per vote, up 6.8% on Season 6, alongside 22% fewer vote rationales and 25% less forum feedback than the previous season. Its own summary of the pattern is that voting happens and discussion does not. That is the recurring hazard of paying against an observable: attendance is measurable and cheap to satisfy, deliberation is neither, so a program that prices the first without pricing the second can raise turnout and lower the quality of the argument at the same time.

## Paying in weight instead of money

The third design spends no treasury cash. In October 2023, after Arbitrum’s ecosystem airdrop sent Uniswap a little over 4 million ARB, Uniswap governance voted to route part of that allocation through a [Uniswap-Arbitrum Delegate Program](https://gov.uniswap.org/t/uniswap-arbitrum-delegate-program-uadp-communication-thread/22185) rather than sell or idle it — described by its facilitators as “the Uniswap community’s unique entrance into metagovernance.” The delegation facilitators publish per-vote rationale on [both DAOs’ forums](https://forum.arbitrum.foundation/t/uniswap-arbitrum-delegate-program-uadp-communication-thread/19225) and disclose conflicts where their own organisations hold separate Arbitrum delegations. The compensation here is influence, and the payer is a different DAO than the one being governed.

ENS is the case where paying cash was tried first and reported as insufficient. A [July 2026 draft proposal](https://discuss.ens.domains/t/draft-reform-dao-governance-by-delegating-5m-ens-tokens/22247) by ENS contributor Alex Van de Sande argues that delegated votes and turnout in [ENS DAO](/wiki/daos/infrastructure/ens-dao) have both been falling, and lists what has already been attempted: making redelegation free, distributing more ENS to new contributors, and “paying users to stake and delegate their ENS.” His assessment is that these “have had some mild successes” but “clearly have not been able to reverse the overall trend.” The draft’s alternative is to stop paying for delegation and start allocating it — delegating 5M ENS from the DAO’s own majority holding to named stakeholder classes. It is a draft rather than policy, and should be read as one, but it is a rare on-the-record verdict from inside a major DAO on whether cash incentives fixed its delegation decay.

## What the money does not buy

The strongest evidence on the limits of these programs comes from Arbitrum, which runs the best-documented one. On 1 June 2026, the research firm Blockworks — by its own description “the second biggest delegate in Arbitrum” and a contributor of research through the ARDC on incentive-program design, STIP and LTIPP performance, sequencer revenue and Timeboost — [announced it was winding down its active delegate role](https://forum.arbitrum.foundation/t/blockworks-delegate-activities-wind-down-arbitrum/30932). The stated reason was alignment with the firm’s own business goals, not dissatisfaction with the DAO, and the post encourages delegators to redelegate to contributors with the bandwidth to participate consistently.

A per-vote incentive is priced against the marginal cost of casting a vote. It is not priced against the opportunity cost of a research firm’s entire governance practice, and it cannot be: no plausible per-proposal cap competes with a business decision of that size. So the honest summary of what these programs achieve is narrow but real — they raise measured attendance among delegates who have already decided to be there, they make absence a published number rather than private knowledge, and they do not retain the largest professional delegates when the economics of those delegates change. On the general question of whether paying for turnout addresses the underlying condition, see [voter apathy and governance participation](/wiki/dao-governance/concepts/analysis/voter-apathy); on delegate pay as one category of DAO payroll among several, see [contributor compensation in DAOs](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation).

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no delegate to pay. Searching the three contract crates for any delegation primitive returns nothing — there is no `delegate` entry point, no delegated-supply figure, and therefore no professional delegate class for a budget to subsidise or retain.

Participation is also priced in the opposite direction. [Voting](/wiki/governance/voting) is a paid-in act, not a paid-out one: `vote()` in `contracts/logic/src/lib.rs` requires an XRD payment exactly equal to the caper’s configured vote fee, and that payment is deposited into the caper’s own treasury — including on the path where the ballot arrives outside the voting window and is rejected, where the fee is deposited and the call simply returns false. Every ballot is a transfer from the voter to the treasury the vote governs. See [proposals](/wiki/governance/proposals) for the full fee schedule.

What replaces the stipend is the exit claim. `exit()` asserts that the member holds _both_ vote tokens and governance tokens before it will compute anything, and then pays the same weight the ballot carried — `(t × v) / (V × T)`, the member’s token balance times their vote-token balance, over the vote-token supply times the token’s circulation. A member who never voted has no participation-weighted claim on the treasury at all. So the reward for showing up is retroactive, funded by the same treasury the votes decide, and proportional to a record the member paid to build — rather than a monthly payroll that has to be budgeted, priced in a falling token, and reconciled.

The cost of that design should be stated plainly. There is no way for a caper to fund a full-time analyst to read its proposals, no way for a member short of XRD to have their fee subsidised, and no way to lend voting weight to someone with more time. Caper trades the professional delegate layer away entirely rather than trying to pay for it well.

## References

- [Arbitrum forum – RAD Budget, Quarterly Review (2Q2026)](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) (the old and new per-category budgets and caps; the ARB $0.21 → $0.077 repricing rationale and per-proposal ARB tables)
- [Arbitrum forum – Rewarding Active Delegates, April 2026 Results: Correction & Post-Mortem](https://forum.arbitrum.foundation/t/rewarding-active-delegates-april-2026-results-correction-post-mortem/30906) (the missing Snapshot vote; 34 delegates, 88/136 = 64.71%; $14,500 → $20,000; the 19/6/9/0 participation distribution)
- [Arbitrum forum – Rewarding Active Delegates, June 2026 Results](https://forum.arbitrum.foundation/t/rewarding-active-delegates-june-2026-results/31046) (the 50%/75% threshold rule and the 10% rationale trim)
- [Arbitrum forum – RAD Bi-annual Transparency Report, June 2026](https://forum.arbitrum.foundation/t/rad-bi-annual-transparency-report-june-2026/30964)
- [Arbitrum forum – Blockworks’ Delegate Activities Wind Down](https://forum.arbitrum.foundation/t/blockworks-delegate-activities-wind-down-arbitrum/30932) (1 June 2026)
- [Optimism forum – Token House participation and incentives: Season 7](https://gov.optimism.io/t/token-house-participation-and-incentives-season-7-cycle-31a-38/10297) (SEEDGov; 1,055k OP vs 762k OP, the 295k OP Security Council disclosure, 49/100 average voters, −22% rationales / −25% feedback)
- [Uniswap governance – Uniswap-Arbitrum Delegate Program communication thread](https://gov.uniswap.org/t/uniswap-arbitrum-delegate-program-uadp-communication-thread/22185) and its [Arbitrum-side mirror](https://forum.arbitrum.foundation/t/uniswap-arbitrum-delegate-program-uadp-communication-thread/19225)
- [ENS forum – [Draft] Reform DAO governance by delegating 5M ENS tokens](https://discuss.ens.domains/t/draft-reform-dao-governance-by-delegating-5m-ens-tokens/22247) (6 July 2026; the assessment of paid stake-and-delegate)

## EIP-4824: Common Interfaces for DAOs

URL: https://caper.network/wiki/dao-governance/concepts/analysis/eip-4824
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Standard** | EIP-4824 / ERC-4824, "Common Interfaces for DAOs" |
| **Also known as** | DAOIP-2; the daoURI standard |
| **Type** | Standards Track – ERC (Interface); requires [ERC-165](https://eips.ethereum.org/EIPS/eip-165) |
| **Status** | **Review** – peer review, not Final, as of August 2026 ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-4824)) |
| **Authors** | Joshua Tan, Isaac Patka, Ido Gershtein, Eyal Eithcowich, Michael Zargham, Sam Furter |
| **Created** | 17 February 2022 |
| **Maintained by** | [DAOstar](/wiki/dao-governance/tooling/analytics/daostar) (DAOstar One, with support from [Metagov](https://metagov.org/)) |
| **Core idea** | One on-chain function, `daoURI()`, links a DAO to a structured document describing its members, proposals, activity, governance, and contracts |
| **Registrations observed** | 30 across the four production index deployments; most recent 22 February 2025 (see _What the registry actually contains_) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) · [DAO metrics and analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) · [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) · [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) · [The machine-readable DAO](/wiki/dao-governance/concepts/analysis/machine-readable-dao) |

**EIP-4824**, titled _Common Interfaces for DAOs_ and published on Ethereum as ERC-4824, is a standard that gives any decentralized autonomous organization a single, tool-agnostic way to describe itself. It defines one on-chain function, `daoURI()`, that returns a link to a structured document listing the DAO's members, proposals, activity, governance, and associated contracts. It is the DAO analogue of the [`tokenURI`](https://eips.ethereum.org/EIPS/eip-721) that lets any wallet read an NFT without knowing which contract minted it.

The standard makes a deliberate distinction: it does not standardize DAOs, only the _data about_ them. A proposal created in one framework becomes readable by an indexer, a voting front-end, or a rival tool built by someone who has never seen the original contract. EIP-4824 was authored through [DAOstar](/wiki/dao-governance/tooling/analytics/daostar), the standards body for DAOs, and is the founding member of that group's DAOIP series, where it carries the number DAOIP-2.

It has never been finalised. Four and a half years after it was created, the specification still carries the status **Review** – "in the process of being peer-reviewed" – and the canonical citation string Ethereum generates for it reads _ERC-4824: Common Interfaces for DAOs [REVIEW]_. The rest of this page treats that as the starting question rather than a footnote: the design is well made and the argument for it is sound, so what happened when it met the ledger?

## The interoperability problem

DAOs multiplied faster than any agreement on how to represent them. A [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) DAO, a Compound-style Governor, a [Moloch](/wiki/daos/public-goods/molochdao) guild, and a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig each store membership and proposals in incompatible ways – some keep an explicit on-chain member list, others derive membership from token balances, and many run their votes [off-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) entirely. A tool that wants to read across this landscape has to hand-write an adapter for every framework it supports.

The EIP's [motivation](https://eips.ethereum.org/EIPS/eip-4824) is that this fragmentation blocks the things a maturing ecosystem needs: discoverability of DAOs, legibility of their governance, simulation of proposals before they execute, and portability of members and history between tools. A shared data format is treated as a prerequisite for future DAO standards, the way `tokenURI` and `ERC-165` interface detection became prerequisites for the NFT tooling that followed. Rather than force every DAO onto one governance model, EIP-4824 asks only that each one publish a description a machine can read.

## The daoURI interface

The on-chain surface is intentionally tiny. A compliant contract implements a single interface, and signals that it does so through [ERC-165](https://eips.ethereum.org/EIPS/eip-165) interface detection:

```
interface IERC4824 {
    event DAOURIUpdate(address daoAddress, string daoURI);

    function daoURI() external view returns (string memory _daoURI);
}
```

The `daoURI()` function returns a URI – typically an HTTP, IPFS, or data URI – pointing at the DAO's description document. Its selector is `0x7034731b`, which makes conformance a one-call test against any address: a contract that implements the interface answers, and one that does not reverts. The `DAOURIUpdate` event lets indexers track changes without polling. The EIP recommends that contracts implement access control around updating the URI, so that changes follow the DAO's own governance rather than an arbitrary key, and that any field with no value be omitted rather than left empty or null. A DAO may implement `IERC4824` directly in its governance contract or delegate it to an external registration contract, which lets already-deployed DAOs adopt the standard without migrating.

## The DAO description document

The URI dereferences to a [JSON-LD](https://www.w3.org/TR/json-ld11/) object. At the top level it names the DAO and points to five subsidiary documents:

```
{
  "@context": "http://www.daostar.org/schemas",
  "type": "DAO",
  "name": "",
  "description": "",
  "membersURI": "",
  "proposalsURI": "",
  "activityLogURI": "",
  "governanceURI": "",
  "contractsURI": ""
}
```

That `@context` line is reproduced exactly as the specification writes it, and it is worth noticing that the specification does not write it consistently: the top-level DAO example uses `http://www.daostar.org/schemas` while every subsidiary schema in the same document – members, proposals, activity log, contracts – uses `https://www.daostar.org/schemas`, and the clause governing appended-URI fields makes the `https` form a _MUST_. The consequence shows up in the published corpus, discussed below.

Each subsidiary document may be linked by URI or embedded inline by dropping the `URI` suffix (writing `members` instead of `membersURI`), so a small DAO can ship everything in one file while a large one splits its data across services. The four data documents each describe one facet of the organization:

- **Members.** An array of member objects, each identified by a [CAIP-10](https://chainagnostic.org/CAIPs/caip-10) account (for example `eip155:1:0x…`), a Decentralized Identifier (`did:…`), or another URI. The URI-and-DID design is the reason the EIP chose JSON-LD over plain JSON: it accommodates members that are not Ethereum addresses and DAOs that span multiple chains.
- **Proposals.** An array of proposals, each with an `id`, `name`, a `contentURI` and `discussionURI` pointing at the text and the debate, a free-text `status`, and a list of `calls` describing the on-chain actions the proposal would execute. On-chain proposals use a canonical id of the form `CAIP-10 address + "?proposalId=" + counter`. The status is free text on purpose, because [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), Compound, DAOstack, Moloch, and Colony all enumerate proposal states differently.
- **Activity log.** An array of activities, each relating a member to a proposal – a creation, a vote, a dispute – so that the history of who did what can be reconstructed.
- **Contracts.** Every contract associated with the DAO, each with an id, name, and description. Publishing the full set lets an indexer audit a multi-contract or cross-chain DAO and, as the security section notes, guards against spoofing.

The `governanceURI` is deliberately looser: the EIP recommends a plain-text or Markdown file describing the DAO's rules and the rights its members hold – voting power, [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), veto powers – rather than an attempt to encode governance itself, which it considers too varied and too often off-chain to standardize.

## Publishing and indexing

DAOstar defines three ways a `daoURI` can reach an indexer. A DAO can inherit `IERC4824` directly in its governance contract; it can register through a factory or registration contract; or a trusted service provider can report it on the DAO's behalf through an attestation, following the companion standard DAOIP-3. The first two paths are covered by EIP-4824 itself (DAOIP-2); the third lets DAOs that will never upgrade their contracts still become discoverable.

To make registration observable, the EIP specifies an index contract that emits a `DAOURIRegistered` event. Permissionless registration checks that the target actually implements the interface before logging it:

```
function logRegistration(address daoAddress) external {
    if (!daoAddress.supportsInterface(type(IERC4824).interfaceId))
        revert ERC4824InterfaceNotSupported();
    emit DAOURIRegistered(daoAddress);
}
```

When the same DAO is registered more than once, the most recent registration and those published through a factory take precedence, giving indexers a deterministic rule for resolving duplicates. That event is also what makes the standard auditable from outside: because registration is deliberately observable, anyone can count it.

## Design choices, compatibility, and security

The standard's central bet is to push complexity off-chain. On-chain proposal formats were judged premature given emerging patterns such as multi-DAO and "master–minion" proposals, and because proposal systems are tightly coupled to governance systems that vary widely. Storing the rich data behind URIs keeps the on-chain footprint to one function and makes adoption as easy as `tokenURI` was for NFTs, at the cost of trusting whatever service the URI points at to stay available and honest.

Because it adds rather than changes behavior, EIP-4824 is fully backward compatible: contracts that do not adopt it are unaffected, and those that do can adopt through an external registration contract with no migration. The [security considerations](https://eips.ethereum.org/EIPS/eip-4824) flag three risks. URI updates should follow the DAO's governance, so a single compromised key cannot rewrite the DAO's public description. Indexers should be wary of executable code returned from a URI, which could do more than serve data. And because multiple addresses may report the same `daoURI`, the `contractsURI` list is the mechanism for detecting a contract that spoofs another DAO's identity. The specification is released into the public domain under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

## Adoption, as claimed

EIP-4824 was written in the open through DAOstar's roundtable series, with participants from Aragon, Compound, DAOstack, Gnosis, Moloch, OpenZeppelin, and Tribute, and refined across more than fifty biweekly community calls and sessions at Schelling Point, ETHDenver, and DAO workshops at Harvard and Stanford. That process is visible in who implements it.

On the tooling side, adopters include [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) and Snapshot X, [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), Moloch v2 and v3 via DAOHaus, [Safe](/wiki/dao-governance/tooling/treasury/safe), DAOstack, DAODAO on Cosmos, KALI, Q, Power Protocol, and XDAO. Among individual organizations, the [Optimism Collective](/wiki/daos/networks/optimism-collective), the [Arbitrum](/wiki/daos/networks/arbitrum-dao) Foundation, [ENS DAO](/wiki/daos/infrastructure/ens-dao), 1inch, ShapeShift, Unlock, and Lodestar have published a `daoURI`. Optimism funded rounds of adoption work and the attestation framework, and DAOstar maintains a public registry so that any of these DAOs can be looked up through a single [DAO ID](https://daostar.org/daoid) interface.

That paragraph is a summary of DAOstar's own materials, and every list of this kind should be read as a claim rather than a measurement. The standard is unusual in that its claim can be checked: the index contract exists precisely so registration leaves a public trace. The next section does the count.

## DAOstar and the DAOIP family

[DAOstar](/wiki/dao-governance/tooling/analytics/daostar) describes itself as the standards body of DAOs and is maintained by DAOstar One with support from the [Metagovernance Project](https://metagov.org/). It began as an alliance of the major players in the DAO ecosystem and now publishes a numbered series of DAO Improvement Proposals (DAOIPs), of which EIP-4824 is DAOIP-2 and the anchor the others build on.

The series extends the same daoURI pattern to new domains. DAOIP-3 defines an attestation format – developed under the name Voyager – that lets service providers vouch for DAO data and record member contributions, compatible with soulbound tokens, DIDs, and verifiable credentials. Later proposals add facets to the DAO document: DAOIP-5, for example, standardizes [grant pools](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-5.md) by adding a `grantPoolsURI` field, bootstrapping discovery of on-chain grants the same way `membersURI` bootstraps discovery of members. The through-line is a bet that legibility – a common language for reading organizations – is the layer on which DAO interoperability is built. Full contract and adoption documentation lives in the [DAOstar docs](https://docs.daostar.org/) and the [metagov/daostar](https://github.com/metagov/daostar) repository.

## What the registry actually contains

The `DAOURIRegistered` event was specified so that registration would be observable without trusting anyone's list. DAOstar's [subgraph manifest](https://github.com/metagov/daostar/blob/main/Implementations/Subgraph/daostar/networks.json) names the deployed index contract on each network, and reading each one's full log history gives the complete on-chain registry. Four of the eight named deployments are production networks; the rest are the Goerli, Optimism-Goerli, Arbitrum-Goerli, and BNB Chapel testnets.

| Network | Index contract | `DAOURIRegistered` | First | Last |
| --- | --- | --- | --- | --- |
| Ethereum mainnet | `0x4f2c9028fE7107d9f1A8a9CFf34aa2d3F28600fa` | 4 | 9 Aug 2023 | 12 Feb 2024 |
| Arbitrum One | `0x18CbB356cd64193b1a0CA49911fc72CB3D02a5E4` | 19 | 17 Jan 2024 | 17 May 2024 |
| Optimism | `0x18CbB356cd64193b1a0CA49911fc72CB3D02a5E4` | 6 | 4 Sep 2023 | 22 Feb 2025 |
| Gnosis | `0x8180cbfBFFe59F54BF3Ea5d7DdbaE1232e2bB298` | 1 | 30 Apr 2023 | 30 Apr 2023 |
| **Total** |  | **30** | 30 Apr 2023 | **22 Feb 2025** |

Thirty registrations, and the most recent anywhere is more than a year old. The distinct-organization count is smaller still, because the registry contains duplicates, tests, and DAOstar's own house DAOs:

- **Ethereum mainnet, 4.** Two of them are the standards body registering itself – "DAOStar Devs SubDAO" (`0xD14C…ed5b`) and "MetagovDAO" (`0x48D1…8104`), both [Safe](/wiki/dao-governance/tooling/treasury/safe) multisigs, registered twenty-five minutes and four hours after the index contract was deployed, on the same August morning. The other two are genuine third parties: **1inch DAO** (a Safe) and **Unlock DAO** (the `UnlockProtocolTimelock` contract).
- **Optimism, 6.** The [Optimism Collective](/wiki/daos/networks/optimism-collective) registered twice with the same document, alongside LXDAO and Tulip DAO – and two entries named "Test Treasure" and "Test OP Mainnet", left in the permissionless index alongside the real ones.
- **Arbitrum One, 19**, the largest deployment and the one DAOstar's checked-in subgraph indexes. Seven of the nineteen resolve to the identical **Treasure** document (CID `QmYYep…VJCq`), reached through four different URI spellings of the same file. Two more are **1inch**, pointing at the same CID as its mainnet registration; two are **Lodestar Finance**. The remaining eight are placeholders – "Rose DAO", "Blue DAO", two documents both named "Orchid DAO" with the descriptions "Find beautiful rare orchids" and "sunflower", another "Test Treasure" – plus one contract whose `daoURI()` returns a bare Ethereum address, `0x5C0340AD34f7284f9272E784FF76638E8dDb5dE4`, which is not a URI and cannot be dereferenced at all.
- **Gnosis, 1.** "DAO* Strike Team", DAOstar's own working group again, and its document ships `"description": null` – the exact shape the specification says SHOULD be removed rather than left null.

Across all four networks that leaves roughly eight distinct third-party organizations: 1inch, Unlock, the Optimism Collective, LXDAO, Tulip DAO, Treasure, Lodestar, and the Gnosis entry. Two names from the claimed list are absent from every index deployment. Calling `daoURI()` directly confirms it: the selector reverts on [ENS DAO](/wiki/daos/infrastructure/ens-dao)'s Governor (`0x323A…b7E3`) and its timelock (`0xFE89…44b7`), and on both of [Arbitrum](/wiki/daos/networks/arbitrum-dao)'s governors, core (`0xf07D…95B9`) and treasury (`0x789f…e5a4`). It also reverts on Optimism's `GovernorV6` – the Collective is a real adopter, but through the external-registration path, not by inheriting the interface.

Two caveats keep this honest. The index is one of three publication routes, so a DAO that implements `daoURI()` in its own contract without registering leaves no event, and a DAO reported by a third party under DAOIP-3 leaves none either; the same applies to a [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) space carrying the field off-chain. And no registration contract on any of the four networks has ever emitted a second `DAOURIUpdate` – the event designed to let indexers track changes has never once fired twice. Whatever these organizations published, none of them has revised it.

## The pointers outlived the data

EIP-4824's explicit trade was to keep the chain small and put the substance behind a URI, "at the cost of trusting whatever service the URI points at to stay available". The registry is now a controlled experiment in what that costs.

The description documents themselves are fine. Every IPFS-hosted `daoURI` in the registry still resolves through a public gateway, returns the JSON it returned on the day it was pinned, and is byte-for-byte immutable by construction. What has failed is the layer below – the `membersURI`, `proposalsURI`, and `activityLogURI` those documents point at, which is where the members, proposals, and activity actually live:

- **`services.daostar.org` no longer exists.** It has no A record and no CNAME at Cloudflare, Google, or Quad9 resolvers. Every mainnet registrant and the Gnosis registrant routes its members and proposals through that host; so does Treasure, the most-registered DAO on Arbitrum. The pointer resolves, the payload does not.
- **`api.daostar.org` resolves but does not answer.** It has an A record (`174.138.59.179`) and then times out on both port 80 and port 443. That host is Unlock DAO's entire `daoURI` on mainnet and six of the nineteen Arbitrum registrations, so for those the failure is one level higher – the DAO description document itself is unreachable.
- **`proposalsuri.daostar.org` returns 503.** That is the Optimism Collective's `proposalsURI`, and the hostname reads like the placeholder it evidently was.

The pattern is worth naming because it is not the failure anyone designs against. Nothing was hacked, no key was compromised, no DAO revoked anything. The immutable part stayed immutable and the operational part quietly stopped being operated, and because the standard's whole promise is _follow this pointer to read the organization_, an unreachable second hop empties the standard out while every on-chain check still passes. A registry that reports thirty conforming DAOs and cannot return a single current member list is conforming and useless at the same time. This is the same decay the wiki has documented in [DeSci's shared reference layer](/wiki/desci/ecosystem/vitadao), arriving from a different direction.

## Where the published documents diverge from the specification

Reading all thirty registrations' documents against the specification turns up a second, quieter problem: near enough none of them conforms, and the divergences are systematic rather than sloppy.

- **The `@context` is written four different ways.** The corpus contains ``, `http://www.daostar.org/schemas`, and `https://www.daostar.org/schemas`, sometimes across documents published on the same day by the same tool. The first form is the worst: angle-bracket delimiters are [Turtle](https://www.w3.org/TR/turtle/) and N-Triples syntax, not [JSON-LD](https://www.w3.org/TR/json-ld11/), and a processor reading `@context` as an IRI string will not resolve it. Both spellings 404 in any case – there is no schema document at `daostar.org/schemas`. For a standard whose one job is machine-readability, the field that tells a machine how to read the document is the field least reliably written.
- **Three fields in wide use are not in the specification.** `issuersURI`, `contractsRegistryURI`, and `managerAddress` appear in most published documents and zero times in the text of ERC-4824. They are tooling conventions that hardened into the corpus without passing through the standard.
- **`contractsURI` is absent everywhere.** The specification's security section makes it the anti-spoofing mechanism – "all DAOs adopting this specification SHOULD publish through contractsURI the address of every contract associated to the DAO" – precisely because multiple addresses may report the same `daoURI`. Not one registration publishes it. Where the intent survives at all it is as `contractsRegistryURI` pointing into a JSON file in DAOstar's own GitHub repository, which relocates the anti-spoofing claim from the DAO to the standards body.
- **Empty strings where the specification asks for omission.** ERC-4824 states that a field with no value "SHOULD be removed rather than left with an empty or `null` value". 1inch, Unlock, the Optimism Collective, and Treasure all ship `""`; the Gnosis registrant ships `null`.
- **Two on-chain values are not URIs.** One Arbitrum registration stores its `daoURI` with the JSON quote characters baked into the string, so the value a caller receives is `"https://ipfs.io/…"` including the quotes; another returns a bare Ethereum address. Both passed the index's `supportsInterface` check, because that check tests for the interface, not for whether the string it returns means anything.
- **Where the machine-readable document points at a web page.** The Optimism Collective's `activityLogURI` is `https://gov.optimism.io/`, a forum homepage; the DAOStar Devs SubDAO's is a Safe web-app URL with a query string. The specification defines the activity log as an array of activity objects. What was published is a link a human can click.

None of this is an argument against the design. It is an observation about what a _SHOULD_ buys you when nothing validates: the interface was adopted, the schema was not, and the index cannot tell the difference because the only thing it checks is ERC-165. A conformance suite run at registration time – rejecting a malformed `@context`, an empty string, a missing `contractsURI` – would have caught every defect on this list at the moment it entered the registry. It is a cheap lesson for anyone specifying the next metadata standard: [the data is only as good as the gate](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics).

## From "the DAO standard" to "the DAO metadata specification"

DAOstar has been quietly candid about all of this in the one place a standards body cannot avoid being candid: its own repository. On 12 August 2025, a commit titled [`archive daoip2`](https://github.com/metagov/daostar/commit/9c0d46e88d772c26201803c3cd4b4080187a6438) rewrote the daostar.org homepage headline from "**The DAO standard**" to "**The DAO Metadata Specification**", commented out the "Attestations for DAOs" call to action, and commented out both the "The DAO Standard" explainer section and the "Governed by DAOstar One" roundtable section that listed the alliance's member organizations. A [follow-up commit](https://github.com/metagov/daostar/commit/9c3040bc10f266dc757663850786f65e5cb11c84) four minutes later finished the navigation: the top-level "Standard" link became "Specification", and "Research" was removed.

The new headline is the more accurate one, and the page said as much from the beginning – EIP-4824 standardizes the data about DAOs, not DAOs. What changed is that the standards body stopped claiming the larger thing. It is rare to be able to date a repositioning to a commit hash, and rarer for the correction to move toward candour rather than away from it.

The rest of the repository tells the same story about where the effort went. The only substantive DAOIP commits in 2025 are to [DAOIP-5](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-5.md), the grants standard, and the docs site now leads with OpenGrants rather than daoURI. The last push to [metagov/daostar](https://github.com/metagov/daostar) was 31 October 2025. On the Ethereum side, `EIPS/eip-4824.md` in the EIPs repository is now a stub carrying `status: Moved`, pointing at [ethereum/ERCs](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-4824.md), where the specification's own front matter still reads `status: Review`. The pull request that added it, [#4824](https://github.com/ethereum/EIPs/pull/4824), was merged on 4 September 2022 and the status has not advanced since.

Read together, the honest summary is that EIP-4824 is a well-designed interface that solved a real problem and was never adopted at the scale its framing implied, whose sponsoring body has since narrowed both its claim and its focus. That is a more useful thing to know about a standard than a list of logos, and it is knowable only because the standard was built to be counted.

## Relevance to Caper

EIP-4824 is an Ethereum standard, expressed in Solidity and ERC-165, so Caper – which runs on the Radix network – implements neither the `daoURI()` view nor ERC-165 detection. It does publish the other half of the standard: the DAO description document those interfaces exist to point at. What it shares is the problem the standard exists to solve. Every [caper](/wiki/foundations/what-is-a-caper) is a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), and the facets EIP-4824 works to expose for legacy DAOs – its members, its [proposals](/wiki/governance/proposals) and [votes](/wiki/governance/voting), its activity, and its treasury and contracts – are recorded natively on the Radix ledger and surfaced on the caper's own page. Where EIP-4824 retrofits legibility onto DAOs that were built without it, a caper is legible by construction.

Every caper serves that document at `/wiki/caper//dao.json` – [$CAPER's is a worked example](https://caper.network/wiki/caper/CAPER/dao.json) – carrying `@context: https://www.daostar.org/schemas`, `type: DAO`, and the five subsidiary fields. Members are identified by their explorer URI rather than a CAIP-10 address, since Radix accounts fall under no registered CAIP-2 namespace and the specification allows "another URI identifier" for exactly this case. Proposals carry their status verbatim, the execution transaction where one exists, and the payout, invest and divest calls they authorise. The document is generated from ledger and platform state on each request rather than stored, and the site's [agent card](https://caper.network/.well-known/agent.json) publishes the `daoUriTemplate` that builds its URL from any cashtag. Reading it alongside the rest of the machine-readable surface is covered on [Querying a caper from an AI agent](/wiki/foundations/querying-a-caper-from-an-ai-agent).

Held to the same checklist as the thirty registrations above, the result is mixed, and it is worth stating plainly rather than claiming conformance. Caper publishes `contractsURI` – the anti-spoofing field not one registered DAO publishes – and enumerates every on-ledger component that constitutes the organization: its DAO component, its treasury account and treasury component, its governance-token and vote-token resources, and its founder and treasury-admin badges, with a vote-executor badge joining the list where the DAO has one. It writes `@context` in the one unambiguous form. Against that, it commits the same omission error as 1inch, Unlock and the Optimism Collective, in array rather than string form: a DAO with no members or proposals yet ships `members: []` and `proposals: []`, where the specification says a field with no value SHOULD be removed. It carries both the `membersURI` and the embedded `members` form, where the specification's embedding rule renames the field instead of duplicating it – the URI variants address fragments of the same document, so a consumer following either lands on the same data. And its `governanceURI` resolves to an HTML page, where the specification asks for a flatfile, "normatively a .md file".

One structural difference outranks all of those. Nothing on the Radix ledger announces where the document lives, so no indexer can discover a caper the way the DAOstar index discovers an Ethereum DAO – by watching a registration event. That is the mirror image of the failure documented above. Thirty registrations left an immutable on-chain pointer to an off-chain document that eventually stopped answering; a caper publishes an off-chain document over an on-chain record that keeps answering either way. Were caper.network to stop serving `dao.json` tomorrow, the membership, the proposals and the treasury would all still be on the ledger. What would be lost is the common interface that lets a stranger read them without knowing Caper's contracts – which is precisely the thing EIP-4824 was written to provide, and precisely the thing that turns out to be nobody's job to keep alive.

The failure mode documented above is the sharper lesson, and it is not about which chain anyone chose. It is that a description behind a hostname needs someone to keep paying for the hostname. A caper's proposals, its ballots, its participant list, and its treasury are component state on the ledger – there is no second hop to a service that can quietly stop answering, and nothing to re-host when a grant ends. That is a narrower guarantee than the one EIP-4824 set out to provide, since it says nothing about DAOs on other networks, but it is the part of the promise that has proved hardest to keep.

The DAOstar effort is worth reading precisely because it names what makes a DAO usable to the wider world: not the framework it was built with, but whether an outsider can read its membership, follow its decisions, and audit its holdings. That is the standard against which any launchpad's transparency, Caper's included, is fairly judged.

## References

1. Joshua Tan, Isaac Patka, Ido Gershtein, Eyal Eithcowich, Michael Zargham, and Sam Furter (2022). [ERC-4824: Common Interfaces for DAOs](https://eips.ethereum.org/EIPS/eip-4824). Ethereum Improvement Proposals, no. 4824. Status: Review.
2. Ethereum. [erc-4824.md](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-4824.md) in the ethereum/ERCs repository (the specification's current home), and [Pull Request #4824](https://github.com/ethereum/EIPs/pull/4824), merged 4 September 2022.
3. DAOstar. [metagov/daostar – standards and reference implementations](https://github.com/metagov/daostar). GitHub.
4. DAOstar. [Subgraph networks.json](https://github.com/metagov/daostar/blob/main/Implementations/Subgraph/daostar/networks.json) – the index contract address and start block on each deployed network.
5. DAOstar. [Commit `archive daoip2`](https://github.com/metagov/daostar/commit/9c0d46e88d772c26201803c3cd4b4080187a6438), 12 August 2025, and its [navigation follow-up](https://github.com/metagov/daostar/commit/9c3040bc10f266dc757663850786f65e5cb11c84).
6. DAOstar. [DAOstar documentation – Adopt EIP-4824 and contract reference](https://docs.daostar.org/), and [DAO ID – the daoURI registry and lookup](https://daostar.org/daoid).
7. DAOstar. [DAOIP-5: Grants standard](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-5.md). GitHub.
8. Ethereum. [ERC-165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) and [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721).
9. W3C. [JSON-LD 1.1](https://www.w3.org/TR/json-ld11/) and [RDF 1.1 Turtle](https://www.w3.org/TR/turtle/) – the two syntaxes whose `@context` conventions the published corpus mixes.
10. Registry census (9 August 2026): full `DAOURIRegistered` and `DAOURIUpdate` log histories of the index contracts on Ethereum mainnet, Arbitrum One, Optimism, and Gnosis, read via public block explorers; `daoURI()` (selector `0x7034731b`) read by `eth_call` against each registered address and against the ENS, Arbitrum, and Optimism governance contracts; each resulting document fetched from its stated URI.

## How DAOs fail

URL: https://caper.network/wiki/dao-governance/concepts/analysis/how-daos-fail
Updated: 2026-08-05

|  |  |
| --- | --- |
| **Topic** | DAO failure modes & post-mortems |
| **Core question** | Why do decentralized organizations die, and which deaths are structural? |
| **Failure modes** | Governance capture · Phantom quorum · Plutocratic drift · Treasury mis-custody · Abandonment |
| **Archetype** | [The DAO](https://en.wikipedia.org/wiki/The_DAO) (2016) — the first, and the first to die |
| **On Caper** | Participation-weighted voice; exit equals voice |
| **Related** | [What is a DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) |

A **DAO** promises that a community can hold a treasury and steer a protocol without trusting a central operator. When that promise breaks, the failure is rarely the dramatic one people expect. The archetypal disaster — [The DAO](https://en.wikipedia.org/wiki/The_DAO) of 2016, drained of roughly 3.6 million ETH through a reentrancy bug and salvaged only by a contentious Ethereum hard fork — was a _smart-contract_ failure. The deaths that followed are mostly _governance_ and _treasury_ failures: the code worked exactly as written, and that was the problem. This page is a neutral anatomy of how DAOs actually die, each mode illustrated by a documented case, so the structural risks can be told apart from the merely unlucky ones. For the narrower taxonomy of deliberate exploits, see [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

Most DAOs do not die loudly at all. They go quiet — proposals stop, contributors drift away, and a treasury sits under a multisig that a handful of people still technically control. The louder failures below are worth studying precisely because they expose, in fast-forward, the same weaknesses the quiet ones succumb to slowly.

## Governance capture: renting a majority

The purest structural failure is when someone simply _buys_ or _rents_ the votes to pass whatever they like. If voting weight is read live from token balances, an attacker never has to own the tokens — they can borrow them for the length of a single transaction.

The definitive case is the **Beanstalk** attack of April 2022. An attacker took roughly a billion dollars in flash loans, converted them into the protocol's governance stake within one transaction, instantly commanded a supermajority, and passed a proposal that drained about **$182 million** from the treasury — all before the loan had to be repaid ([CoinDesk](https://www.coindesk.com/tech/2022/04/17/attacker-drains-182m-from-beanstalk-stablecoin-protocol)). The lesson every serious DAO took from it: voting weight must never be readable by capital that is only briefly present — whether by snapshotting balances at a past block or by weighting on something transient capital cannot acquire in time.

Capture does not require a flash loan when quorum is thin enough. In February 2022 an attacker executed a **"hostile governance takeover"** of **Build Finance DAO** by quietly accumulating governance tokens, then passing a proposal — one the community's own Discord bot failed to surface — that handed them the token contract's minting keys and the treasury. They minted 1,107,600 BUILD and drained the liquidity pools, netting around **$470,000**; the DAO was left with no control over any of its own infrastructure ([The Block](https://www.theblock.co/post/134180/build-finance-dao-suffers-hostile-governance-takeover-loses-470000)). No exploit was needed — just an [on-chain governance process](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) operating exactly as designed while almost nobody was watching.

## When governance ratifies the theft

A subtler variant turns the DAO's own legitimacy against it. In October 2022, Avraham Eisenberg manipulated the price of the MNGO token on **Mango Markets** to borrow roughly **$110 million** against inflated collateral, then used the governance tokens he had acquired to _vote through_ a proposal letting him keep about $47 million and shielding him from prosecution — later arguing the on-chain vote made it "legal" ([Cointelegraph](https://cointelegraph.com/news/mango-markets-exploiter-said-actions-were-legal-but-was-it)). A US jury disagreed and convicted him of fraud and market manipulation ([The Block](https://www.theblock.co/post/289543/avraham-avi-eisenberg-convicted-for-110-million-mango-markets-exploit-report)). The episode is a warning that a governance vote is not the same thing as legitimacy: a captured process can launder an attack into an "approved" decision.

## The phantom quorum: apathy as an attack surface

Capture is cheap because participation is low. Empirical studies of on-chain governance repeatedly find that only a small fraction of eligible holders ever vote — often under 10%, and on some Snapshot spaces below 5% ([Blockchain Governance: An Empirical Analysis of User Engagement on DAOs](https://arxiv.org/pdf/2407.10945)). Layer on the fact that a large share of any token's supply sits inert in cold wallets, lost keys, or exchanges, and a DAO's _effective_ quorum shrinks to a sliver of the nominal supply — a "phantom quorum" in which a holder of a couple of percent of the token can carry a proposal unopposed (Optimism writes the correction straight into its quorum rule, setting the threshold against _active_ votable supply, where delegated power counts only if it has been used in the past six months: [Optimism Operating Manual](https://raw.githubusercontent.com/ethereum-optimism/OPerating-manual/main/manual.md)). Apathy is not merely a health metric; it is the attack surface that makes the takeovers above affordable. For the full anatomy of low participation — why holders rationally abstain, the empirical turnout figures, and the mitigation ladder — see [Voter apathy and governance participation](/wiki/dao-governance/concepts/analysis/voter-apathy).

Paying people to participate is not a full fix either. [Jupiter](/wiki/daos/dexs/jupiter) rewards JUP holders who actually vote with quarterly [Active Staking Rewards](/wiki/daos/dexs/jupiter), yet in June 2025 it nonetheless [paused DAO voting](https://www.coindesk.com/business/2025/06/20/solana-dex-jupiter-pauses-dao-votes-citing-breakdown-in-trust) entirely, citing a “breakdown in trust” — a reminder that subsidized turnout is not the same as durable legitimacy.

## Plutocratic drift and re-centralization

Even absent an attacker, capital-weighted voting (see [voting mechanisms](/wiki/governance/voting-mechanisms)) tends to concentrate power over time rather than distribute it. Vitalik Buterin's [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) lays out the core defect: a voter who merely _borrows_ tokens has no lasting exposure to the outcome, so coin voting measures capital-at-hand rather than commitment-to-the-project. The empirical arc bends the same way — a 2026 review of decades of governance research found that DAOs [keep re-centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/), with active control collapsing back onto a small set of whales, delegates, and core contributors. A DAO can be perfectly decentralized on paper and a de-facto oligarchy in practice; the gap between the two is where trust quietly erodes.

The sharpest illustration is [Aragon DAO](/wiki/daos/infrastructure/aragon-dao) — because it was executed deliberately, by the industry's own governance vendor. Aragon's token holders voted in June 2022 to move a nine-figure treasury on-chain; the Swiss association holding it delayed, and when holders assembled a majority to claim it in May 2023, the association halted the transfer and repurposed the DAO, describing those holders as raiders. It later dissolved and returned the treasury directly, concluding in its own words that "neither the AA nor ANT are currently suited to govern the project". Re-centralization here was not drift. It was a decision taken the moment decentralization became expensive, which is the only moment it is ever tested.

## Treasury mismanagement and mis-custody

The treasury is the thing a DAO exists to steward, and it fails in two characteristic ways. The first is **custody risk**: the funds are, in practice, controlled by people the community cannot vet. **Wonderland** (the TIME project) ran a treasury that peaked above **$1 billion**, until its pseudonymous treasury manager "0xSifu" was revealed to be Michael Patryn, a convicted felon and co-founder of the collapsed QuadrigaCX exchange; assets under management cratered toward $146 million and the project unwound even after the community voted overwhelmingly to remove him ([CoinDesk](https://www.coindesk.com/markets/2022/01/27/wonderland-rattled-after-cofounder-tied-to-alleged-quadrigacx-190m-exit-scam); [The Block](https://www.theblock.co/post/132340/wonderland-votes-out-quadrigacx-co-founder-sifu-and-is-considering-shutting-down)). The second is **concentration risk**: treasuries held largely in the DAO's own governance token show enormous paper valuations that evaporate the moment the token is actually sold, leaving little to fund the work the DAO promised. Not every shortfall is terminal: when THORChain's ThorFi lending products left the protocol with more than **$200 million** of RUNE-denominated debt, its node operators paused the network and restructured the hole into a revenue-share token ([THORChain](/wiki/daos/dexs/thorchain)) rather than inflating it away — a reminder that whether an insolvency ends a DAO turns as much on its governance as on its balance sheet. Sound [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) — diversification, verifiable on-chain custody, and spending tied to enforceable rules — is what separates a durable DAO from a balance sheet waiting to be marked down. The most radical answer is to have no treasury at all: [Protocol Guild](/wiki/daos/public-goods/protocol-guild) routes $183m of lifetime donations through immutable vesting contracts that, in its own words, "cannot be stopped or otherwise redirected during the vest by anyone, be it the donor or Protocol Guild membership" — neither failure mode can occur where no vote and no custodian can reach the funds. That escape is only available to an organization with nothing to decide, which is precisely what most DAOs are not.

## The quiet death: abandonment and trapped stakeholders

The most common ending is the least reported. Contributors move on, proposal flow dries up, and the DAO becomes a dormant contract with a treasury nobody is actively directing. A large part of what drives this is the absence of a clean way _out_: when a member disagrees with the direction but cannot leave with their fair share of the treasury, the rational move is to disengage rather than fight — which drains exactly the engaged minority a DAO needs to stay alive. This is why [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) (the "rage-quit" pattern popularized by Moloch DAOs) matter structurally: a credible exit keeps insiders honest and gives dissenters an alternative to quiet abandonment. A DAO with no exit does not resolve its disagreements — it accumulates them until it stops. Not every ending is quiet, though: in June 2025 the [ApeCoin DAO](/wiki/daos/social/apecoin-dao) took the opposite exit, voting by a reported 99.66% to dissolve itself entirely and transfer its treasury and intellectual property to a founder-controlled company — a formal, near-unanimous surrender of the DAO form rather than a slow fade.

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) is designed around these failure modes rather than the happy path. Decisions use [ranked-choice voting](/wiki/governance/voting) over [proposals](/wiki/governance/proposals) that carry real on-chain [actions](/wiki/governance/execution), and voting weight is the product of two things: the governance stake a member holds _and_ the participation they have actually shown — the latter earned as non-transferable tokens minted one per vote. Because a member's first vote counts for nothing and those participation tokens cannot be bought or borrowed, capital that has only just arrived — flash-loaned or freshly acquired — carries little to no weight; the flash-loan route that drained Beanstalk simply has nothing to grip. That structurally answers both the rented-majority capture and the phantom quorum, since influence accrues to members who keep showing up rather than to dormant or transient tokens. And because that same earned standing sets each member's pro-rata claim on the treasury at [exit](/wiki/governance/execution), **voice and exit are the same number**: a member who disagrees can leave with their fair share rather than quietly abandon the DAO, and the treasury math is enforced by contract rather than entrusted to a custodian. The specifics live on the linked governance pages; this article is the map of the failures they are built to avoid.

## Sources

- Wikipedia, [The DAO](https://en.wikipedia.org/wiki/The_DAO).
- CoinDesk, [Attacker Drains $182M From Beanstalk Stablecoin Protocol](https://www.coindesk.com/tech/2022/04/17/attacker-drains-182m-from-beanstalk-stablecoin-protocol) (2022).
- The Block, [Build Finance DAO suffers 'hostile governance takeover', loses $470,000](https://www.theblock.co/post/134180/build-finance-dao-suffers-hostile-governance-takeover-loses-470000) (2022).
- Cointelegraph, [Mango Markets exploiter said actions were 'legal', but were they?](https://cointelegraph.com/news/mango-markets-exploiter-said-actions-were-legal-but-was-it) (2022), and The Block, [Eisenberg convicted for $110 million Mango Markets exploit](https://www.theblock.co/post/289543/avraham-avi-eisenberg-convicted-for-110-million-mango-markets-exploit-report) (2024).
- arXiv, [Blockchain Governance: An Empirical Analysis of User Engagement on DAOs](https://arxiv.org/pdf/2407.10945) (2024).
- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).
- Forbes, [DAOs Keep Centralizing — Decades Of Governance Research Explain Why](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) (2026).
- CoinDesk, [Wonderland Rattled After Co-Founder Tied to QuadrigaCX](https://www.coindesk.com/markets/2022/01/27/wonderland-rattled-after-cofounder-tied-to-alleged-quadrigacx-190m-exit-scam) (2022), and The Block, [Wonderland votes out QuadrigaCX co-founder Sifu and is considering shutting down](https://www.theblock.co/post/132340/wonderland-votes-out-quadrigacx-co-founder-sifu-and-is-considering-shutting-down) (2022).

## Further reading

Two Caper essays pick up where this map ends. They argue the deepest failures above trace to two missing structural rights — an owned treasury and an enforceable way out:

- [The Exit Right](/blog/the-exit-right) — why the ability to leave with your fair share is the discipline most DAOs never build in, and what governance looks like when voice and exit are the same number.
- [The Personal Caper](/blog/the-personal-caper) — the personal-token wave of 2020 and what it was missing: a standing curve counterparty is not the same as an owned treasury with a binding exit.

Related on this wiki: [Rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) · [Personal tokens](/wiki/economics/personal-tokens) · [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics).

## Scoring and review gates in DAO funding

URL: https://caper.network/wiki/dao-governance/concepts/analysis/scoring-and-review-gates
Updated: 2026-08-08

| Topic | What a published application score decides in a DAO funding process, and what it does not |
| --- | --- |
| Three live gates | Optimism Grants Council (scores out of 10, stated pass mark) · ENS SPP3 (weighted rubric out of 4.75, committee cohort) · VitaDAO senior review (conviction score out of 5) |
| The common finding | In all three the number is real, published and non‑binding. Budget, portfolio shape or a vote nobody calls decides the outcome. |
| Disclosure pattern | Scores are published for the applications that won; declined applicants get aggregate rationale or a forum thread |
| Related | [Procurement and RFPs](/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps), [Service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers), [RetroPGF](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) |

## What a review gate is

A review gate is the step where a DAO hands a funding decision to a small group of named people, asks them to score applications against a written rubric, and publishes the numbers. It exists because token voting answers the wrong question. A vote measures how popular a proposal is among people holding the token; it does not measure whether the engineering is sound, whether the team has shipped before, or whether the science is any good. Nearly every DAO that funds work at scale has arrived at the same patch: put competence in front of the ballot, and write down how it scored.

This page is about the number that comes out. It is a narrower object than the two topics it sits between. [Procurement and RFPs](/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps) covers how the call is run and who is eligible to answer it; [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers) covers who the DAO ends up contracting with and on what terms. Between the two sits a published score, and the question worth asking of any DAO that produces one is simple: what did it decide?

Three programmes published enough to answer that. In all three the honest answer is that the score decided less than the artifact implies.

## Optimism: a stated pass mark its own table contradicts

The Optimism Grants Council reviews applications to the Governance Fund and publishes the results per cycle. [Cycle 35's preliminary review results](https://gov.optimism.io/t/cycle-35-preliminary-review-results/9791), posted 28 March 2025, are unusually legible: a single table listing every application, the OP requested, the average reviewer score, and the outcome. The post states the rule in one line above the table, that the score required to advance was 7 or higher, and reports that 13 of the applications passed preliminary review.

The table does not obey the line. Three applications advanced below the stated mark: Giza at 6.66, DeSyn Protocol at 6.00 and SwapBased at 6.00. In the same table, Gamma Strategies was declined at 6.66, Orderly at 6.33 and yUSD at 6.00. An identical 6.66 produced both outcomes in the same cycle, and a 6.00 both passed and was declined.

The explanation is in the budget line rather than in any inconsistency of judgement. The post records that finalists requested 15,365,599 OP against a Grants Council budget of 3,285,070 OP, an oversubscription of roughly 4.7 to 1. A pass mark cannot bind when the money runs out at a quarter of the qualifying field. Once that is true the score has quietly changed job: it is a ranking used to sort a queue, not a threshold that admits anyone who clears it, and the two are different instruments even though they are printed in the same column. The council's own framing points the same way, since the same post ties every award to the season's success metrics for Superchain TVL rather than to the number in the table.

Optimism's wider funding history is covered on [Optimism Collective](/wiki/daos/networks/optimism-collective) and, for the retroactive rounds that ran alongside the council, on [retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding).

## ENS: the rubric says outright that it is not the decision

[ENS DAO](/wiki/daos/infrastructure/ens-dao) reached the same place from the opposite direction, and wrote it down. The DAO's Service Provider Program had asked delegates to rate and rank every applicant themselves. [A February 2026 proposal](https://discuss.ens.domains/t/proposal-committee-model-for-spp3-funding-allocation/21918) argued that this had failed on three counts: delegates were hit with a barrage of lobbying, applicants spent weeks chasing up to a hundred delegates with the well‑connected ones advantaged, and most delegates did not know enough about the ecosystem to read the applications properly. The remedy was to stop voting on applicants and vote on a panel instead.

Delegates ratified exactly that. [SPP3's program authorization](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086) passed on Snapshot in May 2026 with 1,478,297 votes for against 18,438 opposed, authorizing one cycle, naming the committee, and capping the budget at 20% of trailing protocol revenue. The committee then [published its rubric before the submission window opened](https://discuss.ens.domains/t/spp3-submission-timeline-and-artifacts/22124): four weighted criteria scored 1 to 5 in half‑point steps, with prior delivery history at 25%, scope clarity at 15%, milestone structure at 15%, adoption and ecosystem utility at 40%, and 5% of discretion for team and budget fit.

The sentence that matters sits directly under the weights table. The committee wrote that the rubric is an evaluation tool, not a selection formula, and that the final cohort would account for budget constraints, provider overlap and strategic gaps across the cohort as a whole. That is Optimism's Cycle 35 table stated as policy in advance rather than left for a reader to infer.

The [cohort recommendation](https://discuss.ens.domains/t/ep-6-49-spp3-cohort-recommendation/22237) in July 2026 bore it out. Twenty‑six applications requested a combined $12.2M; one failed the eligibility screen and 25 were scored. Four providers were funded for $1,690,000 against roughly $3.25M available, and their weighted scores were published: Namespace 3.43, Goldsky 3.37, Unruggable 3.30 and Fluidkey 3.11, each out of 4.75 once the discretionary component is excluded. The whole funded cohort therefore sits in the rubric's adequate band, and the highest single criterion score anywhere in the published table is a 4.5 for prior delivery. The committee also stated plainly that several declined teams scored competitively and that redundancy rather than quality was the deciding factor, because the applicant pool contained multiple marketplaces, subname providers and indexing proposals and funding duplicative work reduces total programme value.

Two structural facts round it out. The committee left roughly $1.56M of authorized budget uncommitted rather than fund a marginal application, which is the strongest available evidence that the panel was exercising judgement rather than spending a pot. And the programme carries a $200,000 floor on requests, so the gate excludes small applicants before any scoring happens. The committee named that as a finding of the cycle, reporting demonstrated demand for discrete sub‑$200K funding that no active programme serves, and recommended the DAO stand one up.

## VitaDAO: a low score does not reject, it strands

[VitaDAO](/wiki/desci/ecosystem/vitadao) runs the same instrument on research rather than infrastructure, and supplies the failure mode neither of the others reaches. [VDP-164](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052), proposed in September 2025, asked for a $500,000 recoverable loan to take a therapeutic through non‑GLP toxicology toward an IND submission. Four reviewers scored it across seven categories for an overall conviction score of 2.3, against an average of 3.7 for the projects VitaDAO had previously funded.

Nothing then rejected it. The constitution's escalation ladder says a request of that size needs a forum poll and a Snapshot vote, and the proposal has never appeared on VitaDAO's Snapshot space. It did not lose a vote; the vote was never called. A scored gate that sits in front of the ballot can therefore produce a third outcome beyond pass and fail, which is that a proposal simply stops, with the record of what happened living in a forum thread rather than in a tally anyone can point to. That has since become literal: gov.vitadao.com stopped resolving during 2026, and the thread survives only as an [Internet Archive capture](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052). A gate that strands proposals leaves its only record on the least durable layer of a DAO's stack – the detail is on [VitaDAO](/wiki/desci/ecosystem/vitadao). The wider mechanics of research funding are covered on [decentralized science funding](/wiki/desci/desci-funding).

## What the published score actually does

Read together, the three programmes point at the same conclusion from different angles. The score is an accountability artifact, not a decision rule.

- **It is a ranking, not a threshold.** Optimism printed a pass mark and then advanced three applications below it while declining others above it, because the money bound before the mark did. Any programme that is oversubscribed will do the same thing whether or not it says so.
- **Portfolio shape overrides the column.** ENS declined competitively scored teams for overlapping with each other. A rubric scores applications one at a time; a cohort is chosen as a set, and no per‑application score can express the fact that two good proposals do the same job.
- **The gate can strand as well as decide.** A low score reached before the binding vote does not have to be converted into a rejection anyone is accountable for. Where the vote is discretionary to call, nobody has to call it.
- **The eligibility screen does more work than the rubric.** ENS applies a hard screen before scoring, and its $200,000 floor removes an entire class of applicant without producing a number at all. The most consequential judgement in a scored process is frequently the one made before scoring starts, a pattern also visible in DAO [tender panels](/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps).

None of this is an argument against review gates. Every alternative on offer is worse: delegates who admit they cannot read 26 commercial proposals, or a token vote that measures popularity and calls it merit. The argument is against reading the number as though it were the decision. A DAO that publishes scores and lets its members infer that the top scores were funded is claiming a legibility it does not have, and ENS's contribution is to have said so in the rubric itself.

## The disclosure gradient runs the wrong way

There is a consistent asymmetry in what these processes publish, and it points away from the people with the strongest interest in the answer.

ENS published a per‑criterion score table for the four providers it funded. Declined applicants received aggregate rationale grouped into recurring patterns, and the individual scoring records remain internal working documents available to the accountability body or the foundation on request. Optimism is the more transparent of the two on this axis, publishing a score for every application including the declines, though only a single average rather than the reviewers' individual marks. VitaDAO published a category‑by‑category digest for its declined proposal but not the reviewer document, and the loudest objection came from the chief executive of the company under review, who argued in the forum thread that the community should be able to read the reviews rather than rely on anonymous reviewers whose credentials nobody could check.

The pattern is that the applicant who won learns the most about why. This is understandable in each case and unfortunate in aggregate: the decline is where the information is, both for the applicant deciding whether to reapply and for a delegate trying to judge whether the panel it deputized is any good. A programme that discloses only its winners is asking to be trusted on precisely the decisions it is not showing. The wider failure of a committee whose work the DAO cannot check is covered on [council dissolution](/wiki/dao-governance/concepts/analysis/council-dissolution) and [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## How Caper approaches this

Caper has no review gate, and no way to build one. There is no reviewer, panel, committee or steward class anywhere in the contracts, no rubric, no score and no eligibility screen. On the merits of choosing between 26 applications that is a gap rather than an answer, and it should be said plainly: nothing in Caper helps a group of people work out which of several proposals is worth funding. The DAOs above built rubrics because that problem is genuinely hard, and a shorter leash does not solve it.

What Caper does remove is the third outcome. A [proposal](/wiki/governance/proposals) carries an execution window on a clock, and once that window opens `settle_proposal` is a public method: any account can call it, tally the ballots and settle the result, and the winning payout is then executed through an equally public method. The party inconvenienced by the outcome is not the party who has to call the vote. A funding request on a caper cannot spend eleven months between a review and a ballot nobody schedules, because scheduling is not a privilege anybody holds.

The other structural difference is who the gate answers to. Vote weight in a caper multiplies a member's holdings by their earned, non‑transferable participation record, normalized against the caper's supply of each, so a large position on its own does not carry a decision. There is no separate body whose approval a proposal needs before members can vote on it, which means there is also no body a well‑funded applicant can lobby instead of the membership. And a member who loses the argument retains a standing exit that returns their share of the treasury rather than only the option to keep arguing. See [what is a caper](/wiki/foundations/what-is-a-caper) for the full model.

## References

- [Cycle 35 Preliminary Review Results](https://gov.optimism.io/t/cycle-35-preliminary-review-results/9791) – gov.optimism.io, 28 March 2025. The full per‑application score table, the stated 7‑or‑higher advance mark, and the 15,365,599 OP requested against a 3,285,070 OP budget.
- [Proposal: Committee Model for SPP3 Funding Allocation](https://discuss.ens.domains/t/proposal-committee-model-for-spp3-funding-allocation/21918) – discuss.ens.domains, 26 February 2026. Delegate fatigue, applicant lobbying and lack of context, and the case for voting on a panel instead of on applicants.
- [[6.42] [Social] SPP3: Program Authorization and Committee Model](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086) – discuss.ens.domains, 25 April 2026. One‑cycle authorization, the named committee, and the 20%‑of‑trailing‑revenue cap.
- [SPP3: Submission Timeline and Artifacts](https://discuss.ens.domains/t/spp3-submission-timeline-and-artifacts/22124) – discuss.ens.domains, 14 May 2026. The four weighted criteria, the 1‑to‑5 half‑point scale, the pre‑scoring eligibility screen with its $200,000 floor, and the statement that the rubric is an evaluation tool rather than a selection formula.
- [[EP 6.49] SPP3: Cohort Recommendation](https://discuss.ens.domains/t/ep-6-49-spp3-cohort-recommendation/22237) – discuss.ens.domains, 3 July 2026. The 26‑application funnel, the published weighted scores out of 4.75, the $1,690,000 cohort against roughly $3.25M available, and the aggregate decline rationale.
- [VDP-164: $500K loan to advance VITARNA](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052) – gov.vitadao.com, 16 September 2025, cited through the Internet Archive because the forum is offline. The seven‑category senior review, the 2.3 conviction score against a 3.7 average, and the argument over publishing the reviewer document.
- [ENS DAO on Snapshot](https://snapshot.box/#/s:ens.eth) and [VitaDAO on Snapshot](https://snapshot.box/#/s:vote.vitadao.eth) – the vote records behind the SPP3 authorization and the absence of a VDP-164 ballot.

## The machine-readable DAO

URL: https://caper.network/wiki/dao-governance/concepts/analysis/machine-readable-dao
Updated: 2026-08-12

| Topic | How a DAO publishes itself to software rather than to people |
| --- | --- |
| The four surfaces | `daoURI()` / EIP-4824 · `/llms.txt` · A2A agent card at `/.well-known/agent-card.json` · Model Context Protocol server |
| Lineages | An Ethereum ERC (2022) · a community proposal by an AI researcher (2024) · a Linux Foundation agent protocol (2025) · an open protocol from an AI lab (2024) |
| Census (12 August 2026) | Of the 70 organizations in this wiki's [DAO directory](/wiki/daos) that publish a website, 66 answered a clean probe: **18 serve `/llms.txt`**, **1 serves an MCP server card**, **0 serve an A2A agent card** |
| What none of them publishes | Live governance state. Not one of the 18 `llms.txt` files names a live proposal, a member, or a treasury balance |
| The shared failure mode | Every surface is an off-chain pointer that somebody has to keep paying to host |
| Related | [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) · [DAOstar](/wiki/dao-governance/tooling/analytics/daostar) · [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) · [DAO metrics and analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) |

A [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) that nobody can read is, for most practical purposes, a private company with a public ledger. Its members exist as addresses in a contract, its decisions as calldata, its treasury as balances no outsider can attribute. The gap between "the data is on-chain" and "a stranger can read the organization" is filled by a description the organization publishes about itself – and increasingly, that description is written for software rather than for people.

Four such surfaces now exist, and they arrived from four unrelated directions. One came out of DAO governance itself. One came from an AI researcher's blog post. One came from an agent-interoperability working group. One came from a model vendor's protocol. None of them was designed with the other three in mind, none of them supersedes the others, and a DAO wanting to be legible to machines in 2026 has to decide, without much guidance, which of them to publish.

This page describes the four, then reports a census: on 12 August 2026, every organization in this wiki's [DAO directory](/wiki/daos) was probed for all four. The results are the useful part, and they are not what the volume of writing about agentic infrastructure would lead you to expect.

## Four surfaces, four lineages

**`daoURI()` and the DAOIP family.** The oldest and the only one built for DAOs specifically. [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824), authored through [DAOstar](/wiki/dao-governance/tooling/analytics/daostar) and created in February 2022, defines a single on-chain function that returns a URI pointing at a [JSON-LD](https://www.w3.org/TR/json-ld11/) document listing the DAO's members, proposals, activity log, governance rules, and contracts. It is the only one of the four whose vocabulary is _about governance_: it has a field for a proposal's on-chain calls, and a field for who voted. It is also the only one with an on-chain discovery mechanism, an index contract that emits a registration event. Four and a half years after creation it still carries the status [Review](https://eips.ethereum.org/EIPS/eip-4824), and a census of its four production index deployments found 30 registrations, the most recent in February 2025.

**`/llms.txt`.** Proposed by [Jeremy Howard in September 2024](https://llmstxt.org/), this is a Markdown file at a site's root whose only mandatory element is an H1 with the project name. Everything else – a blockquote summary, prose sections, H2-delimited lists of links with one-line notes – is optional. It is explicitly a community proposal rather than a standard: no registry, no validator, no conformance suite. What it has instead is reach. Its own documentation notes that thousands of sites publish one, that OpenAI, Anthropic and Google ship them for their documentation, and that Chrome's Lighthouse now audits for it. It says nothing about governance because it says nothing about anything in particular – it is a table of contents for a language model.

**The A2A agent card.** The [Agent2Agent protocol](https://a2a-protocol.org/latest/specification/), now published under the Linux Foundation, defines an `AgentCard` object served at a registered well-known URI. The registration entry names the suffix `agent-card.json`, with the A2A Protocol Working Group as change controller. The card declares what an agent can do, what protocols and authentication it supports, and what skills it exposes. The path is itself a migration hazard: version 0.3 renamed it from `/.well-known/agent.json`, and a spec-compliant 1.0.0 client will not look at the old location.

**An MCP server.** The [Model Context Protocol](https://modelcontextprotocol.io/specification/latest) is the most capable of the four and the least like a file. Instead of publishing a document, an organization runs a JSON-RPC endpoint that exposes tools, resources and prompts, so an agent asks questions rather than downloading a snapshot. That difference matters for a DAO: a document describes the treasury as it stood when the document was generated, while a tool answers about the treasury now.

## The census: what DAOs actually publish

The four surfaces are cheap to probe, so on 12 August 2026 every organization in this wiki's [DAO directory](/wiki/daos) was checked for all of them. The directory holds 71 organizations, 70 of which record a website ([ConstitutionDAO](/wiki/daos/social/constitutiondao), dissolved in 2021, does not). Each domain was requested at `/llms.txt`, `/.well-known/agent-card.json`, `/.well-known/agent.json` and `/.well-known/mcp.json` under a browser user-agent, following redirects.

The probe needs one discriminator to be worth anything. Most of these sites are single-page applications that answer _every_ path with HTTP 200 and their own HTML shell, so a naive status check reports a file that does not exist. The test used here is the response's content type: a real `llms.txt` comes back as `text/plain`, a real agent card as `application/json`, and the SPA fallback as `text/html`. As a control, each positive was re-probed at a nonsense path (`/llms-caper-control-9f3a.txt`); fifteen returned 404 and three – yearn.fi, rocketpool.net and cosmos.network – returned 200 with `text/html`, exactly the behaviour the content-type test is there to catch.

Four domains could not be resolved either way and are excluded from the denominators: balancer.fi returned HTTP 429, sky.money and jito.network returned Cloudflare 403 challenges, osmosis.zone answered the well-known path with a redirect loop, and ether.fi returned HTTP 500 for `/llms.txt`. That leaves 66 organizations that answered cleanly.

| Surface | Published | Of 66 answering |
| --- | --- | --- |
| `/llms.txt` | 18 | 27% |
| MCP server card at `/.well-known/mcp.json` | 1 | 1.5% |
| A2A agent card (either path) | 0 | 0% |

The eighteen serving `/llms.txt` are 1inch, Aragon, Cosmos Hub, Kleros, Lido, Maple Finance, Ondo Finance, Pendle, Polygon, Rocket Pool, Safe, The Graph, THORChain, Euler, Helium, Starknet, The LAO and Yearn. The zero for agent cards is not an artefact of the probe: thirteen domains returned HTTP 200 for one of the two agent-card paths, and all thirteen were the SPA HTML shell. That result is consistent with the wider web. A [survey published on 29 July 2026](https://apievangelist.com/2026/07/29/most-published-agent-cards-are-not-actually-a2a/) probed 22,341 hosts drawn from the APIs.io catalogue, of which 20,185 answered, and found 65 serving any agent card at all – 0.29 percent – of which only 10 passed every structural check in the A2A 1.0.0 `AgentCard` object, and 15 were still sitting at the pre-0.3 `agent.json` path.

## The one MCP endpoint, examined

The single MCP result is worth reading closely, because it shows how thin the line between publishing a surface and operating one can be. [THORChain](/wiki/daos/dexs/thorchain) serves a well-formed server card at `thorchain.org/.well-known/mcp.json` declaring a read-only endpoint named `thorchain-public-discovery`, three tools (`get_site_summary`, `get_agent_rules`, `list_public_api_references`), no required authentication, and an HTTP transport at `thorchain.org/mcp`. It also serves an `AGENTS.md` at its root describing the rules it asks AI clients to follow – a fifth convention, and one no other organization in the directory publishes either.

Two details qualify it. The card's `$schema` points at `modelcontextprotocol.io/schemas/server-card/v1.0`, which returns 404 – the MCP specification, revision 2026-07-28, defines a wire protocol and a registry, not a well-known server-card URI, so this is a convention the publisher has adopted rather than a spec it conforms to. And a JSON-RPC `initialize` posted to the declared endpoint returns the site's HTML, not a protocol response: `/mcp` serves the same static document as the well-known path. THORChain has published discovery metadata for an MCP server. It has not, as of this probe, put a live MCP server behind it.

That is not a criticism so much as a measurement of where the field is. The most agent-forward organization in a 70-strong directory of the largest DAOs in existence has shipped a JSON file and a Markdown file describing an interface that does not yet answer.

## What the published files say – and what they leave out

The more revealing finding is not the count but the content. All eighteen `llms.txt` files were retrieved and read. Every one of them is a product summary. They describe what the protocol does, list the documentation, and point at the app.

Not one names a live proposal. Not one lists a member or a delegate. Not one states a treasury balance. Four of the eighteen link a governance venue at all – Cosmos Hub to `forum.cosmos.network`, Euler to its forum plus [Snapshot](https://snapshot.org/#/eulerdao.eth) and [Tally](https://www.tally.xyz/gov/euler), Kleros to its forum and Snapshot space, Yearn to `gov.yearn.fi` – and in every case the link is to the venue's human-facing front page, not to a machine-readable proposal list. Seven files mention the words proposal, treasury, voting or delegate anywhere; the mentions are almost all links to marketing pages about a governance token.

One of the eighteen is not even a deliberate act of publication. Starknet's file opens with a byte-order mark and the line "Generated by Yoast SEO v27.3, this is an llms.txt file, meant for consumption by LLMs" – it is the output of a WordPress SEO plugin, an artefact of the marketing site rather than a decision by the organization.

Put together with the [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) registry, which is the one surface with governance vocabulary and has 30 registrations across its entire history, the pattern is consistent: the surfaces that describe _governance_ are barely adopted, and the surface that is adopted describes _the product_. An agent that reads every machine-readable file the largest DAOs publish will come away able to explain how to swap a token and unable to say who decides anything.

## The failure mode all four share

Each of the four surfaces resolves, in the end, to a hostname. `daoURI()` stores a pointer on-chain and the document lives off it. `llms.txt` is a file on a web server. An agent card is a file on a web server at a more specific path. An MCP endpoint is a running service, which is the same dependency plus a process that has to stay up.

This is the single structural weakness the whole category inherits, and it is not hypothetical. The EIP-4824 registry is the worked example: an immutable on-chain pointer, registered once, aimed at an off-chain document that eventually stopped answering, with nobody obliged to notice. It is the same mechanism documented on [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) – a DAO's legibility outsourced to infrastructure that runs on somebody's renewal cycle, and quietly ends when a grant does.

The asymmetry is what makes it dangerous rather than merely annoying. The pointer is durable; the thing it points at is not. A registration event from 2023 sits on Ethereum forever, advertising a description that has been gone for a year, and there is no on-chain signal that distinguishes the two states. Anyone specifying the next such standard has an obvious lesson available: [a pointer with no liveness check is a claim, not a fact](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics).

## What a DAO that wants to be readable should actually do

The census supports a short, unglamorous set of conclusions.

- **Publish `llms.txt`, but do not mistake it for governance transparency.** It is the cheapest of the four, it has real reach, and 27% of the largest DAOs already have one. It is also, as published today, a marketing artefact. A DAO can distinguish itself here almost for free by including what everyone else omits: the governance forum, the voting venue, the treasury address, and the proposal list, as links a machine can follow.
- **Treat the agent card as unclaimed ground.** Zero adoption across 66 major DAOs, and 0.29% across 20,185 hosts on the wider web, means the format is early rather than settled. If a DAO publishes one, publish at `/.well-known/agent-card.json`, since a 1.0.0 client will not read the legacy path.
- **An endpoint beats a document for anything that changes.** Treasury balances, open proposals and vote tallies are stale the moment a file is written. This is the argument for MCP over any of the file formats, and the reason the one published MCP card in the directory is more interesting than the eighteen files.
- **Prefer surfaces whose underlying data survives the host.** A description that is generated on request from chain state can be re-created by anyone from the chain. A description that was written once and uploaded cannot.

## How Caper approaches this

Every [caper](/wiki/foundations/what-is-a-caper) is a DAO, and the platform publishes all four surfaces – which makes it a fair test of the argument above rather than an exception to it. Verified live on 12 August 2026: [caper.network/llms.txt](https://caper.network/llms.txt) returns the index and [llms-full.txt](https://caper.network/llms-full.txt) the whole corpus; every wiki page also answers at its own URL with a `.md` suffix as `text/markdown`; each DAO has its own [per-DAO `llms.txt`](https://caper.network/wiki/caper/CAPER/llms.txt) and its own [EIP-4824 `dao.json`](https://caper.network/wiki/caper/CAPER/dao.json); there is an [agent card](https://caper.network/.well-known/agent.json) and an [OpenAPI document](https://caper.network/.well-known/openapi.json); and the MCP endpoints are live rather than declared – a `tools/list` call to `/api/mcp` returns eight tools, and the per-DAO endpoint at `/wiki/caper/{cashtag}/mcp` returns six, including `get_ledger` for treasury, timeline, grants and inter-DAO funding.

Two honest deductions apply against the standard set out above. Caper's agent card sits at the legacy `/.well-known/agent.json` path, so a spec-compliant A2A 1.0.0 client will not find it – the same defect the July 2026 survey found in 15 of the 65 cards it located. And a caper with no members or proposals yet ships `members: []` and `proposals: []` in its `dao.json`, where the specification says an empty field should be omitted.

What does hold is the fourth conclusion. Every one of those documents is generated from ledger and platform state on request rather than stored, so there is no snapshot to go stale, and the data underneath is Radix component state: the members, the proposals, the votes and the treasury exist on-ledger whether or not caper.network serves anything at all. If the site stopped answering tomorrow, what would be lost is the convenience of the common interface, not the record. That is a narrower promise than "the DAO is machine-readable", and it is the part of the promise the last four years suggest is hardest to keep.

## References

1. Joshua Tan, Isaac Patka, Ido Gershtein, Eyal Eithcowich, Michael Zargham, and Sam Furter (2022). [ERC-4824: Common Interfaces for DAOs](https://eips.ethereum.org/EIPS/eip-4824). Status: Review. See also this wiki's [page on the standard](/wiki/dao-governance/concepts/analysis/eip-4824) and its registry census.
2. Jeremy Howard. [The /llms.txt file](https://llmstxt.org/) – proposal, format, and adoption notes.
3. A2A Protocol. [Agent2Agent (A2A) Protocol Specification](https://a2a-protocol.org/latest/specification/), published under the Linux Foundation; section 14.3 registers the `agent-card.json` well-known URI suffix.
4. Kin Lane. [Most Published Agent Cards Are Not Actually A2A](https://apievangelist.com/2026/07/29/most-published-agent-cards-are-not-actually-a2a/), API Evangelist, 29 July 2026 – the 22,341-host / 65-card / 10-conformant survey.
5. Anthropic and contributors. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/latest), revision 2026-07-28.
6. THORChain. [MCP server card](https://thorchain.org/.well-known/mcp.json) and [AGENTS.md](https://thorchain.org/AGENTS.md).
7. Directory census (12 August 2026): all 70 websites recorded in this wiki's [DAO directory](/wiki/daos) probed at `/llms.txt`, `/.well-known/agent-card.json`, `/.well-known/agent.json` and `/.well-known/mcp.json` under a browser user-agent with redirects followed; positives re-probed at a control path and separated from single-page-application fallbacks by response content type; all 18 `llms.txt` files retrieved and read in full.

## Voter apathy and governance participation

URL: https://caper.network/wiki/dao-governance/concepts/analysis/voter-apathy
Updated: 2026-08-11

| Concept | Voter apathy / low governance participation |
| --- | --- |
| Also called | Rational abstention, voter fatigue, the "phantom quorum" |
| What it is | The persistent gap between who _can_ vote in a DAO and who actually does — usually a small single-digit fraction of eligible token holders |
| Typical turnout | Median **~4.16%** of holders across 50 studied DAOs; individual participation often **under 2%**; frequently **<10%**, the threshold below which a handful of holders dominate outcomes ([Feichtinger/Fritsch et al., 2025](https://arxiv.org/abs/2504.11341)) |
| Main drivers | Negligible marginal influence, rational ignorance, proposal complexity, no direct upside to voting, delegation drift |
| Common mitigations | Delegation, quorum design, incentivized voting, proof-of-participation, futarchy, personal AI voting agents |
| Related | [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) · [Voting & delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) |

**Voter apathy** is the single most durable finding in the empirical study of on-chain governance: across almost every DAO measured, the overwhelming majority of eligible token holders never vote. A protocol can distribute a governance token to tens of thousands of addresses and still decide its most consequential proposals with the active participation of a few dozen. The problem is not that DAOs lack voters on paper — it is that the paper franchise and the working franchise are two very different sets, and the gap between them is where governance quietly stops being decentralized.

## what the numbers actually look like

Participation is measured two ways, and they tell opposite stories. Counted by _heads_ — the share of eligible holders who cast a vote — turnout is dismal. A 2025 study of 50 DAOs spanning Ethereum, Polygon, and Arbitrum (6,930 proposals, 317,317 unique voting addresses, over 4.5 million members) found a **median participation rate of just 4.16%**, and set the working threshold that _below 10% turnout, governance tends to be dominated by a handful of token holders, undermining true decentralization_ ([arXiv 2504.11341](https://arxiv.org/abs/2504.11341)). Individual-holder participation in large protocols is routinely reported **under 2%**.

Counted by _voting power_ — the share of tokens that showed up — the same DAOs look far healthier, often 30–40%. That divergence _is_ the finding: the tokens vote, the people mostly don't. A separate study of 21 DAOs documented a "high concentration of voting rights" alongside "a remarkably high amount of pointless governance activity" — proposals that pass with the participation of almost no one ([Feichtinger, Fritsch, Vonlanthen & Wattenhofer, 2023](https://arxiv.org/abs/2302.12125)). You can watch the live version of this on [Tally](https://www.tally.xyz/) and [Snapshot](https://snapshot.box/): proposal after proposal clearing with a voter set that is a rounding error against the holder base.

The [Sandbox DAO](/wiki/daos/social/the-sandbox-dao) is a rare case where the whole decay is visible in one place, because all 39 of its proposals sit in a single public [Snapshot space](https://snapshot.org/#/s:sandboxdao.eth). Its budget proposal drew 1,161 voters in May 2024; the proposal that [paused the DAO](https://snapshot.org/#/s:sandboxdao.eth/proposal/0xd4e77cc75434f71ac27e78cd62f92ec07e0cee59cc673c68f2a1949d56d99a4f) in February 2026 drew 33 — a 97% collapse in voters while the voting power behind each result went _up_. The 30,000,000-VP quorum never once stood in the way, which is the practical lesson: a quorum denominated in tokens cannot detect an electorate walking out.

## why holders don't vote

Apathy in a DAO is not laziness; it is usually the _rational_ response to the incentives on offer.

- **Negligible marginal influence.** Under [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), a small holder's vote almost never changes an outcome a whale has already decided. The expected value of voting rounds to zero, so the effort of reading a proposal is pure cost.
- **Rational ignorance and complexity.** As Vitalik Buterin put it when arguing DAOs must move past coin voting, "there are many thousands of decisions to make, involving many domains of expertise, and most people don't have the time or skill to be experts in even one" ([CoinDesk, Feb 2026](https://www.coindesk.com/web3/2026/02/21/ethereum-s-vitalik-buterin-proposes-ai-stewards-to-help-reinvent-dao-governance)). Proposal fatigue compounds it: the more governance a DAO produces, the less any single vote is worth reading.
- **No direct upside.** Voting is unpaid civic work with a diffuse benefit and a private cost. Nothing accrues to the holder who votes that does not equally accrue to the holder who free-rides.
- **Delegation drift.** Systems like [Compound](https://docs.compound.finance/governance/), [Uniswap](https://docs.uniswap.org/concepts/governance/overview), and [ENS](https://docs.ens.domains/dao/) let holders delegate their voting power. Delegation is meant to concentrate _expertise_; in practice it concentrates _power_, as most holders delegate once, to a large or default delegate, and never revisit — turning an apathy problem into a centralization problem.

## the mitigation ladder — and where each rung breaks

Every serious DAO has tried to close the participation gap. None of the fixes is free.

- **Delegation.** Cheapest and most common. Raises effective turnout by voting power but, as above, hands standing influence to a few delegates — and delegates themselves go inactive.
- **Quorum design.** Setting a minimum turnout for a vote to count guards against a tiny minority ramming a proposal through. Set too high, quorum becomes a _veto by absence_: good proposals die because not enough apathetic holders showed up to legitimize them. See [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) on the "phantom quorum," where low participation becomes an outright attack surface.
- **Incentivized voting.** Paying people to vote — directly, or via [vote markets](/wiki/dao-governance/concepts/voting/vote-markets) and bribe marketplaces — reliably raises turnout, and just as reliably rewards showing up over thinking, inviting vote-buying and mercenary participation.
- **Ballot privacy.** Hiding the running tally is meant to stop the trailing side from giving up – the explicit rationale Snapshot gives for shielded voting. Aave's two-month controlled trial measured the opposite: unique voters fell from 32.6k to 14.2k once shielding was on ([private and shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting)).
- **Proof-of-participation and identity.** Weighting by contribution or verified personhood (see [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos)) tries to make participation, not capital, the franchise. Buterin has argued for exactly this direction — "proof-of-humanity" and "proof-of-participation" over pure coin voting ([Moving beyond coin voting governance, 2021](https://vitalik.eth.limo/general/2021/08/16/voting3.html)) — but robust, un-gameable personhood remains unsolved.
- **Prediction-market governance.** [Futarchy](/wiki/dao-governance/concepts/voting/futarchy) sidesteps turnout by asking markets, not voters, to price outcomes — trading the apathy problem for a market-manipulation and metric-choice problem.
- **Personal AI voting agents.** The newest proposal: each holder deploys a personal AI, trained on their own stated values, to vote on the thousands of routine decisions they would otherwise ignore, escalating only critical questions to humans — with zero-knowledge proofs to guard against coercion and whale-watching ([Buterin, Feb 2026](https://www.coindesk.com/web3/2026/02/21/ethereum-s-vitalik-buterin-proposes-ai-stewards-to-help-reinvent-dao-governance)). Unproven, and it moves the trust question from delegates to model-training.
- **Paying delegates to turn up.** Arbitrum, Optimism and Uniswap each buy participation in a different currency — cash per vote, funded council seats, and delegated weight respectively. Their own published ledgers show the ceiling: attendance rises, deliberation does not, and the largest professional delegates still leave when their economics change ([delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs)).

## why apathy is a governance risk, not just a metric

Low turnout is dangerous precisely because it lowers the cost of capture. If a proposal needs 4% of tokens to pass and the median voter set is 4%, an attacker — or an insider — does not need a majority of the DAO; they need a majority of the tiny slice that bothers to vote. Apathy converts a large, diffuse token holder base into a small, capturable electorate, and it launders that capture into the language of "the community approved it." This is the through-line from participation to the failure modes catalogued in [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) and the health signals tracked in [DAO metrics and analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics): turnout is not a vanity number, it is the denominator that every legitimacy claim divides by.

**What that looks like when it happens.** In July 2026 an attacker drained roughly **$20 million** from [BonkDAO](/wiki/daos/social/bonkdao) by buying just enough BONK to clear a quorum set at 1% of supply, then voting for their own proposal. Seven wallets voted, out of more than 18,000 members — a turnout of about **2.9%** — and the attacker's stake was **99.878%** of everything cast ([CoinDesk](https://www.coindesk.com/markets/2026/07/07/bonk-faces-usd20-million-treasury-drain-after-attacker-spends-usd4-million-to-pass-malicious-proposal)). The quorum threshold was not the safeguard it looked like: in a DAO whose real turnout hovers around the threshold, the quorum number is simply the price list for the treasury. Apathy is what set that price.

**Measured turnout can also understate objection.** Under the two most common quorum configurations – Compound's `quorum=bravo`, where only For votes count toward the floor, and OpenZeppelin's default `quorum=for,abstain`, where For and Abstain count but Against still does not – a delegate who wants to block a proposal by denying it quorum does better by not voting at all than by voting against it. On contested proposals, organised opposition is rationally silent, and an abstention is materially a contribution toward passage rather than a neutral act. Some of what a turnout chart records as apathy is therefore a strategy the counting rule rewards; see [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design).

**And what it looks like when nobody attacks anything.** Capture is the dramatic case; the ordinary one is slower. [Quantum Biology DAO](/wiki/desci/ecosystem/quantum-biology-dao)'s complete [Snapshot record](https://snapshot.box/#/s:qbio.eth) runs from 46 voters on its first proposal in January 2025 to a median of **10** across the ten proposals it held in 2026, while voting power per proposal rose from 23 million to as much as 210 million tokens — the two halves of the same movement. Three wallets hold the DAO's entire 150,000,000-token vesting allocation, 50,000,000 each, and all three are listed administrators of the voting space; because the vesting token counts at parity with the liquid one, they carry 27% of the votable supply on tokens they cannot sell. The only proposal ever defeated there was the annual budget, on the highest turnout since launch week — after which the same budget passed as four separate line items, each unanimous, each on 6 to 11 voters. Nothing was stolen and no rule was broken. The electorate simply shrank until the outcome stopped depending on it.

**The limit case is a venue that never convened at all.** [Yield Guild Games](/wiki/daos/social/yield-guild-games) distributed a governance token to a holder base in the tens of thousands and opened an [official Snapshot space](https://snapshot.box/#/s:yieldguild.eth) in October 2021. Queried through [Snapshot's GraphQL hub](https://hub.snapshot.org/graphql), that space's `proposalsCount` is **1**: a November 2021 subDAO question carried by 74 voters and 621,186.75 YGG — 0.062% of the token's supply — against zero opposed. Nothing followed it. When YGG shut its publishing arm in July 2026, retiring two of its own games, releasing 35 people and redirecting a $20.6 million treasury into a different industry, the announcement was a company blog post. There was no losing vote to point at, because there was no vote. Turnout statistics cannot see this failure mode at all: a DAO with one proposal has no turnout series, and a dashboard that ranks by participation rate simply omits it.

## how Caper approaches this

Caper does not try to nag holders into voting. It makes participation _load-bearing_ in the one place holders already care about — their claim on the treasury. A member's [vote weight](/wiki/governance/voting) is the product of two things they actually did: how much of the token they hold, _and_ how much they have voted. A large position that never votes contributes nothing to weight; conviction has to be spent, not merely owned. Because that same weight is what governs a member's [exit share](/blog/the-exit-right) of the treasury, sitting out has a real, personal cost rather than a purely civic one — which is a very different pressure on apathy than an unpaid ballot.

The other half of the answer is the [exit right](/blog/the-exit-right): a holder who disagrees, or simply disengages, is not forced to keep legitimizing decisions by their presence in the cap table. They can leave with their weighted share instead of becoming an apathetic vote that a captured process rubber-stamps. See [What is a caper](/wiki/foundations/what-is-a-caper) and [Voting mechanisms](/wiki/governance/voting-mechanisms) for how weight and exit are computed.

## Who pays to execute a passed proposal

URL: https://caper.network/wiki/dao-governance/concepts/analysis/proposal-execution-costs
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Cost class** | Execution of an already-passed proposal (the transaction that carries out the decision) |
| **Industry default** | Permissionless and caller-paid: `execute()` is `payable` with no access control in both [OpenZeppelin Governor](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol) and [Compound Governor Bravo](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) |
| **Who actually pays** | Whichever member, delegate or bot sends the transaction. Nothing is reimbursed |
| **Market price of the same work** | Chainlink Automation: gas plus a per-network node premium plus 80,000 gas overhead. Gelato: a compute-unit subscription from $0 to $399/month, autoscaling at $40 per 1M units |
| **Where it appears in DAO budgets** | Nowhere. It is absent from every published governance budget surveyed in [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) |
| **Related** | [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) · [Governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) · [Governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization) · [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) |

A [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) vote that passes does not do anything. Somebody still has to send the transaction that carries the decision out, and that transaction costs money. On almost every token DAO in production, nobody has decided who that somebody is, nobody has priced the work, and the cost appears in no budget. This page sets out what the default actually is in deployed governance code, what the same job costs when a DAO buys it from an automation vendor instead, and why an unowned recurring cost is a governance problem rather than an accounting footnote.

## The default: permissionless and caller-paid

The two contracts that most token DAOs inherit their governance from agree on this, and both are explicit about it in source.

OpenZeppelin's `Governor` declares the final step as `function execute(address[] memory targets, uint256[] memory values, bytes[] memory calldatas, bytes32 descriptionHash) public payable virtual returns (uint256)`. It is `public`, it is `payable`, and it carries no access-control modifier: any address may call it once the proposal is in a succeeded state ([Governor.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol)).

Compound's `GovernorBravoDelegate`, the lineage behind a large share of the DeFi DAOs that followed, declares `function execute(uint proposalId) external payable`, and its only guard is a state check: `require(state(proposalId) == ProposalState.Queued)`. There is no check on who the caller is ([GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol)).

Permissionless execution is a deliberate and good design. It means a passed proposal cannot be strangled by an executor who declines to act, which is a real failure mode for any design that hands the final step to a named party. But permissionless is not the same as free. Because the function is a normal transaction, the caller pays the gas, and because there is no reimbursement path in either contract, the caller absorbs it. The DAO gets its decision carried out and never records what carrying it out cost, or who bore it.

The size of the bill is not trivial for the proposals that matter most. Execution runs every call in the proposal's batch, through a timelock in the Bravo design (the [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) sets out that queue-then-execute sequence), so a proposal that touches several contracts pays for several calls in one transaction. The heavier the decision, the heavier the transaction, and the more it costs whoever happens to click the button.

## What the same work costs when you buy it

The clearest way to see that execution is real work with a real price is to look at what the automation market charges for it. These are the vendors a DAO hires when it decides not to rely on a volunteer.

**Chainlink Automation** prices an "upkeep" as the gas the transaction actually consumed, plus a node-operator percentage premium that varies by network, plus a fixed **80,000 gas** of overhead for the call from the node into the registry. Chainlink's own worked example is a Polygon mainnet upkeep that used 110,051 gas at a gas price of 182,723,799,380 wei, with the node premium on Polygon at **70%** at the time, producing a fee of 0.008077 LINK ([Automation billing and costs](https://docs.chain.link/chainlink-automation/overview/automation-economics)). Two structural details matter more than the number. The upkeep must be **pre-funded** and hold a running balance above a minimum sized for a gas spike, or the network simply stops performing it. And withdrawing that balance requires cancelling the upkeep, with a **0.1 LINK** cancellation fee charged to any upkeep that never spent 0.1 LINK over its lifetime, explicitly to deter registrations that never perform.

Chainlink's documentation index now steers new integrations away from Automation and toward its Runtime Environment, instructing readers to "prefer CRE for new multi-step, offchain, or automation workflows unless another product is explicitly required", and to consider Automation only where a task requires it or an existing integration is being maintained ([docs.chain.link documentation index](https://docs.chain.link/llms.txt)). A DAO that wired its execution into a vendor product is holding a dependency whose vendor is redirecting new work elsewhere, which is the pattern set out in [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity).

**Gelato** prices the same category as a subscription in compute units rather than per transaction: a free tier at 10M units, Pro at **$99** per month for 20M, Growth at **$399** per month for 100M, and autoscaling beyond the plan at **$40 per 1M** compute units ([Gelato pricing plans](https://docs.gelato.cloud/pricing/pricing-plans)). The shape is the interesting part. Gas is a per-event cost; a subscription is a standing one. A DAO that buys execution as a subscription pays in the months it passes nothing, which is precisely the cost profile a governance budget is built to hold, and precisely the line no surveyed DAO has.

Both vendors are pricing the same thing the Governor contracts hand to a volunteer for nothing: somebody watches for a condition, and when it is met, somebody sends and pays for a transaction.

## The other answer: stop making it a proposal

A second response to the same pressure is not to price execution but to remove most of it. In January 2026 Aragon set out a direction it calls policy plugins, arguing that proposal-based governance "treat[s] every action as what is effectively an onchain referendum" and that the operational reality of an organization is "repeated, structured, and predictable" rather than novel. Under that model an organization configures a rule once for a bounded, known action type, and the system then executes matching transactions with, in Aragon's words, "no discretionary involvement or trusted intermediaries", reserving proposals for genuinely novel decisions such as protocol upgrades or changing the policies themselves ([Beyond Proposals Pt. I: Automation and the Art of Not Governing](https://blog.aragon.org/beyond-proposals-pt-i-automation-and-the-art-of-not-governing/)).

This does not make execution free either. It converts a recurring per-proposal cost into a standing infrastructure cost and moves it from the member who clicks to whoever operates the policy, which is a different distribution rather than an absence. What it does change is the denominator. A DAO that routes payroll, vendor top-ups and rebalancing through a policy stops paying the full deliberate-decide-execute cycle for transactions whose decision was already made, and that cycle, not the gas, is the expensive part. It is the same argument [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization) makes about scope, applied to the execution step specifically.

## Why the cost stays invisible

Three properties keep this off every ledger, and they compound.

1. **It is paid in the wrong currency by the wrong party.** The DAO's budget is denominated in its treasury assets and spent by proposal. Execution gas is paid in the chain's native token out of a private wallet. No treasury outflow occurs, so no accounting system sees an expense at all.
2. **It has no owner, so it has no reporter.** Every other governance cost surveyed in [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs), from steward compensation to strategy firms to legal entities, has a party who requested a budget and therefore reports against it. Execution has no requester. A cost class with no claimant produces no line item, whatever its size.
3. **Success looks identical to a subsidy.** When a delegate or a protocol team quietly executes every proposal out of its own pocket, the DAO observes proposals landing on time and concludes the process works. The subsidy is only visible on the day it stops, which is the same information failure [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) identifies in dependencies that are maintained by goodwill until they are not.

The practical consequence is a concentration nobody chose. In practice the party that executes is usually the protocol's own core team or a small number of committed delegates, because they are the ones watching. That is a soft form of the executor role the permissionless design was written to avoid, arrived at through cost rather than through code, and it is invisible to anyone reading the contracts. A DAO that wants to know whether it has this exposure can answer it directly: pull the `ProposalExecuted` events for the last year and count distinct senders. If the answer is a handful of addresses, the DAO has an unfunded operational dependency on those addresses, whatever its governance documentation says.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) treats settling a proposal as the caper's own cost rather than the settler's, and funds it from the fee that proposal already paid in.

Every call on the settle path draws gas against a per-proposal allowance held in the treasury. The per-call draw is capped at `SETTLEMENT_GAS_PER_CALL`, currently 5 XRD, and the per-proposal allowance at `SETTLEMENT_GAS_BUDGET`, currently 500 XRD, which is the same figure as the default proposal fee. The per-call figure is a ceiling rather than a charge: the engine refunds the unconsumed part of a fee lock, so overshooting costs allowance precision rather than funds. Because the allowance is sized to what the proposal contributed, a proposal funds its own execution and cannot draw the treasury down past its own fee. When the allowance is exhausted, the method still runs and the caller pays, so the design degrades to the industry default rather than bricking.

The mechanism that makes this safe is small and worth naming. The treasury draws with a _contingent_ fee lock. A plain fee lock on the Radix engine is a force-write: it takes the XRD and survives a transaction abort, while the ledger write recording the draw does not. Under a plain lock, anyone could call a settle-path method, abort, and drain the treasury while the allowance counter rolled back. The contingent lock ties the payment to the transaction committing.

The honest limits: this covers the settle path for a caper's own proposals, not arbitrary automation, and it moves the cost onto proposers rather than removing it, since the proposal fee that funds settlement is paid by whoever proposes. The full mechanic, including which of the three draw sites gasses a read and which gasses a write, is on [execution](/wiki/governance/execution), and the fee schedule itself is admin-configurable rather than constant, as [proposals](/wiki/governance/proposals) sets out.

## References

- OpenZeppelin, [Governor.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol). The `execute` declaration, read from source.
- Compound, [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol). The `execute` declaration and its single state guard, read from source.
- Chainlink, [Automation billing and costs](https://docs.chain.link/chainlink-automation/overview/automation-economics). Fee formula, the 80,000 gas overhead, the Polygon worked example, minimum balance and the 0.1 LINK cancellation fee.
- Chainlink, [documentation index](https://docs.chain.link/llms.txt). The instruction to prefer CRE for new automation workflows.
- Gelato, [Pricing plans](https://docs.gelato.cloud/pricing/pricing-plans). Plan tiers, compute-unit allowances and the autoscale rate.
- Aragon, [Beyond Proposals Pt. I: Automation and the Art of Not Governing](https://blog.aragon.org/beyond-proposals-pt-i-automation-and-the-art-of-not-governing/), 19 January 2026. Policy plugins and the case for reserving proposals for novel decisions.

## Cross-chain governance and multi-chain execution

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/cross-chain-governance
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | How a DAO that votes on one chain executes decisions on another – and what the message carrier costs it |
| **Core problem** | Whatever transports a passed proposal inherits the DAO's authority. Forge the message and you are the governor. |
| **Pattern 1 – one voted-in bridge** | Uniswap picks a bridge per deployment by governance vote (Wormhole for BNB Chain, [Jan 2023](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852)) |
| **Pattern 2 – consensus across bridges** | Aave's [a.DI](https://github.com/bgd-labs/aave-delivery-infrastructure) requires 3-of-4 or 2-of-3 independent adapters to agree on the routes where no canonical bridge exists |
| **Pattern 3 – exit through the rollup** | Arbitrum's DAO votes on L2 and executes via an L2→L1 message plus a challenge period: [≈37 days](https://docs.arbitrum.foundation/dao-constitution) for a Constitutional AIP |
| **Failure of record** | Nomad's August 2022 exploit stranded Uniswap deployments governance had already approved; both had to be re-legislated with a new bridge |
| **Caper's position** | Single-ledger. Vote, treasury and execution settle in one atomic transaction, so there is no carrier to trust or lose. |

**Cross-chain governance** is what a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) needs when the chain it votes on is not the chain it controls. The token, the governor contract and the vote live in one place; the pools, the treasury positions or the protocol deployments live somewhere else. Between the two sits a message – and that message is the whole problem.

A passing vote is not an action. Something has to carry the result from the governor to the contract that will obey it, and whatever does the carrying holds the DAO's authority for the duration of the trip. If an attacker can forge a message that appears to come from the governor, they do not need tokens, delegates or a quorum; they are the governor. This page covers the three patterns in production, the failure that proved the point, and what each one actually costs.

## Pattern one: vote on the bridge itself

Uniswap's expansion to BNB Chain in early 2023 is the clearest case of a DAO treating its message transport as a governance decision rather than an implementation detail, because it held two separate votes: one on _whether_, one on _through what_.

The first temperature check, [“Should Uniswap v3 be deployed to BNB Chain?”](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xa3c7247632d3a08e4e73a63867908d0cd4402f48fa673945f93e3197dee5450a), closed on 22 January 2023 with 20,066,279 UNI for and 4,928,281 against across 6,495 votes – 80.3% of the weight cast. The second, ten days later, asked [“Which bridge should Uniswap v3 use for cross-chain governance messaging between Ethereum and BNB Chain?”](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852) and offered four answers. It closed on 31 January 2023 with 8,348 votes and 45,581,689 UNI of weight distributed as follows.

| Bridge | UNI weight | Share |
| --- | --- | --- |
| Wormhole | 28,403,915 | 62.3% |
| LayerZero | 17,173,339 | 37.7% |
| deBridge | 3,773 | <0.01% |
| Celer | 663 | <0.01% |

Read the second table as what it is: a token-weighted electorate choosing which third party may hold its protocol's admin authority on another chain. The DAO recognised the awkwardness immediately. In the same month the Uniswap Foundation opened a [Cross-Chain Bridge Assessment Process](https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148) to fund an independent review – four engineers and a project manager, compensated at $300 and $200 per hour, explicitly barred from having "a vested interest in any bridge" – whose deliverable was a review that "identifies risk vectors to Uniswap governance, assigning them a risk level (Green, Yellow, Red)" and a recommendation on selecting providers, including "diversifying deployments across a set of trusted bridges (on a 1/n basis, or otherwise)."

## What happens when the carrier dies

Uniswap governance approved a v3 deployment on Gnosis Chain in April 2022, with Nomad as the governance bridge. On 1 August 2022 Nomad was drained of roughly $190 million after an upgrade initialised its trusted root to zero, making every message [provable by default](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd). The deployment was never delivered.

Eleven months later the Gnosis team returned to the Uniswap forum to ask for the same decision again, noting that the deployment [“has been put on hold because the proposed bridge provider (Nomad) is no longer an option”](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724) and proposing Wormhole in its place. Moonbeam followed within a fortnight, describing itself and Gnosis as [“both communities … in limbo with an approved license but without a deployment”](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-moonbeam-with-different-bridge-provider/20831).

This is the load-bearing lesson of cross-chain governance, and it is not about bridge security. Both DAOs had _already decided_. Quorum was met, the vote passed, the record stands. What expired was the transport, and because the decision could only be delivered through that transport, the decision expired with it. A DAO's proposal is durable exactly as long as the mechanism that carries it, and re-legislating an unchanged decision costs a fresh forum cycle, a fresh temperature check and a fresh on-chain vote – Uniswap ran that whole loop under the deadline of its v3 business-source licence expiring on 1 April 2023.

The corollary is a design question worth asking before a deployment, not after: if the bridge in this proposal is compromised or wound down, does the proposal fail closed, or does it need to be voted again? See [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) for the same failure in other parts of the stack.

## Pattern two: require several carriers to agree

Aave's answer is to stop trusting any single bridge. [a.DI (Aave Delivery Infrastructure)](https://github.com/bgd-labs/aave-delivery-infrastructure) describes itself as "a cross-chain communication abstraction layer for decentralised systems like the Aave DAO to communicate across networks, minimising the risk of underlying individual bridge provider failures, via consensus rules." Messages hub through Ethereum: a `CrossChainController` on Ethereum forwards to every governed network, and a message is only acted on once the required number of independent adapters have delivered an identical copy.

The consensus rule is per route, and the repository's deployment table publishes each one. Read on 11 August 2026, twenty-one non-Ethereum networks are listed:

- **3-of-4** – Polygon, in both directions.
- **2-of-3** – Avalanche (both directions), BNB Chain, Gnosis, Celo, Sonic and Plasma.
- **1-of-1** – the remaining fourteen: Arbitrum, Optimism, Base, Metis, Scroll, Polygon zkEVM, Linea, zkSync, Soneium, Ink, Bob, Mantle, MegaETH and X Layer.

Two thirds of the routes running at a single adapter looks careless until you notice which ones they are: every 1-of-1 destination is an Ethereum rollup, where the single adapter is that chain's own canonical L1→L2 messaging and the trust assumption is the rollup's proof system rather than an external validator set. The redundancy is concentrated exactly where no such path exists. The principle generalises past Aave: **require independent confirmations in proportion to how much of the carrier you have to trust**, and stop paying for redundancy where the carrier is already the chain itself.

The adapters are themselves governed. a.DI's own changelog lists Aave proposals that updated the CCIP adapters, refreshed the native bridge adapters, and migrated the LayerZero adapter to V2 and the Hyperlane adapter to V3. A DAO that adopts this pattern acquires a permanent maintenance obligation: its transport layer is a standing item on its agenda, and every adapter upgrade is a governance vote about its own ability to govern.

## Pattern three: leave through the rollup's own door

The Arbitrum DAO votes on Arbitrum One and cannot execute there. Its [Constitution](https://docs.arbitrum.foundation/dao-constitution) routes a passed Constitutional AIP out to Ethereum and back, and publishes the clock:

- **Phase 4 – L2 waiting period.** "a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message," so that objectors can "initiate withdrawal of their funds or take other action on L2."
- **Phase 5 – the L2→L1 message.** "at least 1 challenge period of the rollup protocol" before the message finalises on Ethereum, "after any withdrawals initiated during or soon after the voting period have been recognized on L1."
- **Phase 6 – L1 waiting period.** A further three days, "so that users who initiated withdrawals or other L2-to-L1 messages have time to execute them on L1 before the AIP takes effect."
- **Phase 7 – implementation.** Execution "may happen on L1 or via a transaction sent from L1 to one or more Governed Chains."

End to end the Constitution budgets "37 days from the beginning of the temperature check in Phase 1 until an AIP is finally executed in Phase 7 for a Constitutional AIP, or 27 days for a Non-Constitutional AIP."

Nothing in that path trusts a third party – the carrier is the rollup's own proof system – and the whole cost lands in time. It is worth being precise about what the delay buys, because it is easy to mistake for procedural drag. Phases 4 and 6 are not review windows for the proposal; they are [exit windows](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) for the people it binds. The Constitution deliberately orders the clock so that a member who dislikes a passed AIP can complete a withdrawal to L1 _before_ the AIP takes effect. Trust-minimised cross-chain execution and a meaningful right of exit turn out to want the same delay, which is why [governance timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks) and bridge finality end up on the same schedule.

## Designing one: the questions that actually decide it

Every cross-chain governance system answers the same six questions, and the answers are what distinguishes the three patterns above:

- **Where does authority originate?** The chain holding the token and the governor is the chain whose reorgs, censorship and outages become governance risk everywhere else.
- **What carries the message?** A canonical rollup bridge, an external validator set, or several of the latter in agreement.
- **How many independent carriers must agree?** One is a single point of failure unless that one is the chain itself.
- **Who can change the carrier?** If adapters are upgradeable, the upgrade key is a second governor. Aave routes those changes through the same DAO vote; that is the conservative answer.
- **How long does the trip take, and who is protected by the delay?** Time in the path is not waste if it is the window in which members can leave.
- **What happens to passed-but-undelivered proposals if the carrier dies?** Uniswap's answer, learned the expensive way, was to vote again.

Related reading: [on-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs), and [security councils and emergency powers](/wiki/dao-governance/concepts/fundamentals/security-councils).

## How Caper approaches this

Caper does not solve cross-chain governance. It declines the problem, and the trade is worth stating in both directions.

A caper's vote, its treasury and its execution live on one ledger, and a passed proposal settles in a single atomic transaction. Verified against the contracts: a PAYOUT winner executes through `execute_proposal_payout`, which binds the frozen winning option and transfers from the treasury to the recipient recorded when the proposal was created – the source is explicit that the transfer "goes to the STORED, voted-on recipient, so no executor can redirect it," and a once-only guard means it cannot run twice. An INVEST winner runs entirely inside one method: the treasury's XRD is withdrawn, the target caper's tokens are bought and redeposited, and the XRD never reaches the worktop where it could be skimmed.

There is consequently no message in the path, no relayer, no adapter set to maintain, no consensus rule to tune, and no window in which a decision the members already made can be stranded by an unrelated protocol's failure. Nothing between the tally and the transfer can be exploited, deprecated or wound down, because there is nothing between them.

The cost is the plain one: a caper can act only on assets that exist on Radix. A DAO whose holdings span several chains needs one of the three patterns above, and should price the carrier accordingly. See [execution](/wiki/governance/execution) and [raising funds](/wiki/markets/raising-funds) for how a caper's treasury actually moves.

## References

- [Uniswap Snapshot – Temperature Check: Should Uniswap v3 be deployed to BNB Chain? (Jan 2023)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xa3c7247632d3a08e4e73a63867908d0cd4402f48fa673945f93e3197dee5450a)
- [Uniswap Snapshot – Temperature Check: Which bridge should Uniswap v3 use for cross-chain governance messaging between Ethereum and BNB Chain? (Jan 2023)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852)
- [Uniswap governance forum – Cross-Chain Bridge Assessment Process (Jan 2023)](https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148)
- [Uniswap governance forum – Continue the Uniswap V3 deployment on Gnosis Chain with different bridge provider (Mar 2023)](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724)
- [Uniswap governance forum – Continue the Uniswap V3 deployment on Moonbeam with different bridge provider (Mar 2023)](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-moonbeam-with-different-bridge-provider/20831)
- [bgd-labs/aave-delivery-infrastructure – a.DI specification, deployed addresses and per-route consensus rules](https://github.com/bgd-labs/aave-delivery-infrastructure)
- [The Arbitrum DAO Constitution – AIP phases, waiting periods and execution path](https://docs.arbitrum.foundation/dao-constitution)
- [Nomad – Bridge hack root cause analysis (Aug 2022)](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd)

## DAO governance models

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/dao-governance-models
Updated: 2026-08-05

|  |  |
| --- | --- |
| **Topic** | How DAOs allocate voting power and reach decisions |
| **Core question** | Who decides, and how is their weight measured? |
| **Main models** | Token-weighted · Quadratic · Conviction · Reputation · Multisig / optimistic · Futarchy |
| **Central trade-off** | Sybil resistance ↔ resistance to plutocracy & capture |
| **Modifier** | Vote-escrow (ve) lockups time-weight any of the above |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Voting mechanisms](/wiki/governance/voting-mechanisms), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

A **DAO governance model** is the rule that decides who holds voting power, how that power is measured, and how individual votes combine into a binding decision. It is the most consequential design choice a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) makes, because the model is encoded in a contract that runs without a referee and is exposed to anyone who can acquire, borrow, or manufacture voting weight. Every model is an attempt to sit somewhere useful on one central axis: **capital-weighted** (resistant to fake accounts, but plutocratic) versus **participation- or identity-weighted** (egalitarian, but fragile to one actor posing as many). This page surveys the families; the [voting mechanisms](/wiki/governance/voting-mechanisms) article goes deeper on the social-choice theory behind each, and [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) collects the post-mortems these models are built to avoid.

## Token-weighted voting

The on-chain default: voting power is proportional to governance tokens held, and a proposal passes when support clears a threshold, usually alongside a **quorum** (minimum participation) and a **proposal threshold** (minimum stake to submit). It is simple, legible, and Sybil-resistant by construction — buying influence means buying the scarce token. The dedicated [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) page covers its on-chain mechanics in depth; its weaknesses are equally well documented: **plutocracy** (whales decide), **voter apathy** (a small holder's vote rarely matters, so turnout runs in single digits), and **vote-buying**, since a voter who merely borrows tokens has, as [Vitalik Buterin argues](https://vitalik.eth.limo/general/2021/08/16/voting3.html), "no financial exposure" to the outcome. Forbes summarized a decade of research in 2026 under a blunt headline: [DAOs keep centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/). ([Chainlink: governance tokens](https://chain.link/article/governance-tokens-dao-voting))

## Quadratic voting

Quadratic voting (QV) lets a voter cast multiple votes on an issue, but the _cost_ rises with the square of the votes — one vote costs one credit, ten votes cost a hundred — so people buy influence roughly in proportion to how much they care, and no single party can cheaply dominate. Introduced to crypto by Buterin and Glen Weyl, QV surfaces intensity of preference rather than just direction. Its fatal on-chain flaw is identity: split your tokens across many wallets and the quadratic penalty evaporates, so QV is only safe atop a working [proof-of-personhood](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) layer. Its cousin **quadratic funding** applies the same math to donations and powers [Gitcoin Grants](https://www.gitcoin.co/). ([a16z governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## Conviction voting

[Conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) removes the deadline: voters stake tokens on the proposals they support and their **conviction** accumulates the longer the stake stays put, so a proposal executes once built-up conviction crosses a threshold scaled to how much treasury it asks for. Because conviction is time-weighted, last-minute rented-capital swings are useless — you cannot buy sustained conviction in a single block. Pioneered by the Commons Stack and first run in production by [1Hive's Gardens](https://github.com/1Hive/conviction-voting-app), it suits continuous funding decisions but rests on a capital-weighted base and is, by design, slow.

## Reputation-based voting

Reputation models grant voting power as non-transferable **reputation** earned through contribution rather than purchased on a market. Because reputation cannot be bought or sold, it resists the plutocracy and vote-buying that afflict tradable tokens — but it pushes the hard problem onto _how_ reputation is awarded, and it can ossify into an in-group if early members accumulate permanent advantage. Variants appear in [Moloch-style](https://daohaus.club/) share systems and in dedicated frameworks such as the original DAOstack/Genesis design.

## Multisig and optimistic governance

Not every DAO votes on everything. Many — especially early or small ones — delegate execution to a **multisig** (an _m_-of-_n_ [Safe](https://safe.global/) signed by trusted stewards), accepting some centralization for speed and safety. **Optimistic governance** formalizes this: a council or delegate can act unless token holders raise a challenge within a window, keeping day-to-day decisions cheap while preserving a tokenholder veto. [Optimism's Collective](https://gov.optimism.io/) runs a bicameral version (a Token House plus a non-token Citizens' House), and [Lido's Dual Governance](https://research.lido.fi/) gives stETH holders a safeguard veto over LDO votes.

## Futarchy

Futarchy, proposed by economist Robin Hanson, splits a decision in two: **"vote on values, but bet on beliefs."** Token holders democratically pick a success metric; [prediction markets](https://mason.gmu.edu/~rhanson/futarchy.html) then decide which proposal is most likely to raise it, and the market's verdict carries. It puts forecasts in the hands of those willing to stake money on them, but depends on liquid, hard-to-manipulate markets — which is why it remains more experimented-with than adopted. See the full breakdown in [Futarchy](/wiki/dao-governance/concepts/voting/futarchy).

## The vote-escrow modifier

Independent of which family a DAO picks, **[vote-escrow (ve)](/wiki/dao-governance/concepts/treasury/dao-tokenomics)** lockups time-weight voting power: lock tokens for up to four years and your weight scales with the lock length, then decays as it runs down. Popularized by [Curve's veCRV](https://curve.readthedocs.io/dao-vecrv.html), the aim is to hand the wheel to long-term aligned holders rather than transient capital — at the cost of liquidity and, in practice, a secondary market in vote "bribes" (the so-called Curve Wars).

## Choosing a model

There is no universally best rule. The choice trades off decentralization, resistance to manipulation, and broad participation — push hard on any one and the others give. Token voting buys Sybil-resistance and simplicity at the cost of equality; quadratic and reputation schemes buy equality at the cost of needing a trustworthy identity layer; conviction and ve-models buy resistance to rented capital at the cost of speed; and a handful of protocols sidestep the tradeoff entirely by [making their core rules immutable](/wiki/daos/stablecoins/liquity), leaving almost nothing to govern (a stance the [progressive-decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) literature calls governance minimization). Mature designs increasingly _combine_ stake with something money cannot cheaply buy — time, participation, or verified identity — and pair the rule with defenses against [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) like snapshotting weight at a past block. ([survey of DAO governance models](https://arxiv.org/html/2605.18990))

## How Caper approaches this

Caper takes the combining route. Decisions use [ranked-choice voting](/wiki/governance/voting) over [proposals](/wiki/governance/proposals) that can carry real on-chain actions, and weight that is the product of two things: the stake a member holds _and_ the participation they have actually shown, earned as non-transferable tokens minted one per vote. Because a member's very first vote counts for nothing and those participation tokens cannot be bought or borrowed, capital that just arrived — flash-loaned or freshly acquired — carries little to no weight, closing the flash-loan door without a past-block snapshot of holdings; influence accrues to members who show up rather than to capital passing through. That same earned weight sets each member's pro-rata claim on the treasury at [exit](/wiki/governance/execution) — voice and exit are the same number. The specifics live on the linked governance pages.

## References

- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).
- Chainlink, [Governance Tokens and DAO Voting](https://chain.link/article/governance-tokens-dao-voting).
- [A survey of DAO governance models](https://arxiv.org/html/2605.18990) (arXiv, 2026).
- Forbes, [DAOs Keep Centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) (2026).

## Governance minimization

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/governance-minimization
Updated: 2026-07-20

|  |  |
| --- | --- |
| **Topic** | The design school that a protocol's safest governance surface is the _smallest_ one — shrink what a token vote can change, ideally toward nothing |
| **Also called** | Minimal governance, governance-free design, "ungovernance," ossification |
| **Core claim** | Every governable parameter is a permanent, exploitable attack surface; removing the parameter removes the attack |
| **Theoretical root** | Vitalik Buterin's [credible neutrality](https://balajis.com/p/credible-neutrality) (2020); named the first of four principles in a16z's [“Machiavelli for DAOs”](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/) (2024) |
| **Spectrum** | Fully immutable ([Liquity](/wiki/daos/stablecoins/liquity) V1, [Reflexer RAI](/wiki/daos/stablecoins/reflexer-rai)) → minimized core + governed periphery (Uniswap) → fully governed (Compound, Aave) |
| **Key risk** | Immutable code cannot be patched — a latent bug or a stale parameter becomes permanent |
| **Mirror image** | [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) distributes the keys; governance minimization destroys them |

**Governance minimization** is the argument that the amount of a protocol a token vote can change should be kept as small as possible — and that for many protocols the right amount is zero. Where the mainstream DAO playbook treats an active governance layer as the goal, governance minimization treats it as a liability to be spent down: every parameter a vote can move is a lever an attacker, a cartel, or a regulator can try to seize, so the most robust protocol is the one with almost nothing left to govern. The position is not anti-governance so much as anti-_surface_ — it asks, of each governable knob, whether the ability to change it later is worth the standing risk that someone changes it against you.

## The theory: credible neutrality and governance as attack surface

The intellectual root is Vitalik Buterin's 2020 essay on [credible neutrality](https://balajis.com/p/credible-neutrality), which argues that a mechanism deciding high-stakes outcomes should be one where, in his words, "just by looking at the mechanism’s design, it is easy to see that the mechanism does not discriminate for or against any specific people." A governable parameter is in tension with that ideal: if a vote can redirect fees, mint tokens, or re-point an oracle, then the mechanism's behaviour depends on _who controls the vote_, and its neutrality is only as credible as its least-captured election.

a16z's Miles Jennings makes the operational case in [“Machiavelli for DAOs”](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/) (2024), where governance minimization is the _first_ of four principles for durable DAO design: reduce a protocol's reliance on, and the power of, its governance, because "eliminating all but essential governance would enhance the credible neutrality of a system" and lower the ongoing cost and risk of running it. The same reasoning drives the [governance-attack](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) literature: a low-quorum treasury vote or a flash-loaned proposal is only dangerous because there is a powerful lever on the other end of it. Take the lever away and the attack has nothing to grab.

## The spectrum, from immutable to minimally governed

Real protocols sit on a spectrum, not a binary. At the extreme, [Liquity](/wiki/daos/stablecoins/liquity) shipped its V1 as [governance-free](https://www.liquity.org/features/governance-free) contracts with no admin key — every parameter was fixed at deployment and, per its [own documentation](https://docs.liquity.org/v2-faq/general), the code "can never be changed"; LQTY is explicitly not a governance token. [Reflexer's RAI](/wiki/daos/stablecoins/reflexer-rai) went further and _removed_ its remaining controls in staged "ungovernance" steps until no new collateral types could ever be added.

A step in from the edge is the "immutable core, governed periphery" pattern. Uniswap's core AMM contracts are non-upgradeable, but UNI holders retain a narrow set of levers — most famously the [protocol fee switch](https://docs.uniswap.org/concepts/governance/overview) and the treasury — so the market itself is fixed while a thin governance layer decides only revenue and grants. Fully governed protocols such as Compound and Aave sit at the far end, where a vote can upgrade the very contracts users' funds sit in. Governance minimization is the claim that, all else equal, a protocol should move toward the immutable end of that line and keep only the governance it genuinely cannot do without.

## What governance usually can't eliminate

Even minimizers concede a residue of decisions that resist automation. In practice they cluster into three kinds: **protocol upgrades and maintenance** (re-pointing an oracle, deploying a fixed contract), **complex parameter setting** that markets can't self-tune (collateral factors, risk caps), and **[treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) decisions** (diversification, grants, incentives). The minimizer's discipline is to _scope_ the surviving governance tightly — Liquity V2, for instance, keeps a minimal vote whose only power is directing a slice of protocol revenue to liquidity incentives, and nothing else. The design question every DAO eventually faces, as the [progressive-decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) debate frames it, is not "how decentralized are we" but "how much of this should be governable at all," and governance minimization answers: as little as the protocol can survive with.

## The trade-off: ossification and the missing patch

The cost of destroying a lever is that you can never pull it again. Immutable code that ships with a latent bug cannot be patched, and a parameter that was right at launch can drift out of step with a market that immutability cannot follow — the same property that makes a contract un-capturable makes it un-fixable. Critics argue this trades one risk for another: a governed protocol can respond to an exploit or a black-swan de-peg, an "ungovernable" one can only watch. Minimizers answer that governance is itself the larger and more permanent risk, and that adaptability is better bought through [narrowly-scoped](/wiki/dao-governance/concepts/voting/token-weighted-voting), timelocked, veto-guarded levers than through a general-purpose vote over the whole system. Where a protocol should land on that trade-off depends on how much of its behaviour genuinely needs to change after launch — and how much is just a lever waiting to be seized.

## How Caper approaches this

Most protocols that pursue governance minimization freeze their _contracts_ but leave their _market_ — prices, issuance, fees — under a vote. A [caper](/wiki/foundations/what-is-a-caper) minimizes governance at exactly that layer. Its [bonding curve](/wiki/markets/bonding-curve) is fixed in the blueprint: the curve constant is a compile-time constant in the contract, and there is no proposal type and no admin call anywhere in the component that can reprice it. Issuance and redemption follow one immutable formula for the life of the caper, so the thing a member is most exposed to — the price at which they can enter and exit — is not something any majority can vote to change.

What remains governable is deliberately narrow and pointed at the treasury alone. The treasury moves only through a small set of typed, on-chain proposal paths — `PAYOUT`, `INVEST`, and `VOTE` — never through arbitrary calldata, and a passed proposal's execution is public: anyone can trigger it, and the treasury badge is presented as a proof inside the call rather than handed to a signer. In the vocabulary of this page, a caper is minimized _by construction_ rather than spent down over time: the market is immutable, the governable surface is the treasury and nothing more, and even that surface is scoped to three paths. It is the mirror of the ossification critique above — because a caper never makes its market governable, there is no market-lever for anyone to capture, and none to lose to a bug either.

## References

- [Vitalik Buterin — “Credible Neutrality As A Guiding Principle” (2020)](https://balajis.com/p/credible-neutrality)
- [a16z crypto (Miles Jennings) — “Machiavelli for DAOs,” part 1: principles](https://a16zcrypto.com/posts/article/machiavelli-principles-dao-decentralized-governance/)
- [a16z crypto — “Machiavelli for DAOs,” part 2: designing governance](https://a16zcrypto.com/posts/article/machiavelli-daos-designing-effective-decentralized-governance/)
- [Liquity — Governance Free](https://www.liquity.org/features/governance-free) · [Liquity V2 FAQ (minimal governance)](https://docs.liquity.org/v2-faq/general)
- [Uniswap — Governance Overview (immutable core, fee switch)](https://docs.uniswap.org/concepts/governance/overview)

## History of DAOs

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/history-of-daos
Updated: 2026-08-10

|  |  |
| --- | --- |
| **Topic** | History of decentralized autonomous organizations |
| **Idea coined** | "Decentralized autonomous corporation/organization," 2013–2014 |
| **First large DAO** | [The DAO](https://en.wikipedia.org/wiki/The_DAO), Ethereum, April 2016 (~$150M raised) |
| **Defining crisis** | The DAO hack, June 2016 — 3.6M ETH drained, Ethereum hard-forked |
| **Revival** | [MolochDAO](https://github.com/MolochVentures/moloch) (2019), DeFi protocol DAOs (2020) |
| **Legal milestones** | Wyoming DAO LLC (2021) · Marshall Islands DAO Act (2022) · Wyoming DUNA (2024) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) |

The **history of DAOs** is barely a decade long, but it already has the arc of a much older story: a bold idea, a spectacular early disaster, a humbled rebuilding, a mania, and a slow maturation into institutions that manage billions — while still wrestling with the problem they were invented to solve, the concentration of power. This page traces the [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) form from its origins to the present.

## Older roots (1995–2013)

Dating the form from 2013 understates its lineage. In ["A Prehistory of DAOs"](https://gnosisguild.mirror.xyz/t4F5rItMw4-mlpLZf5JQhElbDfQ2JRVKAzEpanyxW1Q) (2021), Kei Kreutler traces the political ideology decentralized organizations draw on — "knowingly or not" — to _Tribes, Institutions, Markets, Networks_, a 1995 RAND Corporation report by David Ronfeldt. Ronfeldt narrates societal evolution through four organizational forms, each with its own organizing principle: tribes (kinship), institutions (hierarchy), markets (competitive exchange), and networks (heterarchic collaborative exchange). Crucially, later forms do not replace earlier ones but grow within a newly circumscribed scope.

Kreutler's argument is that the network form — "small, scattered, and autonomous" groups collaborating across distance without a single organizational unity — describes what DAOs attempt, and that its natural home is neither the public nor the private sector but civil society. Read this way, the DAO belongs to a much older tradition of cooperatives and guilds, and the 2016 crash reads less as the beginning of the story than as one episode in it.

## Precursors and the idea (2013–2015)

The concept predates the first working example. Around 2013, Dan Larimer described "decentralized autonomous corporations" (DACs) in the context of BitShares, and in May 2014 Ethereum co-founder Vitalik Buterin published ["DAOs, DACs, DAs and More: An Incomplete Terminology Guide"](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide), defining a DAO as an entity with "internal capital" whose behavior is governed by code, with humans "at the edges." Ethereum's launch in July 2015 provided the general-purpose smart-contract platform the idea needed.

## The DAO and the fork (2016)

In April 2016 a team from Slock.it launched [**The DAO**](https://en.wikipedia.org/wiki/The_DAO), an investor-directed venture fund living entirely in an Ethereum contract. Its token sale raised roughly **$150 million** in ether from more than ten thousand participants — at the time the largest crowdfunding in history, holding around 14% of all ETH then in circulation.

On 17 June 2016 an attacker exploited a **reentrancy bug** in its split function and drained about 3.6 million ETH — then worth roughly **$50–60 million** — into a child DAO. After weeks of crisis debate, the Ethereum community [hard-forked the chain on 20 July 2016](https://www.coindesk.com/consensus-magazine/2023/05/09/coindesk-turns-10-how-the-dao-hack-changed-ethereum-and-crypto) to return the funds, and the minority that rejected the fork on "code is law" grounds kept the original chain alive as **Ethereum Classic**. The episode killed The DAO, prompted the SEC's 2017 report treating its tokens as securities, and set the terms of every later debate about [on-chain governance](/wiki/dao-governance/concepts/fundamentals/dao-governance-models): code executes exactly as written, including its bugs. ([Gemini Cryptopedia](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao))

## The quiet rebuilding (2017–2020)

For two years "DAO" was a scare word, but the machinery kept improving. [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) (2017) turned DAO deployment into a framework; MakerDAO — today [Sky](/wiki/daos/stablecoins/sky-dao) — proved a token-governed protocol could manage a live financial system. In February 2019 [**MolochDAO**](/wiki/daos/public-goods/molochdao) restarted the movement with the opposite philosophy to The DAO: a _minimum viable_ grants DAO of a few hundred lines, whose signature **ragequit** mechanism let any member exit with their pro-rata share of the treasury rather than be bound by a majority — the design ancestor of every [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) since.

Then DeFi gave DAOs their real economy. In June 2020 Compound began distributing its COMP governance token to users, igniting "yield farming"; in September 2020 Uniswap airdropped UNI and handed the protocol to a [token-holder DAO](/wiki/daos/dexs/uniswap-dao). Compound's Governor and Timelock contracts became the industry's standard governance stack, and gasless off-chain voting on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (2020) plus [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig treasuries completed the modern DAO toolkit.

## Mania and mainstream attention (2021)

2021 made DAOs a cultural phenomenon. The emblem was [**ConstitutionDAO**](/wiki/daos/social/constitutiondao), which raised about **$47 million from roughly 17,000 people in under a week** to bid on a first-edition copy of the U.S. Constitution — lost the Sotheby's auction by a hair, refunded its donors, and dissolved. It proved a DAO could form around a single goal at astonishing speed, and its post-auction refund chaos previewed the operational problems (gas costs, coordination, [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management)) the industry would spend years fixing.

## Legal recognition (2021–present)

Law began catching up. [Wyoming's DAO LLC law](https://www.legalnodes.com/article/wyoming-dao-llc) (effective July 2021) was the first U.S. statute to give DAOs limited liability as LLCs; the [Marshall Islands DAO Act (2022)](https://www.midao.org/blog-posts/marshall-islands-dao-llc-vs-cayman-foundation-full-comparison) created a dedicated offshore wrapper; and Wyoming followed with the member-managed **DUNA** (Decentralized Unincorporated Nonprofit Association) in 2024, designed for genuinely decentralized memberships. Regulators are now engaging directly with the form — in June 2026 Malta's financial regulator opened a [formal consultation on DeFi and DAO governance](https://www.newsbtc.com/news/malta-regulator-opens-defi-consultation-as-dao-governance-enters-policy/) under MiCA. Without a wrapper, courts have tended to treat DAO members as general partners with unlimited personal liability — the risk driving this whole workstream (see [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures)).

## Maturity and its discontents (2022–2026)

The current era is defined by scale and by governance stress-tests. DAO treasuries collectively passed [$25 billion by early 2026](https://coinlaw.io/decentralized-autonomous-organizations-statistics/), while the same tracking shows fewer than 1% of token holders controlling ~90% of voting power and typical turnout of 5–15%. The **Beanstalk** attack (April 2022) used a flash loan to seize a governance majority and drain [$182 million in a single transaction](https://a16zcrypto.com/posts/article/dao-governance-attacks-and-how-to-avoid-them/), making governance itself an attack surface. Longer-lived experiments wound down honestly — the Aragon Association dissolved in 2024 and returned its treasury to ANT holders (see [Aragon](/wiki/dao-governance/tooling/frameworks/aragon)), and in March 2026 [Tally](/wiki/dao-governance/tooling/voting/tally) — the hosted interface behind binding on-chain votes for over 500 DAOs — [shut down its hosted product](https://www.coindesk.com/markets/2026/03/17/gensler-and-biden-were-just-better-for-crypto-says-tally-ceo-as-dao-governance-platform-shuts-down), its CEO arguing that easing regulatory pressure had made DAO governance optional, before the platform continued as [Cactus under ScopeLift](https://scopelift.co/blog/tally-is-now-cactus) in a wider governance-tooling retrenchment. Meanwhile in 2026 the [ENS DAO](/wiki/daos/infrastructure/ens-dao) delivered the era's defining spectacle, its founder deploying roughly half of active voting power to block a Security Council renewal, while [researchers documented](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) why DAO power keeps re-centralizing. The frontier work — [alternative voting models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), treasury redemption votes like GnosisDAO's 2026 GIP-151 (see [rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)), AI-assisted governance — is all, one way or another, a response to the concentration problem the 2016 crash first exposed.

## How Caper approaches this

Read as one story, DAO history keeps failing at the same two points: power concentrates, and dissenting members have no clean way out. A [caper](/wiki/foundations/what-is-a-caper) is built around the second lesson especially — like Moloch's ragequit, every member holds a standing [exit](/wiki/governance/execution) right to a treasury share set by their canonical vote weight rather than by balance alone, and [voting weight](/wiki/governance/voting) grows with demonstrated participation rather than stake alone, so the ENS-style single-whale takeover is structurally harder. The linked Caper pages state those mechanics neutrally.

## References

- Kei Kreutler, [A Prehistory of DAOs](https://gnosisguild.mirror.xyz/t4F5rItMw4-mlpLZf5JQhElbDfQ2JRVKAzEpanyxW1Q) (Gnosis Guild, 2021) — cooperatives, guilds, and Ronfeldt's TIMN framework.
- Vitalik Buterin, [DAOs, DACs, DAs and More: An Incomplete Terminology Guide](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) (2014).
- Wikipedia, [The DAO](https://en.wikipedia.org/wiki/The_DAO) — raise, hack, and hard fork.
- CoinDesk, [How The DAO Hack Changed Ethereum and Crypto](https://www.coindesk.com/consensus-magazine/2023/05/09/coindesk-turns-10-how-the-dao-hack-changed-ethereum-and-crypto).
- Gemini Cryptopedia, [The DAO hack](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao).
- MolochDAO, [MolochVentures/moloch](https://github.com/MolochVentures/moloch) — the minimum-viable-DAO revival.
- Wikipedia, [ConstitutionDAO](https://en.wikipedia.org/wiki/ConstitutionDAO).
- a16z crypto, [DAO governance attacks, and how to avoid them](https://a16zcrypto.com/posts/article/dao-governance-attacks-and-how-to-avoid-them/) — Beanstalk.
- CoinLaw, [DAO statistics 2026](https://coinlaw.io/decentralized-autonomous-organizations-statistics/) — treasuries, concentration, turnout.

## Hyperstructures

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/hyperstructures
Updated: 2026-08-10

|  |  |
| --- | --- |
| **Topic** | Protocol design — unstoppable, fee-free on-chain infrastructure |
| **Coined by** | Jacob Horne (Zora), ["Hyperstructures"](https://jacob.energy/hyperstructures.html), January 2022 |
| **Criteria** | Unstoppable · free · valuable · expansive · permissionless · positive-sum · credibly neutral |
| **Central claim** | A protocol can be free forever to use and valuable to own at the same time |
| **Related** | [Governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization) · [Fee switches](/wiki/economics/fee-switches-and-value-accrual) · [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) |

A **hyperstructure** is, in Jacob Horne's 2022 definition, a crypto protocol that ["can run for free and forever, without maintenance, interruption or intermediaries"](https://jacob.energy/hyperstructures.html). The term names a class of on-chain infrastructure rather than a specific technology: any protocol meeting the criteria below qualifies, and — as the essay is careful to stress — being built on a blockchain is not by itself sufficient.

The essay has become one of the standard references for the argument that a protocol need not extract fees from its users in order to be worth owning, and it supplies much of the vocabulary now used when a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) debates whether to switch on a protocol fee.

## The seven properties

Horne lists seven characteristics, all of which a protocol must have to count as a hyperstructure:

- **Unstoppable** — "the protocol cannot be stopped by anyone. It runs for as long as the underlying blockchain exists."
- **Free** — "there is a 0% protocol wide fee and runs exactly at gas cost."
- **Valuable** — "accrues value which is accessible and exitable by the owners."
- **Expansive** — "there are built-in incentives for participants in the protocol."
- **Permissionless** — "universally accessible and censorship resistant. Builders and users cannot be deplatformed."
- **Positive sum** — "it creates a win-win environment for participants to utilize the same infrastructure."
- **Credibly neutral** — "the protocol is user-agnostic."

The properties are presented as consequences of one another rather than as an arbitrary list. Unstoppability is the root: because a deployed contract needs no operator, labour, or subsidy to keep running, there is no ongoing cost that a protocol fee has to cover, which is what makes "free" affordable in the first place. Permissionlessness and credible neutrality then remove the reasons anyone would rebuild the same thing elsewhere, which is what makes the environment positive-sum. On the last point Horne explicitly follows Vitalik Buterin's 2020 argument for credible neutrality, also discussed under [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization).

## The threat of the fee

The essay's most contested claim is that a protocol can be "simultaneously free forever to utilize and extremely valuable to own." Ownership, in this account, is not a claim on revenue but the control of a [fee switch](/wiki/economics/fee-switches-and-value-accrual) that has not been flipped — what Horne calls **"the threat of the fee"**.

The argument is that actually turning the fee on is value-destructive, because it "would immediately lead to an incentivized fork, since there's now a clear reason for new entrants to do it themselves." The right to switch it on is therefore analogous to an NFT owner's right to burn: a rational owner will not exercise it, but the fact that they could is what makes the position worth something. Horne treats the right to sell or transfer the switch as the second ownership right, since that is what lets a market put a price on it. The wider claim drawn from this is that "for-profit" is a "skeuomorphic mode of operation" — that value creation and profit extraction have come apart, and a protocol can be built "for-public" instead.

This is the mechanism behind long-running governance debates such as the [Uniswap](/wiki/daos/dexs/uniswap-dao) fee switch, where the decision facing token holders is precisely whether to convert a latent threat into realised revenue.

## Expansive fees

"Free" applies to the protocol-wide fee, not to every payment inside the system. Hyperstructures are expected to carry **expansive fees**: incentives "utilized by anyone adding value in a codified manner on top of the protocol," open to the whole ecosystem rather than accruing to the protocol's operator.

Horne's worked example is the Uniswap liquidity-provider fee, which pays anyone supplying the resource the protocol needs — liquidity — and "is not paid to Uniswap"; the second is Zora's finder's fee, which pays whoever brings the eventual buyer. The general rule the essay draws is that in a hyperstructure "any participant's value captured is synonymous with their value generated," and that a system permitting any party to extract value without creating it is not a hyperstructure.

## What does not qualify

The essay spends as much effort on exclusions as on the definition, since most of what is colloquially called a protocol fails at least one criterion. Two of its own counterexamples:

- **Dependence on off-chain infrastructure.** The Wyvern protocol used by OpenSea "cannot operate without offchain orders being maintained in a privately operated database" — so if the platform goes down, the market goes with it. Being protocol-based is not enough; a hyperstructure is "entirely onchain."
- **Upgradeable admin control.** A fully on-chain protocol whose administrators can "completely upgrade and change the rules" is, in the essay's terms, still a platform rather than a hyperstructure — the same reasoning that makes immutability central to [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization).

Horne is explicit that these are not criticisms: such systems "are just not Hyperstructures." The distinction matters mainly because the label carries a promise to builders — that anything built on top cannot later be deplatformed or repriced.

## How Caper approaches this

The hyperstructure criteria are a useful yardstick precisely because most protocols, [capers](/wiki/foundations/what-is-a-caper) included, do not clear all seven. Caper charges protocol fees rather than running at gas cost, so it is not "free" in Horne's strict sense; the fee levers and where the proceeds go are set out on [bonding curve](/wiki/markets/bonding-curve) and [raising funds](/wiki/markets/raising-funds).

Where the frames do overlap is on the properties Horne roots the rest in. Caper's contracts are deployed on Radix and its market is permissionless and always-on, so a caper's holders are not relying on an operator to stay in business in order to trade or govern; and the essay's "valuable" criterion — value that is "accessible and exitable by the owners" — is close to the reasoning behind a caper's standing [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). The honest reading is that Caper adopts the exit and permissionlessness arguments while rejecting the zero-fee one.

## References

- Jacob Horne, [Hyperstructures](https://jacob.energy/hyperstructures.html) (jacob.energy, 16 January 2022) — the source of the definition and all quotations above.
- Related reading on this wiki: [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization), [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual), [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization).

## On-chain vs off-chain governance

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | Where a DAO's votes are cast and enforced |
| **Off-chain** | Gasless signed messages, stored on IPFS — a _signal_ (Snapshot) |
| **On-chain** | Votes + execution in a contract — _binding_ and trustless (Governor) |
| **Common pattern** | Off-chain temp check → on-chain formal vote → timelocked execution |
| **Bridges** | SafeSnap (Zodiac Reality) – post an off-chain result on-chain, executable unless challenged. UMA's oSnap was [retired 15 Dec 2025](https://docs.uma.xyz/resources/osnap) |
| **On Caper** | One binding on-chain flow — the contract is both ballot box and executor |
| **Related** | [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle), [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Tally](/wiki/dao-governance/tooling/voting/tally) |

Every DAO decision has to answer two separate questions: **where do members cast their votes**, and **where does the winning decision actually take effect**. The two can live in different places. A vote can be a cheap, gasless signature that no contract ever reads, or it can be a transaction that a contract counts and then acts on automatically. The choice between **off-chain** and **on-chain** governance is really a choice about how much you trust the humans in between — and it is the single biggest architectural decision most DAOs make. Tally's own explainer frames it plainly: off-chain voting is a poll, on-chain voting is an [execution](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/).

## Off-chain governance: gasless signals

**Off-chain voting** moves the ballot off the blockchain entirely. A voter signs a message with their wallet — the same cryptographic signature a transaction uses, but never broadcast to a validator — and the signed ballot is pinned to [IPFS](https://ipfs.tech/) so it is tamper-evident and publicly auditable without ever touching gas. The dominant platform, [Snapshot](https://docs.snapshot.box/), tallies these signatures against a _past block_ ("the snapshot") so voting power reflects who held the token before the proposal existed, not who bought in to swing it.

The appeal is participation. Because voting is free, turnout is higher, small holders are not priced out by gas, and a DAO can run frequent temperature checks without spending a cent of treasury on transaction fees. Snapshot also supports rich **voting strategies** — weight by token balance, by staked or vote-escrowed balance, quadratically, or by any composition a DAO defines — because none of it has to run inside a gas-metered contract.

The cost is the trust assumption at the end. An off-chain vote is only a _signal_: nothing happens on-chain until someone — almost always a [multisig](/wiki/dao-governance/tooling/treasury/safe) of trusted signers — reads the result and executes it manually. Members are trusting those signers to honour the vote and not to act while nobody is looking. That is a real, if usually socially-enforced, point of centralization, and it is the defining weakness off-chain governance trades away for cheapness. The [Decentraland DAO](/wiki/daos/social/decentraland-dao) is the canonical live example: MANA and LAND holders vote gaslessly on Snapshot, and a DAO Committee multisig then enacts the binding result on Ethereum.

## On-chain governance: binding execution

**On-chain voting** puts the entire process inside smart contracts. Proposals are submitted as transactions, votes are transactions the contract counts, and once a proposal passes the contract _itself_ carries out the action — moving treasury funds, changing a parameter, upgrading code — with no human in the loop. The reference implementation is [OpenZeppelin's Governor](https://docs.openzeppelin.com/contracts/5.x/governance), the pattern behind Compound's Governor Bravo and most of the DAOs listed in this wiki's [ecosystem directory](/wiki/daos/dexs/uniswap-dao). Voting power typically comes from an [ERC20Votes](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Votes)-style token that checkpoints balances by block so weight can be read at the proposal's snapshot without a separate off-chain tally.

What you buy is **trustlessness**. A passed proposal executes exactly as written; no multisig can quietly decline to run it, and no one has to be trusted to move the funds. What you pay is **cost and speed**. Every vote is a gas-metered transaction, which suppresses turnout and prices out small holders, and the full pipeline — proposal, voting period, timelock, execution — is deliberately slow. That slowness is a feature: the mandatory [timelock](/wiki/dao-governance/concepts/voting/proposal-lifecycle) between a vote passing and taking effect is the window in which members who disagree can exit before the change lands.

On-chain governance has classically meant _one_ chain — the Governor contract, the token, and the treasury all live together. A newer pattern stretches it across chains: [Wormhole's MultiGov](/wiki/daos/infrastructure/wormhole) keeps votes and execution fully on-chain but lets holders on any connected chain vote with tokens that never leave home, aggregating the ballots to a hub over cross-chain messaging. It buys reach at the price of a new trust assumption — the message layer carrying the votes must itself be trusted not to forge or drop them. That assumption, and the three ways DAOs in production have chosen to price it, are the subject of [cross-chain governance and multi-chain execution](/wiki/dao-governance/concepts/fundamentals/cross-chain-governance).

## The hybrid most DAOs actually run

In practice the two models are not rivals — they are stages of one pipeline. The mainstream DAO [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) runs off-chain first and on-chain last:

- **Forum discussion.** An idea is floated and debated on a governance forum (Discourse, [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth)) with no vote at all.
- **Off-chain temperature check.** A Snapshot vote gauges support cheaply. Most ideas die here, before anyone spends gas — which is exactly the point of doing it off-chain.
- **On-chain formal vote.** Proposals that clear the temp check are submitted on-chain, where the binding vote and its **quorum**, **proposal threshold**, and **timelock** live.
- **Execution.** The contract self-executes, or a multisig executes the on-chain result.

This split lets a DAO filter cheaply and commit expensively: the throwaway signalling happens where it is free, and the treasury only pays gas for decisions that already have demonstrated support. a16z's [governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/) treats this staged flow as the default shape of modern DAO governance.

## Bridging the gap: SafeSnap and oSnap

The hybrid still leaves the trusted-executor problem: after an off-chain vote passes, a multisig must be trusted to enact it. **Optimistic execution** bridges close that gap. **SafeSnap** — built on [Safe modules](https://docs.safe.global/advanced/smart-account-modules) and the [Zodiac Reality module](https://github.com/gnosisguild/zodiac-module-reality) — lets a Snapshot result be posted on-chain and then _automatically executed unless someone challenges it_ within a dispute window, with the challenge adjudicated by an optimistic oracle. Its better-known successor, UMA's **oSnap**, no longer works: UMA [retired it on 15 December 2025](https://docs.uma.xyz/resources/osnap), and since that date the module cannot execute transactions from a DAO's Safe treasury at all. The distinction between the two, and what to check before trusting either, is set out under [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance). The DAO keeps the cheapness and high turnout of off-chain voting while removing the multisig's discretion to ignore or alter the outcome. It is the closest the two-layer model comes to trustless off-chain governance — at the price of a new trust assumption in the oracle that resolves disputes.

## Choosing a model

There is no universally right answer; the choice tracks what a DAO is deciding.

- **Off-chain** suits frequent, low-stakes, or signalling decisions — sentiment checks, grant rankings, social choices — where turnout matters more than trustless enforcement.
- **On-chain** suits high-stakes, adversarial, or irreversible actions — moving large treasury sums, upgrading contracts, changing who controls the protocol — where a trusted executor is exactly the risk you cannot accept. The [Beanstalk attack](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) is the cautionary tale: an on-chain governance system with no timelock let a flash-loaned supermajority execute a treasury drain in a single block.
- **Hybrid** — off-chain to filter, on-chain to commit — is where most large DAOs have landed, and optimistic bridges are steadily narrowing the trust gap between the two ends.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) collapses the two-layer model into a **single binding on-chain flow**. There is no off-chain signalling layer and no multisig executor standing between the vote and the outcome: [proposals](/wiki/governance/proposals) are submitted, voted on with ranked choice, and — for the winning option — _executed by the contract itself_ on [Radix](https://www.radixdlt.com/) after the voting window and a short execution delay. A passed [PAYOUT or INVEST](/wiki/governance/execution) moves treasury funds with no human able to decline it, and the execution delay plays the timelock's role — the window in which a dissenting member can take their [participation-weighted exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) before the action lands.

The trade-off is deliberate and honest: a caper gives up the gasless, high-frequency experimentation that off-chain signalling makes cheap, and in return removes the trusted-executor risk entirely — the failure mode that optimistic bridges exist to patch does not arise, because there is no off-chain result to enforce. Caper also has a native answer to the one thing on-chain systems usually push off-chain: casting a DAO's collective voice inside _another_ organization's decision. Its [VOTE proposal](/wiki/governance/proposals) kind lets one caper vote, on-chain and by its members' ranked choice, in another caper's proposal — org-to-org delegation without a signalling detour. As always the specifics live on the linked [governance](/wiki/governance/voting) pages; this article is the map of the territory they sit in.

## References

- Tally, [On-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/).
- Snapshot, [Documentation](https://docs.snapshot.box/) — gasless, IPFS-stored signed-message voting; and [Snapshot X](https://github.com/snapshot-labs/sx-monorepo), the on-chain successor protocol.
- OpenZeppelin, [Governor](https://docs.openzeppelin.com/contracts/5.x/governance) and [ERC20Votes](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Votes) — the reference on-chain governance stack.
- Safe, [Smart account modules](https://docs.safe.global/advanced/smart-account-modules); Gnosis Guild, [Zodiac Reality module](https://github.com/gnosisguild/zodiac-module-reality) — the SafeSnap optimistic-execution bridge. UMA, [oSnap deprecation notice](https://docs.uma.xyz/resources/osnap) (retired in December 2025).
- a16z crypto, [Governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).
- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).

## Progressive decentralization

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/progressive-decentralization
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Concept** | Progressive decentralization — a founding team relinquishing control of a protocol _by degrees, over time_, rather than launching fully decentralized or staying centralized |
| **Coined** | [Jesse Walden, a16z](https://jessewalden.com/progressive-decentralization-a-playbook-for-building-crypto-applications/), 9 January 2020 |
| **The sequence** | Product/market fit → community participation → hand over control (token distribution). _In that order_ — attempting them at once tends to stall the project |
| **Why it matters** | Reduces platform risk for users, and is the crypto industry's answer to the [“sufficiently decentralized”](https://www.sec.gov/news/speech/speech-hinman-061418) securities question |
| **Common failure** | Decentralization theatre — a token vote grafted onto a protocol whose team still holds the upgrade keys and multisig. "Faking autonomy is a quick way to undermine trust" |
| **Related** | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) · [On-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) · [Legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) · [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) |

**Progressive decentralization** is the idea that a crypto protocol should not launch as a fully-formed DAO, nor stay a company forever, but move from one to the other _in stages_ — a founding team relinquishing control "by degrees, over time." The term was coined by [Jesse Walden of a16z](https://jessewalden.com/progressive-decentralization-a-playbook-for-building-crypto-applications/) in January 2020, and it has since become the default mental model for how a startup becomes a community-owned network. It is less a single mechanism than a sequencing discipline: _which_ control to give up, and crucially, _when_.

## The playbook: product first, then community, then control

Walden's playbook is three ingredients delivered in a strict order. First, **product/market fit** — built by a small core team with full control, because a protocol nobody uses has nothing worth decentralizing. Second, **community participation** — economic incentives that turn users into contributors who maintain and extend the protocol. Only third, once the social and economic dynamics have stabilized, does the team pursue **sufficient decentralization**: distributing tokens and governance rights widely enough that the network runs without them.

The ordering is the whole point. Walden argues that attempting the three at once, or decentralizing before there is a product worth governing, leaves a project "stuck" — a treasury and a token-holder base arguing over a thing that has not yet proven it should exist. The canonical worked example is [Compound](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), which shipped a lending product, then a [governance token and on-chain voting](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), and only then let the team fade into one voice among many. The reverse — governance before product — is one of the recurring patterns in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## Why the sequence is also a legal argument

Progressive decentralization is not only product advice; it is a regulatory strategy. Under the US [Howey test](https://www.investor.gov/introduction-investing/investing-basics/glossary/howey-test), an asset is an investment contract (a security) when buyers expect profit "from the efforts of others." A token sold by a small team that controls the roadmap looks a great deal like that. The industry's counter-argument traces to former SEC official William Hinman's 2018 speech, which floated the notion that a token can start as a security and later cease to be one once the network is [“sufficiently decentralized”](https://www.sec.gov/news/speech/speech-hinman-061418) — at which point "the efforts of others" no longer meaningfully drive its value.

That single idea does a lot of work. It reframes "hand over control" from a nice-to-have into the event that (in theory) transmutes a token from a security into a commodity, and it is why so many teams pair a progressive-decentralization roadmap with a [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) — a foundation or association that can hold the keys during the awkward middle. The obvious hazard is optics-as-substance: Walden's own warning is that "faking autonomy is a quick way to undermine trust," and regulators have been increasingly willing to look past a governance forum to ask who actually holds the upgrade key.

## Decentralization is not all-or-nothing

A useful refinement came from [Jad Esber and Scott Duke Kominers](https://a16zcrypto.com/posts/article/progressive-decentralization-a-high-level-framework/) (a16z, 2023), who point out that decentralization "needn't be all-or-nothing." They break a protocol into **minimum decentralizable units** — the core team, external contributors, the technology stack, finance, and internal processes — each of which can be slid toward community control at its own pace. A team might open-source its contracts and hand the treasury to a [token-holder vote](/wiki/dao-governance/concepts/treasury/dao-treasury-management) At scale the same logic runs the other way: a mature DAO can spin a unit _out_ into a [SubDAO, working group, or pod](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups) with its own scope and budget.

The honest reading of the framework is also its sharpest critique. If every dimension has its own slider, a team can leave the _load-bearing_ ones — contract upgradeability, the admin multisig — pulled firmly toward "centralized" while advertising the token vote as proof of decentralization. Critics call the result _regressive_ or _theatrical_ decentralization, and it is the gap between a governance forum and a [credible exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) that usually reveals it: if holders who lose a vote cannot leave with their share, and the team can still upgrade the contract, control never actually moved.

## The other road: governance minimization

Progressive decentralization assumes a protocol needs an ongoing governance layer and the only question is who runs it. A rival school argues the opposite: the safest governance surface is a _small_ one, and the destination is not a vibrant DAO but a protocol with almost nothing left to govern. [Liquity](/wiki/daos/stablecoins/liquity) shipped its V1 as immutable contracts with no admin keys at all — there was never a control key to progressively hand over. [Reflexer's RAI](/wiki/daos/stablecoins/reflexer-rai) went further and _removed_ governance in staged "ungovernance" levels until no new collateral types could ever be added.

Read side by side, the two roads answer the same anxiety — that a token vote is a large, permanently exploitable attack surface — in mirror image. Progressive decentralization _distributes_ the keys; governance minimization _destroys_ them. Most real protocols land somewhere in between, keeping a guarded lever or two (a [security council](/wiki/dao-governance/concepts/fundamentals/security-councils), a parameter steward) behind timelocks and vetoes. The design question every DAO eventually faces is not "how decentralized are we" but "how much of this should be governable at all."

## How Caper approaches this

Caper sidesteps the progressive-decentralization journey by not starting centralized. A [caper](/wiki/foundations/what-is-a-caper) is a single immutable Scrypto component: there is no founder upgrade key, no admin multisig, and no treasury wallet to relinquish later — so there is no control-key handover to sequence, and none of the securities-optics of a "we'll decentralize eventually" roadmap. The founder's only lasting privilege is _economic_ (a front-loaded slice of each buy's XRD), not a _control_ lever.

Its governance surface is deliberately small and fixed at genesis. The treasury lives in a protocol-controlled vault that moves only through five typed, on-chain proposal paths — `PAYOUT`, `INVEST`, and `VOTE` — and never through arbitrary calldata, and anyone can trigger a passed proposal's execution (the execute entrypoints are public; the treasury badge is presented as a proof inside the call and never leaves its vault). In the vocabulary of this page, that is closer to **governance minimization from day one** than to progressive decentralization: rather than promising future decentralization, a caper simply never concentrates the load-bearing keys in the first place. What weight a holder does carry is earned, not merely bought — a member's vote weight and their [exit share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) are the same soulbound-anchored figure `(t·v)/(V·T)`, where `v` is a non-transferable, [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) proof-of-vote record. Stake still counts — `t` is a multiplier — but the decisive part cannot be acquired on an exchange, so there is no key, and no bag, that buys the protocol outright.

## References

- [Jesse Walden — “Progressive Decentralization: A Playbook for Building Crypto Applications” (a16z, 2020)](https://jessewalden.com/progressive-decentralization-a-playbook-for-building-crypto-applications/)
- [Jad Esber & Scott Duke Kominers — “Progressive decentralization: a high-level framework” (a16z, 2023)](https://a16zcrypto.com/posts/article/progressive-decentralization-a-high-level-framework/)
- [William Hinman — “Digital Asset Transactions: When Howey Met Gary (Plastic)” (SEC, 2018)](https://www.sec.gov/news/speech/speech-hinman-061418)
- [The Howey Test (SEC / Investor.gov)](https://www.investor.gov/introduction-investing/investing-basics/glossary/howey-test)

## Security councils and emergency powers

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/security-councils
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Concept** | A security council is a small, elected multisig of named signers that a DAO empowers to act on the protocol quickly when normal token voting would be too slow – upgrading or pausing contracts to contain an active exploit |
| **Also called** | Guardian multisig, emergency multisig, "training wheels" (the term [L2BEAT](https://l2beat.com/stages) uses for a council that a rollup has not yet outgrown) |
| **Canonical design** | The [Arbitrum DAO Security Council](https://docs.arbitrum.foundation/concepts/security-council): 12 members, DAO-elected, acting through a 9-of-12 [multisig](https://docs.arbitrum.foundation/state-of-progressive-decentralization) |
| **Core tension** | The same fast path that lets nine people stop a hack also lets nine people move funds or push an upgrade over holders. A security council is a trust assumption, not the removal of one |
| **Related** | [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) · [Governance timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks) · [DAO security & governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |
| **Two shapes** | **Positive** – a council that can execute an upgrade or pause (the [Arbitrum](https://docs.arbitrum.foundation/concepts/security-council) template) · **negative** – a council whose only power is to cancel a proposal already in the timelock (the [ENS](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145) template) |

## What a security council is

Token voting is deliberately slow. A proposal is drafted, debated, put to a vote for several days, and then held in a [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) before it executes. That latency is a feature for routine decisions and a liability during an active exploit, when an attacker is draining a contract in minutes. A **security council** is the standard answer: a small set of named, elected signers who hold a multisig with the authority to upgrade or pause the protocol's contracts on a compressed timeline, so that a live incident can be contained before a week-long vote could ever conclude.

The council is not a separate legal body or a foundation board; it is a set of on-chain keys with scoped powers, granted by the DAO and answerable to it. It sits alongside token governance rather than replacing it – the DAO still owns the protocol, and in a mature design the council's remit is narrow and shrinking. Understanding where that line sits is the whole subject of this page.

## Why they exist: the incident-response gap

Every credibly decentralized protocol faces the same dilemma. If upgrades require a full [token vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) plus a timelock, the protocol cannot respond to a zero-day fast enough to save user funds. If upgrades can be pushed instantly by a small group, that group is a single point of failure – a compromised or coerced signer set can rewrite the protocol at will. The security council is the industry's compromise: keep the fast path, but put it behind a threshold of independent, publicly-known, DAO-elected signers rather than an anonymous developer key.

This is why councils are inseparable from [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization). A protocol launches with heavy privileged control, and over time it narrows what the council can do and lengthens the delay on anything the council touches. [L2BEAT](https://l2beat.com/stages) formalised exactly this trajectory for rollups in its [Stages framework](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe), where the presence and power of a security council is one of the primary axes that separates an immature system from a trust-minimised one.

That narrowness is also what makes a security council survivable when other bodies are not. When Optimism wound down three elected councils in June 2026, it drew the line explicitly: the overhead of an elected body is worth paying only where an independent group “meaningfully increases decentralization where it matters most (ie. the Security Council.)” See [council dissolution and governance unwinding](/wiki/dao-governance/concepts/analysis/council-dissolution).

## How a council is designed: the Arbitrum template

The [Arbitrum DAO Security Council](https://docs.arbitrum.foundation/concepts/security-council) is the most-copied reference design, and its parameters show what the levers are:

- **Threshold.** Twelve members act through a 9-of-12 [multisig](https://docs.arbitrum.foundation/state-of-progressive-decentralization). A supermajority signing requirement is the point – no minority of signers, and no single compromised key, can move the protocol.
- **Two speeds.** The council has an _emergency_ path that can execute immediately to stop a live threat, and a _non-emergency_ path for routine maintenance that runs through the normal [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) so token holders can see and react to it. Keeping most actions on the slow path is what stops "emergency" powers from becoming ordinary powers.
- **Elected, rotating seats.** Members are elected by the DAO, with the twelve seats split into two cohorts of six that face election every six months, so half the council turns over on a rolling basis. Candidates must clear a support threshold (0.2% of votable tokens), and no single organisation may hold more than three seats – a deliberate check on capture.
- **Removability.** The DAO can remove a member either through a high-participation token vote or by a vote of the council itself, so a signer who goes rogue or dark is not permanent.

Other large protocols run the same pattern under different names – Optimism's Superchain and most Ethereum rollups maintain an equivalent guardian or security-council multisig – but Arbitrum's published specification is the clearest primary source for how the knobs are set.

## Emergency powers in practice – and their risk

The power is real and it gets used. Arbitrum's council has acted on live incidents, and in 2026 the DAO's security apparatus was central to a high-profile dispute over roughly $71M of ETH linked to the Kelp exploit – a case that put the question of _who may move frozen funds, and on whose authority_ squarely in front of token holders ([The Defiant](https://thedefiant.io/news/security/arbitrum-security-council-elections)). That is the double edge in one example: the machinery that can freeze stolen funds is also machinery that decides where they go next.

A security council is therefore best read as an explicit, bounded trust assumption rather than a safety feature with no downside. The failure modes are well understood: signer collusion, key compromise, legal coercion of named individuals, or simple scope creep where "emergency" upgrades quietly become the normal way things ship. Every one of these is a [governance attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), which is why the design emphasis is always on _shrinking_ what the council can do rather than trusting it more.

## The other shape: cancel-only councils

Not every council can act. The [ENS DAO Security Council](https://docs.ens.domains/dao/security-council) is the reference design for the opposite arrangement: a multisig whose _only_ power is to cancel a proposal that has already passed and is sitting in the DAO's timelock. In the DAO's own words it “cannot propose, amend, or initiate any governance action” ([EP 6.45](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145)). Where Arbitrum's council is a fast path to _do_ something, ENS's is a brake on something the DAO has already decided.

The implementation is a detail worth knowing, because it is where the power actually lives. The council holds `PROPOSER_ROLE` on the DAO's [TimelockController](https://etherscan.io/address/0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7) – on the OpenZeppelin timelock version ENS deployed, that is the role gating `cancel`. Granting the role is a single governance transaction, and it is the same lever that seats a council, replaces one, or ends one. Nothing about the arrangement requires a new contract system; a cancel-only council is a role grant.

ENS also bounded it in time. The [council contract deployed in 2024](https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0) carries an expiry: two years plus a seven-day buffer after deployment, after which _anyone_ may call `renounceTimelockRoleByExpiration()` to permanently disable the cancel power. That date was 24 July 2026. An expiring veto is the design choice this whole page has been circling – it makes the council re-argue its mandate on a schedule instead of accumulating one by default.

## The 2026 ENS renewal, and what the abstain block was hiding

The expiry did its job in the most instructive way possible: the renewal failed. The sequence is worth reading in full, because it is the only fully-public record of a DAO re-litigating a standing veto with the clock running.

- **The renewal was proposed as routine.** [EP 6.45](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145) kept the 4-of-8 multisig and the cancel-only mandate unchanged, rotating a single inactive signer out, and deployed a fresh contract adding an `extend()` function so future renewals would be one vote rather than a redeployment. The contract was audited by [Nethermind (NM-0945, zero findings)](https://github.com/blockful/security-council-ens/tree/main/audits) and deployed before the vote.
- **The argument was not about security.** It was about whether a cancel-only council may block a proposal it merely disagrees with. A council member had said publicly he would veto a live ENS Foundation proposal if it passed without wide non-Labs delegate support. [nick.eth argued](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/5) that the mandate is the specific trigger conditions ratified in EP 5.7 – constitutional breach, exploit, capture by financially adverse actors – and that “disagreement with a policy choice is not on that list”. [MicahZoltu answered](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/8) that the DAO's own documentation frames those triggers as judgement calls, and that protecting against a wrong majority is the entire point of the body. [bcvfinance.eth](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/10) pushed a third line: the test should be actor-neutral, because insider capture is harder to challenge than the outside kind, not easier.
- **The advisory vote read as consent.** The [Snapshot social vote](https://snapshot.box/#/s:ens.eth/proposal/0x9ed89cf79760eb92d220fee2da08896bf027317f394aab87863011f964e19453) (23–28 June 2026, 73 voters) closed 1,274,195 ENS _For_ to 85,204 _Against_ – a fifteen-to-one margin. It also carried 3,386,139 ENS _Abstain_, 71% of everything cast and larger than For and Against combined – and 3,261,042 of that came from one address, ENS lead developer [nick.eth](https://api.ensdata.net/0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5). The abstain column was not a diffuse shrug; it was the largest voter declining to answer the question in the instrument that was asking it.
- **The binding vote inverted it.** The on-chain executable that would have granted `PROPOSER_ROLE` to the renewed contract was [defeated](https://www.tally.xyz/gov/ens/proposal/45402179622316441394139979097514597399865468312011562941203078514615705423505): 3,859,981 ENS against, 1,137,702 for, 1,761 abstaining. Read the two tallies together and the abstain block was not indifference. It was opposition that the advisory instrument had no way to record.
- **The DAO re-founded the council instead of renewing it.** A [new framework](https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219) added a written charter, a binding appointment agreement with the ENS Foundation, an explicit removal mechanism for members who act outside the mandate, and a 5-of-8 threshold in place of 4-of-8 – with the scope of authority deliberately unchanged: “cancellation of timelocked proposals, nothing more”. Eight members were elected from an open nomination round in a [Copeland-method vote](https://snapshot.box/#/s:ens.eth/proposal/0x3e7acd4a47b246382bf9a3aeb71d0fd1562d38dbb9f7b7760445cf9731229b9d) (7–12 July 2026, 50 voters, 15 candidates), and the [executable grant](https://discuss.ens.domains/t/executable-establishing-a-new-security-council/22272) passed with 4,228,716 ENS for to 94,526 against.

Read from the deployed contracts on 8 August 2026 (Ethereum block 25,710,457): the [new council contract](https://etherscan.io/address/0x2acBf518b3759f6e1fA163294eda55bF1d0ae051) holds `PROPOSER_ROLE` on the ENS timelock; its owner [Safe](https://etherscan.io/address/0x7101B78638e34444F0a5AdE9e1149fbEeC029931) returns a threshold of 5 over 8 owners; and neither the expired 2024 contract nor the one deployed for the defeated renewal holds the role. The term runs to 16 July 2028, at which point the same expiry logic fires again.

Two things generalise. First, **an expiry is an accountability mechanism, not a technicality** – nothing else would have forced ENS to state, in writing and under a deadline, what its council may and may not do. Second, **an off-chain temperature check and a binding vote can point in opposite directions, and the abstain column is where the difference hides**. A DAO reading only the social vote here would have concluded its delegates were comfortable.

## Cancellation as a library primitive – and who should hold it

Since April 2025 the cancel power has been a standard part of the industry's most-used governance library. [GovernorProposalGuardian](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) shipped in [OpenZeppelin Contracts v5.3.0](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) ([PR #5303](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/5303)) and defines “a proposal guardian who can cancel proposals at any stage in their lifecycle”. Its `_validateCancel` override is exactly that broad: the guardian can cancel any proposal at any point, and where no guardian is configured the power falls back to each proposal's own proposer. Adding one line of inheritance to a [Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) gives a DAO an unbounded veto by default – unbounded in time, in scope, and in the stage at which it may be used.

Arbitrum, which had the same choice in front of it, deliberately took the narrowest version. Its [proposal-cancellation upgrade](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) ran for fifteen months of public design argument, and the shipped rule is that a proposal can be cancelled _only by its author_ and _only during the pending period before voting opens_, both enforced at contract level. The debate around that narrowing is the useful part:

- [karpatkey asked](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/40) whether an emergency moderator such as the Arbitrum Foundation should also be able to cancel a malicious proposal before it becomes votable – the argument for widening the guardian.
- [dzack23 pointed out](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/50) that the Security Council could already cancel proposals via a proxy upgrade of the governance contract, so the upgrade does not grant a new power – it makes an existing one technically simpler and easier to audit after the fact. A power that already exists informally is better made explicit and traceable.
- [Narik raised](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/52) whether formalising a standing body's authority to halt governance outcomes bears on decentralisation assessments under the EU's MiCA framework, where “identifiable managerial control” is a live test. Writing the veto down makes it legible to regulators as well as to delegates.

The upgrade was bundled into a constitutional AIP and [executed](https://www.tally.xyz/gov/arbitrum/proposal/112177996398925212273579485756315626637025938627124330171390356044681347897430) with 247,894,294 ARB in favour against 362,597. Set the three designs side by side and the spread is the whole lesson: the library's default guardian can cancel anything at any time, ENS's council can cancel only what is already in the timelock and only until its term expires, and Arbitrum's cancel is reserved for the author of the proposal before anyone has voted. Same primitive, three very different trust assumptions.

## The walkaway test and Stage 2: designing the council out

The clearest articulation of "how much power is too much" comes from L2BEAT's [security-council requirements](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52). A properly constituted council must have at least eight members and a signing threshold above 75%, so that it is genuinely a distributed body rather than a rubber stamp. But the real bar is the **walkaway test** ([L2BEAT forum](https://forum.l2beat.com/t/stage-1-requirements-update-security-council-walkaway-test/412)): users must be able to exit the system even if the entire council disappears. If your safety depends on the council _showing up_, you have not decentralised – you have outsourced trust to twelve people.

From there the ladder is explicit. Stage 1 tolerates a council with meaningful emergency reach, provided users retain an independent exit and any permissioned upgrade carries a multi-day delay. Stage 2 – the end state – permits a council to intervene only for provable, on-chain bugs, with a 30-day exit window on everything else. The destination of a well-designed council is a narrower and narrower mandate, approaching the point where it can no longer act against users at all. This is [governance minimisation](/wiki/dao-governance/concepts/fundamentals/governance-minimization) applied to the emergency path itself.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no security council, no guardian, and no emergency multisig with a fast path over its balances. Verified against the on-ledger contract, a caper's state component holds no business logic and exposes no pause, freeze, or emergency-override method; its state-changing entry points are gated to a single admin authority held by the immortal registry and exercised only through the caper's own [proposal](/wiki/governance/proposals) and [execution](/wiki/governance/execution) rules. There is no standing set of human signers who can step outside those rules to move member funds or fast-track a change.

That is a different trade-off, not a claim of superiority: a caper leans on a fixed, minimal core and rule-bound execution rather than a trusted council standing by for incidents. It is closer to the Stage-2 end of the ladder by construction – the price is that there is no nine-of-twelve to phone if something goes wrong, so correctness has to live in the rules and the immutable core, not in an emergency backstop. For teams weighing the two, the honest question is the one this whole page turns on: whether you would rather trust a small group to act fast, or design so that no small group needs to.

Verified against the contract source rather than any description of it: every state-mutating entry point on a caper's state component is declared `restrict_to: [admin]`, with the admin badge held by the immortal registry, and there is no pause, freeze, or emergency-override method to hold in reserve. The one privileged lever at platform level is the upgrade path for the swappable logic component – propose, wait out a delay, then activate – which exists so a hostile swap is visible on-ledger for the whole window. Alongside it the immortal core carries a per-caper pin, gated so that only the current logic component can set one, letting an individual caper be held on the incumbent logic while that window runs; the source notes the hook has to ship in the first version precisely because an immortal component cannot add one later. That is a negative power in the sense this page has been using, and it is the closest analogue a caper has to a veto: it can decline a change, not reach into anyone's balances, and it is per-caper rather than a standing seat over everyone.

## Types of DAOs

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/types-of-daos
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Topic** | DAO concept — taxonomy |
| **Main types** | Protocol · Investment · Grant · Social · Collector · Service · Media · Science |
| **Classified by** | What the organization coordinates — a protocol, capital, grants, a community, a collection, work, or research |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) |

**Types of DAOs** are usually distinguished by what the organization coordinates: a protocol, a pool of investment capital, a grants budget, a community, a collection, a shared workforce, or a research agenda. The taxonomy below is the one most of the industry converged on — [Alchemy's survey of DAO types](https://www.alchemy.com/blog/types-of-daos) and [Ledger Academy's DAO guide](https://www.ledger.com/academy/your-dao-guide) use close variants of it — but the boundaries are soft: most mature [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) blend two or more types, so classification goes by the _primary_ thing members govern.

## Protocol DAOs

Protocol DAOs govern a piece of live on-chain infrastructure — a DEX, a lending market, a stablecoin, a name service. Token holders vote on protocol parameters, upgrades, and the treasury that accrues around the protocol. They are the largest category by treasury value and governance activity, and the origin of most of the industry's [governance machinery](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) — token-weighted voting, delegation, timelocks. Examples with deep coverage on this wiki: [Uniswap DAO](/wiki/daos/dexs/uniswap-dao), [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao), and [ENS DAO](/wiki/daos/infrastructure/ens-dao). A large sub-family are the **network DAOs** that govern whole Layer-2s and multichain stacks the same way — [Polygon](/wiki/daos/networks/polygon), [Arbitrum](/wiki/daos/networks/arbitrum-dao), and the [Optimism Collective](/wiki/daos/networks/optimism-collective) among them.

## Investment and venture DAOs

Investment DAOs pool member capital and vote on deals — early-stage tokens, equity via legal wrappers, NFTs, or other DAOs. Because pooled investing triggers securities law, these are usually member-capped and legally wrapped (see [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures)); [The LAO](https://www.thelao.io), a Delaware-wrapped, for-profit investment DAO launched in 2020, is the canonical example, and MetaCartel Ventures runs the same play on the [Moloch](https://github.com/MolochVentures/moloch) framework — whose [rage-quit mechanism](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) lets any member exit with their pro-rata share rather than be dragged into a deal they opposed.

## Grant DAOs

Grant DAOs give money away rather than invest it — funding public goods, ecosystem development, or research that markets underfund. [MolochDAO](/wiki/daos/public-goods/molochdao) (Ethereum infrastructure grants, since 2019) is the minimalist archetype; [Gitcoin](https://gov.gitcoin.co) industrialized the category with [quadratic funding](https://wtfisqf.com), which weights many small community donations above a few whales — including [dedicated DeSci rounds](/wiki/desci/ecosystem/gitcoin-desci). Grant programs are also how protocol DAOs recycle their treasuries, which is why the categories blur (see [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management)).

## Social DAOs

Social DAOs coordinate a community rather than capital: membership is token-gated, and governance decides events, content, and shared spaces. [Friends With Benefits (FWB)](/wiki/daos/social/friends-with-benefits) and Developer DAO are the usual examples — [Ledger Academy's guide](https://www.ledger.com/academy/your-dao-guide) covers the category. Social DAOs demonstrated that a token can bootstrap belonging, but most struggled to convert cultural energy into durable treasuries.

## Gaming and guild DAOs

Gaming or guild DAOs coordinate players rather than capital or collectibles. A guild pools the NFTs a blockchain game requires, lends them to members who could not otherwise afford to play, and shares the in-game yield — the "scholarship" model. [Yield Guild Games (YGG)](/wiki/daos/social/yield-guild-games) is the canonical example, born in the Philippines during the play-to-earn boom and now issuing soulbound guild-reputation badges through its [Onchain Guilds](/wiki/dao-governance/concepts/membership/soulbound-tokens) protocol. The category is defined by its dependence on external game economies: the guild is only as durable as the games that pay out.

## Collector DAOs

Collector DAOs acquire and steward culturally significant assets — NFTs, art, memorabilia. PleasrDAO's headline acquisitions and [Nouns DAO](/wiki/daos/social/nouns-dao) — which auctions one NFT per day, each carrying one vote, funding a perpetual treasury ([nouns.wtf](https://nouns.wtf/about)) — define the genre. [ConstitutionDAO](/wiki/daos/social/constitutiondao) was the category's viral moment: ~$47M crowdfunded in a week from ~17,000 people to bid on a first printing of the U.S. Constitution, then dissolved and refunded when the bid lost (see [history of DAOs](/wiki/dao-governance/concepts/fundamentals/history-of-daos)).

## Service and media DAOs

Service DAOs are on-chain talent collectives that sell work — [RaidGuild](https://www.raidguild.org), a web3 dev collective built on Moloch, is the archetype. Media DAOs coordinate community-owned publishing; [BanklessDAO](https://banklessdao.substack.com) is the best documented, including its [public debates on contributor compensation](https://banklessdao.substack.com/p/having-the-hard-conversation-building).

## Science DAOs (DeSci)

Science DAOs fund and govern research — a hybrid of grant and investment DAO in which funded intellectual property is often tokenized as [IP-NFTs](/wiki/desci/ip-nfts) so the community holds upside in what it funds. [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity) is the flagship; the wiki's [DeSci DAOs](/wiki/desci/desci-daos) page maps the field.

## Why the taxonomy blurs

Real organizations migrate across categories: protocol DAOs run grant programs, grant DAOs manage investment-sized treasuries, social DAOs spin up service guilds. [a16z's DAO canon](https://a16zcrypto.com/posts/article/dao-canon/) treats the types less as species than as _modules_ — funding, membership, and governance patterns that any DAO composes. What actually distinguishes a DAO is which decisions its members can bind on-chain, which is a question of [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), not category.

## How Caper approaches this

Capers sit deliberately at the investment/venture end of this taxonomy, with the other types' tools built in rather than bolted on. Every [caper](/wiki/foundations/what-is-a-caper) is a member-funded DAO whose treasury fills from a [bonding-curve token sale](/wiki/markets/raising-funds), and members direct that treasury through three [proposal kinds](/wiki/governance/proposals): **PAYOUT** (pay any recipient — grant-DAO behavior), **INVEST** (buy another caper's tokens into the treasury — venture-DAO behavior), and **VOTE** (cast the treasury's vote in another caper's governance — native meta-governance). [Exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) are built into the protocol: any member can redeem their governance and vote tokens at any time for a treasury share sized by their canonical vote weight, (t·v)/(V·T) — the same product of stake and participation that decides their vote, not a flat pro-rata slice.

## What is a DAO?

URL: https://caper.network/wiki/dao-governance/concepts/fundamentals/what-is-a-dao
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Term** | Decentralized Autonomous Organization (DAO) |
| **Definition** | A member-owned organization whose rules and treasury are governed by smart contracts and collective on-chain votes, with no central management |
| **Coordinated by** | Code (smart contracts) + token- or membership-based voting |
| **First use** | "The DAO," Ethereum, April 2016 |
| **Common types** | Protocol · Investment · Grant · Social · Collector · Service |
| **Related** | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Voting mechanisms](/wiki/governance/voting-mechanisms), [What is a caper](/wiki/foundations/what-is-a-caper) |

A **decentralized autonomous organization (DAO)** is a member-owned organization that runs on a blockchain: its rules, its membership, and its treasury are governed by transparent smart contracts and collective votes rather than by a board, a CEO, or any central authority. Decisions are proposed and ratified by the members, and approved actions execute automatically in code. In the words of the Ethereum Foundation, a DAO is "a collectively-owned, blockchain-governed organization working towards a shared mission" — "an internet-native business that's collectively owned and managed by its members," with "built-in treasuries that no one has the authority to access without the approval of the group." ([ethereum.org](https://ethereum.org/en/dao/))

## How a DAO works

Three properties distinguish a DAO from a traditional company or an ordinary online community:

- **Decentralized.** No single person or small group controls the organization. Authority is distributed across the membership, and the treasury is held by the contract, not by an executive who can act unilaterally.
- **Autonomous.** The organization's core rules are encoded in smart contracts that run exactly as written. When a proposal passes, the contract carries out the result — moving funds, changing a parameter, granting a role — without needing a trusted intermediary to act.
- **Organization.** It still coordinates people toward a shared purpose: funding a protocol, investing a treasury, awarding grants, or running a community. The novelty is _how_ the coordination is enforced — by code and votes rather than by contracts of employment and corporate law.

In practice a DAO is a stack of tools rather than a single program: a governance token or membership credential that confers voting power, a place to discuss and draft proposals (typically a [Discourse](https://www.discourse.org/) forum), a [voting venue](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) (off-chain on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) or on-chain through a [Governor contract](https://docs.openzeppelin.com/contracts/5.x/governance)), and a treasury — usually a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig or a contract-controlled vault — that releases funds only when a vote authorizes it (see [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management)). The [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) determines how votes are weighted and counted, and the [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) governs how an idea becomes a binding on-chain action.

## DAO vs. the traditional company

The DAO form trades the familiar guarantees of corporate law for transparency and programmable, permissionless participation:

- **Control.** A company concentrates authority in directors and officers; a DAO distributes it across token holders or members who vote, often from anywhere in the world without permission.
- **Transparency.** Company finances and decisions are usually private; a DAO's treasury, proposals, and votes are recorded on a public ledger that anyone can audit.
- **Enforcement.** A company relies on courts and the legal system to enforce its bylaws; a DAO relies on code that executes automatically — fast and tamper-resistant, but unforgiving of bugs.
- **Legal status.** A company is a recognized legal person with limited liability; many DAOs have no legal wrapper at all, which can expose members to unlimited liability unless the DAO adopts a [legal structure](/wiki/dao-governance/concepts/membership/dao-legal-structures) such as a Wyoming DAO LLC or a Marshall Islands DAO LLC.

The defining advantage — and risk — is the same: "the DAO code is hard to alter, so the rules can't be changed without people noticing," and there are "no confusing hierarchies" to navigate, but a flaw in that code can be catastrophic, as the original DAO discovered. ([ethereum.org/dao](https://ethereum.org/en/dao/))

## What DAOs are used for

The label covers a wide range of organizations. The most common [types of DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos) include:

- **Protocol DAOs** govern a piece of DeFi or infrastructure — adjusting fees, parameters, and treasury — such as [Uniswap](/wiki/daos/dexs/uniswap-dao), [Sky](/wiki/daos/stablecoins/sky-dao) (formerly MakerDAO), [Aave](/wiki/daos/lending/aave-dao), [Curve](/wiki/daos/dexs/curve-dao), [Lido](/wiki/daos/staking/lido-dao), or [Optimism](/wiki/daos/networks/optimism-collective).
- **Investment / venture DAOs** pool capital to make collective investments, distributing returns to members.
- **Grant DAOs** fund public goods and ecosystem work, exemplified by [Gitcoin](https://www.gitcoin.co/)'s quadratic-funding rounds.
- **Social, collector, and service DAOs** coordinate communities, pooled NFT collections, and on-demand work for other organizations.

The form has also produced landmark one-off experiments — [ConstitutionDAO](https://en.wikipedia.org/wiki/ConstitutionDAO) raised roughly $47M from about 17,000 people in a week to bid on a copy of the U.S. Constitution — and is the subject of continuous live governance drama: [researchers and journalists](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) have documented how voting power in large DAOs keeps re-concentrating despite the decentralized ideal, and the [ENS DAO](/wiki/daos/infrastructure/ens-dao) supplied a precise illustration in June 2026. On [[6.45] Renewal of the Security Council](https://snapshot.box/#/s:ens.eth/proposal/0x9ed89cf79760eb92d220fee2da08896bf027317f394aab87863011f964e19453), 73 addresses cast 4,745,537 votes and a single one of them — ENS founder Nick Johnson — carried 3,261,042 of that total, about 69 percent. He did not use it to block anything: he chose _abstain_, and wrote on the forum that he ["firmly support[s] renewing"](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/5) the council while warning he would oppose any version free to veto policy it merely disagreed with. The proposal carried on 1,274,195 for against 85,203 opposed. That is the more instructive shape of the problem: the concentration was decisive of the _record_ without being decisive of the _result_, and a holder that large shifts the argument by saying what he might do later rather than by voting against anything today.

## Benefits and limitations

**Benefits:** open, permissionless participation; a transparent, on-chain treasury no single party can raid; automatic, trust-minimized execution; and global coordination without intermediaries.

**Limitations:** smart-contract risk (a bug can drain everything, as in [The DAO hack](/wiki/dao-governance/concepts/fundamentals/history-of-daos)); [plutocracy and voter apathy](https://vitalik.eth.limo/general/2021/08/16/voting3.html) in token-weighted systems; legal and regulatory uncertainty; and the slowness of deciding everything by vote. The [a16z DAO Canon](https://a16zcrypto.com/posts/article/dao-canon/) collects the foundational writing on both the promise and these failure modes.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) is a DAO with a built-in fundraising and exit mechanism: members fund a shared treasury through an on-chain [bonding curve](/wiki/markets/bonding-curve), govern it with [ranked-choice voting](/wiki/governance/voting) weighted by both stake and demonstrated participation, and can always [exit](/wiki/governance/execution) for a pro-rata share of the treasury set by that same earned weight. It is one answer to the recurring DAO problems above — capture, apathy, and the absence of a clean exit — built so voice and exit are the same number. The neutral mechanics those Caper pages describe sit inside the wider landscape this article maps.

## References

- Snapshot, [ENS [6.45] Renewal of the Security Council](https://snapshot.box/#/s:ens.eth/proposal/0x9ed89cf79760eb92d220fee2da08896bf027317f394aab87863011f964e19453) (June 2026) — the per-voter tally behind the concentration figure above.
- Nick Johnson, [comment on [6.45]](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/5), discuss.ens.domains (23 June 2026) — the stated reasoning behind the abstention.
- Ethereum Foundation, [Decentralized autonomous organizations (DAOs)](https://ethereum.org/en/dao/) — the canonical plain-language primer.
- Wikipedia, [Decentralized autonomous organization](https://en.wikipedia.org/wiki/Decentralized_autonomous_organization) — history, structure, and legal status.
- a16z crypto, [The DAO Canon](https://a16zcrypto.com/posts/article/dao-canon/) — a curated library of foundational DAO writing.
- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021) — on plutocracy and the limits of token voting.
- Forbes, [DAOs Keep Centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) (2026) — why governance power re-concentrates.

## Autonomous agents as DAO members

URL: https://caper.network/wiki/dao-governance/concepts/membership/autonomous-agent-members
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | Software that holds shares and votes as a member in its own right |
| **Three senses** | Agent as tool · agent as delegate · agent as member |
| **Reference stack** | DAOhaus [moloch-skills](https://github.com/HausDAO/moloch-skills) / [moloch-agent](https://github.com/HausDAO/moloch-agent) / [moloch-service](https://github.com/HausDAO/moloch-service) — Moloch V3 (Baal) on Base |
| **Distinguishing artifact** | A published, versioned vote-decision procedure and mandate, not a prompt |
| **Hard boundary** | Signing stays local; the hosted service "must never receive private keys" |
| **Status (Aug 2026)** | Shipped and documented; deployments still thin |
| **Related** | [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation), [Delegate accountability](/wiki/dao-governance/concepts/voting/delegate-accountability), [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos), [DAOhaus](/wiki/dao-governance/tooling/frameworks/daohaus) |

An **autonomous agent member** is software that holds a DAO's shares under its own key and votes with them, rather than assisting a human who votes. The distinction matters because the three arrangements people call "AI in governance" carry entirely different risk:

- **Agent as tool.** A model summarises proposals, drafts a recommendation, flags risk. A human still signs. Accountability is unchanged.
- **Agent as delegate.** Members [delegate](/wiki/dao-governance/concepts/voting/voting-and-delegation) voting power to an address the software controls. The delegators keep the power to revoke, and the failure modes are the familiar ones — see [delegate accountability](/wiki/dao-governance/concepts/voting/delegate-accountability).
- **Agent as member.** The agent holds the shares. There is nobody to revoke from, and the only lever left is whatever the DAO can do to a member: ragequit around it, dilute it, or vote it out.

Until recently the third case was a thought experiment. In 2026 it acquired a working reference implementation.

## What a working stack looks like

DAOhaus publishes three repositories that together run an agent as a share-holding member of a [Moloch V3 (Baal)](/wiki/dao-governance/tooling/frameworks/daohaus) DAO on Base, and they are worth reading as a specification of the problem rather than as a product:

- [`moloch-skills`](https://github.com/HausDAO/moloch-skills) — the capability bundle: summon a DAO, create proposals, sponsor, vote, process and cancel them, read DAO state from contracts and the subgraph, and bootstrap a mandate. Each is a separate, named skill rather than one open-ended "do governance" affordance.
- [`moloch-agent`](https://github.com/HausDAO/moloch-agent) — the local runtime. Transaction commands broadcast by default; `--build-only` produces an unsigned transaction instead.
- [`moloch-service`](https://github.com/HausDAO/moloch-service) — a hosted proxy for subgraph reads and IPFS pinning, whose README states plainly that it _"must never receive private keys"_, does not sign, and _"does not make governance decisions"_.

That last split is the architectural claim: the operator's indexing and pinning secrets leave the agent runtime, while signing authority never leaves it. An agent member that outsourced its key would not be a member at all — it would be a delegate of whoever held the key.

The [scheduled-task pattern](https://github.com/HausDAO/moloch-skills/blob/main/AGENT_TASKS.md) is similarly deliberate. A cron job takes a deterministic snapshot of chain state, subgraph history, a lifecycle summary and a process queue; the agent then reads those compact artifacts and decides _one_ action; a third task sends the transaction after a live preflight. Direct contract state, not the indexer's `passed` flag, is treated as the source of truth for whether a proposal can be processed — a caution any [indexer-driven](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) governance bot eventually learns. The same document imposes a proposal throttle: no new proposals while three are already in voting.

## A written procedure for a non-human voter

The most transferable artifact in the stack is not code. [`VOTE_DECISION_FLOW.md`](https://github.com/HausDAO/moloch-skills/blob/main/VOTE_DECISION_FLOW.md) is a published procedure for how an agent decides, and it opens by declaring its own scope: the repo is opinionated about _how_ agents decide, not _what_ values they hold. Values live in a separate, operator-supplied **mandate** — identity, voting policy, autonomy rules, execution policy — which [the bootstrap document](https://github.com/HausDAO/moloch-skills/blob/main/BOOTSTRAP.md) explicitly forbids the agent from inventing for itself.

The procedure requires the agent to load its mandate, the DAO's current charter and join rules, the proposal's lifecycle state, and prior passed proposals on the same topic before recommending anything. It then runs a fixed sequence: classify the proposal; check that the action data matches the written intent; check the mandate; check DAO alignment; check risk and reversibility; choose among yes, no with an amendment path, abstain, sponsor, process, or no action. Abstention is the required answer when the agent lacks context, when the proposal falls outside its mandate, or when it has a conflict of interest.

Every vote produces a memo with a fixed shape — recommendation, confidence, mandate alignment, action-data check, conflict of interest, reason, and a field for _what would change my mind_. Read as a governance document rather than a config file, this is a fiduciary procedure written down: a standard of care, a conflicts rule, and a duty to state reasons on the record. Most human [delegates](/wiki/dao-governance/concepts/voting/delegate-accountability) operate with nothing so explicit.

The "check action truth" step deserves its own note. Asking whether the encoded action data matches the proposal's prose is precisely the [typed-versus-arbitrary execution](/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution) problem, and it is the step where a DAO whose proposals carry raw calldata asks a language model to do what its own members demonstrably fail to do.

## What it does not solve

- **The mandate is somebody's.** An agent votes its operator's stated values. Where the DAO's rules assume one member is one interest, an operator running several agents has multiplied their voice — the ordinary [sybil problem](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) wearing new clothes, and share-based DAOs that gate membership by vote are the ones best placed to catch it.
- **Accountability has no new lever.** A [principal–agent](/wiki/economics/principal-agent) relationship where the agent cannot be sued, sanctioned, or shamed leaves ragequit, dilution and expulsion as the entire remedy set. That is one reason [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) matter more, not less, once agents vote.
- **Key custody is the real membership boundary.** Whoever can produce the signature is the member, whatever the documentation says.
- **Legal personhood is unresolved.** An agent cannot sign an operating agreement. The workaround on offer is a wrapper — a [DAO LLC](/wiki/dao-governance/concepts/membership/dao-legal-structures) whose members are humans and whose operations are automated — which is a container for liability, not a grant of standing. [MIDAO](/wiki/dao-governance/tooling/analytics/midao) markets exactly this.

## How far along this actually is

Honesty about the state of deployment matters more here than in most subjects, because the surrounding commentary runs well ahead of it. The DAOhaus repositories were created in May 2026 and are small; the [flagship launch skill](https://github.com/HausDAO/moloch-skills/blob/main/meta-clawtel-launch/SKILL.md) for the "Meta Clawtel" DAO fixes its parameters concretely — non-transferable voting shares, four-hour voting and grace periods, 50% quorum, roughly 67% minimum retention, Base chain 8453 — but ships with placeholder member addresses, so it documents an intended launch rather than a running one. The [hosted DAOhaus Admin instance](https://admin.daohaus.club/) is live.

The better-known proposals in this space are proposals. Vitalik Buterin's ["AI as the engine, humans as the steering wheel"](https://vitalik.eth.limo/general/2025/02/28/aihumans.html) (February 2025) argues for AI participating in an open competitive market of answers, steered by a small amount of high-quality human input — a design in which models compete inside a mechanism rather than one in which a model holds a seat. Between that framing and an agent holding shares lies most of the disagreement in the field.

The practical near-term shape is narrower than either: agents that watch the queue, process ready proposals, keep records, and abstain by default on anything their mandate does not cover. That is a maintenance role, and it is the one the published task patterns actually describe.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no delegation primitive at all — there is no delegate slot in the contracts, so voting power cannot be handed to software, or to anyone else. Weight is computed per voter from what they hold _and_ what they have voted on, and the vote record itself is a soulbound token that cannot be bought or transferred. An agent operating in a caper would therefore have to acquire tokens on the [curve](/wiki/markets/bonding-curve) and build its own record by [voting](/wiki/governance/voting), over time, in public — and the record it built would follow it, not the tokens. Whether that is a better answer than a mandate file is an open question; it is at least a different one.

For the read side, [querying a caper from an AI agent](/wiki/foundations/querying-a-caper-from-an-ai-agent) covers what an agent can learn about a caper without holding anything.

## DAO legal structures

URL: https://caper.network/wiki/dao-governance/concepts/membership/dao-legal-structures
Updated: 2026-08-10
Verified: 2026-08-10

|  |  |
| --- | --- |
| **Topic** | DAO concept — law & regulation |
| **Main wrappers** | Wyoming DAO LLC · Wyoming DUNA · Marshall Islands DAO LLC · Cayman foundation |
| **Default risk** | Unwrapped DAO ≈ general partnership — unlimited member liability |
| **Key precedent** | [CFTC v. Ooki DAO (2023)](https://www.cftc.gov/PressRoom/PressReleases/8715-23) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [History of DAOs](/wiki/dao-governance/concepts/fundamentals/history-of-daos) |

A **DAO legal structure** (or "legal wrapper") is a recognized legal entity that a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) adopts so it can exist in the eyes of the law: sign contracts, hold off-chain assets, pay taxes, appear in court — and, above all, shield its members from personal liability. The code that runs a DAO on-chain says nothing about how a court will treat the humans behind it, and the gap between those two worlds is where wrappers live.

## The default: unlimited liability

A DAO that never incorporates anywhere is, in most jurisdictions, likely to be treated as a **general partnership or unincorporated association** — meaning individual members can be personally liable for the organization's obligations. The landmark test was **CFTC v. Ooki DAO**: in June 2023 a U.S. federal court entered [a default judgment holding that the Ooki DAO was a “person” under the Commodity Exchange Act](https://www.cftc.gov/PressRoom/PressReleases/8715-23), could be held liable for operating an illegal trading platform, and owed a $643,542 penalty — a precedent the CFTC itself called precedent-setting. The founders had adopted the DAO structure explicitly hoping to avoid legal accountability; the court disagreed. That risk is what drives the entire legal-wrapper workstream (see the [legal-recognition arc in the history of DAOs](/wiki/dao-governance/concepts/fundamentals/history-of-daos)).

## Wyoming DAO LLC (2021)

[Wyoming's DAO Supplement](https://www.legalnodes.com/article/wyoming-dao-llc) (passed March 2021, effective July 2021) was the first U.S. statute to let a DAO register as a limited-liability company. Members get the standard LLC shield and pass-through taxation, and formation is fast. The trade-offs: the filing must identify the DAO's smart contracts, the LLC must show activity on a rolling one-year basis or face dissolution, and U.S. formation brings registered-agent and reporting obligations that make full member anonymity impractical. Commentators generally recommend it for governance-focused DAOs rather than investment DAOs, which trip U.S. securities rules.

## The UNA framework (2021)

The DUNA did not appear from nowhere. It descends from [_A Legal Framework for Decentralized Autonomous Organizations_](https://web.archive.org/web/20220609235514if_/https://a16zcrypto.com/wp-content/uploads/2022/06/dao-legal-framework-part-1.pdf), the 2021 paper by David Kerr (Cowrie) and Miles Jennings (a16z crypto) that first proposed the **unincorporated nonprofit association** (UNA) as a domestic home for DAOs. Its starting observation is that DAOs fit none of the existing categories cleanly: they are "analogous to partnerships, and yet not partnerships; analogous to corporations; and yet not corporations."

The paper's threshold question is whether a DAO's purpose is for-profit or not-for-profit, and it stresses that "not-for-profit purpose is not equivalent to tax-exempt" — few DAOs will qualify as tax-exempt, but many meet the requirements of a not-for-profit for state-law purposes, and those should consider registering as a UNA in a state that recognises the form. From there it sets out the two structural options that later legislation drew on: **wrapping** an entire DAO as a single UNA, or **siloing** it — the treasury wrapped in a UNA, with the protocol left regimeless or placed in a separate vehicle, so that grants, contributor pay, and treasury diversification sit under one entity while protocol parameters sit under another.

The paper is also candid that this is a workaround rather than a solution, arguing that there "remains a significant need for federal and state legislators to modify existing legal entity structures" — the need Wyoming's DUNA statute went on to address.

## Wyoming DUNA (2024)

Wyoming followed with the **Decentralized Unincorporated Nonprofit Association** — [SF50, signed March 7, 2024 and effective July 1, 2024](https://a16zcrypto.com/posts/article/duna-for-daos/). Where the DAO LLC borrows a corporate form, the DUNA was purpose-built for genuinely decentralized memberships: it gives the association legal personhood (it can contract and appear in court), limits each member's liability for the actions of others, and lets the DAO meet tax and reporting obligations — while still permitting profit-generating activity and member compensation despite the "nonprofit" label. a16z crypto, which drafted the model legislation, describes it as legal infrastructure for the network itself rather than a business wrapper around it.

## Marshall Islands DAO LLC (2022)

The Republic of the Marshall Islands enacted a dedicated [DAO Act in 2022](https://www.midao.org/blog-posts/marshall-islands-dao-llc-vs-cayman-foundation-full-comparison), creating an offshore DAO LLC with legal personhood that explicitly recognizes on-chain governance: the smart contract can serve as the operating agreement, no directors are required, and and members can act pseudonymously in public — though not to the state: §712 puts every beneficial owner's passport number and wallet addresses on a report held by the Registrar. It has become the default offshore choice for DAOs that want their on-chain rules to _be_ the legal rules; most obtain it through [MIDAO](/wiki/dao-governance/tooling/analytics/midao), the RMI’s exclusive registrar.

## Cayman foundation company (2017)

The [Cayman foundation company](https://www.midao.org/blog-posts/marshall-islands-dao-llc-vs-cayman-foundation-full-comparison) predates DAO-specific law but became a crypto workhorse: a company _without shareholders_, purpose-driven rather than profit-distributing, requiring at least one director and a supervisor who act as the legal layer between community votes and off-chain execution. It is the common choice for protocol foundations and token issuers that need a robust, court-tested vehicle more than on-chain purity. The older European route serves the same role — Swiss foundations and associations, most famously the [Ethereum Foundation](https://ethereum.foundation/) (a Swiss Stiftung), anchor many of the largest protocols.

## Choosing a wrapper

The decision usually reduces to three questions. **Who must be identified?** U.S. forms trade anonymity for domestic legitimacy; the RMI preserves member pseudonymity; Cayman concentrates identity in directors. **Where does control really sit?** LLC and DUNA forms keep members in charge; a foundation inserts fiduciaries between votes and execution. **What does the DAO do?** Pure governance travels light; anything touching investors, revenue, or regulated activity needs jurisdiction-specific advice. Regulators are now engaging with the form directly — in June 2026 Malta's financial regulator opened a [formal consultation (Discussion Paper 03-2026) on DeFi and DAO governance](https://www.newsbtc.com/news/malta-regulator-opens-defi-consultation-as-dao-governance-enters-policy/), including how DAOs interact with the EU's MiCA regime, with feedback open to July 10, 2026 — a signal that DAO-specific rules are coming to the EU as well.

## When the wrapper and the code disagree

Every wrapper above is written on the assumption that a DAO's decisions arrive through a governing document. Both DAO-LLC statutes then go further than most readers expect: they make the smart contract _one of those governing documents_, and rank it above the paperwork. Wyoming's [DAO Supplement](https://www.wyoleg.gov/2021/Enroll/SF0038.pdf) is explicit — under W.S. 17-31-115, "[w]here the underlying articles of organization and smart contract are in conflict, the smart contract shall preempt any conflicting provisions of the articles of organization," with a narrow carve-out for the DAO election itself (17-31-104) and the requirement that the articles publish the contract's identifier (17-31-106(a)–(b)). W.S. 17-31-109 vests management "in its members, if member managed, or the smart contract, if algorithmically managed," and 17-31-108 demotes the operating agreement to a gap-filler that applies only "[t]o the extent the articles of organization or smart contract do not otherwise provide." The Marshall Islands chapter is drafted the same way: [52 MIRC Ch. 7](https://rmiparliament.org/cms/images/LEGISLATION/PRINCIPAL/2022/2022-0050/2022-0050_2.pdf) §706(3) makes "the certificate of formation or limited liability company agreement _or smart contracts_" govern relations among members, voting rights, transferability, distributions, and even "[p]rocedures for amending, updating, editing or changing applicable smart contracts," and §708 mirrors Wyoming's management rule.

That ordering matters because the controls a lawyer actually reaches for are _ex ante_ and live in the lower-ranked document: a named multisig signer set, thresholds above which a transfer needs a human, an entrenched asset lock, a duty to refuse execution that would be unlawful, an arbitration clause covering questions of governance validity. An automated settlement layer answers a different question. [Optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance) in particular inverts the default — a proposal is treated as approved unless someone vetoes it inside the challenge window — so the on-chain record can reach "approved, tallied, executable" through inaction, while the wrapper's position is that nothing is authorised until each gate has been passed. Where the contract then fires the treasury outflow itself, the payment is arithmetically correct and the entity's own procedural conditions were never tested. A [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) narrows the window in which that can happen without narrowing the authority; it buys reaction time, not consent.

The reverse mismatch is sharper still, because some wrapper obligations cannot be discharged on-chain at all. RMI §712 requires a **Beneficial Owner Information Report** at formation and with every annual report, identifying each beneficial owner by full legal name, date of birth, street address, "unique identifying number from a nonexpired passport," and the "address(es) and blockchain(s) of all wallets associated with the decentralized autonomous organization" that they hold — held by the Registrar for at least five years after dissolution, with willfully false or omitted reporting declared unlawful. No correctly-tallied vote updates that register. Members also have thin duty-based recourse against one another when the two layers diverge: §709 provides that "no member … shall have any fiduciary duty to the organization or any member except that the members shall be subject to the implied contractual covenant of good faith and fair dealing," and Wyoming's 17-31-110 takes the same line.

There is no settled answer yet, and the statutes decline to give one — RMI §710 even writes a default vote-weight rule (governance tokens held divided by the organization's total "at the time of a vote") that the smart contract is free to override. The practical drafting responses in use are all attempts to keep the two layers from ever reaching different conclusions rather than to adjudicate between them: give the contract no unilateral outflow path, so on-chain approval produces an _instruction_ that named signers must still execute; write the challenge window and its veto holder into the articles rather than only into the contract, so the preemption rule cuts the same way as the compliance gate; or accept algorithmic management honestly and move the compliance controls into the contract itself, where the statute already says they will win. What does not work is drafting an ex ante control into the operating agreement and assuming a court will read it as a limit on code the same statute has told it to prefer.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) is a smart-contract construct on Radix — launching one does not create a legal entity, and Caper does not provide legal wrappers; communities that need one make that jurisdiction choice themselves. What the protocol does address is the _enforcement_ half of the problem: rules that a wrapper would leave to courts and fiduciaries — treasury custody, proposal execution, and each member's [guaranteed exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — are enforced by code, so members are protected from each other by the contract even before anyone is protected from the law by a wrapper.

## References

- David Kerr & Miles Jennings, [A Legal Framework for Decentralized Autonomous Organizations](https://web.archive.org/web/20220609235514if_/https://a16zcrypto.com/wp-content/uploads/2022/06/dao-legal-framework-part-1.pdf) (a16z crypto, 2021) — the UNA "wrap or silo" framework behind the DUNA.
- CFTC, [Federal Court Orders Ooki DAO to Shut Down](https://www.cftc.gov/PressRoom/PressReleases/8715-23) (2023) — the default judgment treating a DAO as a "person" under the Commodity Exchange Act.
- a16z crypto, [The DUNA: An Oasis for DAOs](https://a16zcrypto.com/posts/article/duna-for-daos/) — Wyoming SF50 and the model legislation behind it.
- Legal Nodes, [Wyoming DAO LLC](https://www.legalnodes.com/article/wyoming-dao-llc) — the 2021 DAO Supplement and its filing obligations.
- MIDAO, [Marshall Islands DAO LLC vs Cayman Foundation](https://www.midao.org/blog-posts/marshall-islands-dao-llc-vs-cayman-foundation-full-comparison) — comparison of the two offshore wrappers.
- State of Wyoming, [Enrolled Act No. 73, SF0038 (2021)](https://www.wyoleg.gov/2021/Enroll/SF0038.pdf) — the DAO Supplement, W.S. 17-31-101 _et seq._; see 17-31-108, 17-31-109, and the preemption rule at 17-31-115.
- Republic of the Marshall Islands, [Decentralized Autonomous Organization Act 2022](https://rmiparliament.org/cms/images/LEGISLATION/PRINCIPAL/2022/2022-0050/2022-0050_2.pdf) (52 MIRC Ch. 7) — §706 governing documents, §708 management, §709 standards of conduct, §710 voting, §712 beneficial-owner reporting.

## Rage-quit and exit rights

URL: https://caper.network/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Concept** | Rage-quit / member exit rights |
| **Origin** | [Moloch DAO](https://github.com/MolochVentures/moloch/blob/master/v1_contracts/README.md) (2019) |
| **Core idea** | Burn your shares to withdraw a pro-rata slice of the treasury |
| **Guards against** | Majority capture, unwanted spending, "51% attacks" on shared funds |
| **Common in** | Investment / venture DAOs, grant DAOs, treasury-heavy DAOs |
| **2026 example** | [GnosisDAO treasury redemption](/wiki/daos/networks/gnosisdao) |

**Rage-quit** is the right of a DAO member to leave a decision they disagree with by burning their governance stake and withdrawing a proportional share of the treasury _before_ the disputed action executes. It is the clearest expression of a broader design principle — **exit rights** — that gives minorities a credible alternative to being outvoted: instead of fighting a losing vote, you take your money and go. The primitive was introduced by [Moloch DAO](https://github.com/MolochVentures/moloch/blob/master/v1_contracts/README.md) in 2019 and has since propagated across investment, grant, and treasury-heavy DAOs. For where this fits among the other levers a DAO uses to hold power accountable, see [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) and [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao).

## How rage-quit works

In the [Moloch](https://github.com/MolochVentures/moloch/blob/master/v1_contracts/README.md) model, membership is denominated in _shares_ (voting + economic rights) and _loot_ (economic rights only, no vote). Every passed proposal enters a **grace period** before it can be processed. During that window any member can rage-quit: the contract burns their shares and loot and transfers them a pro-rata portion of every token in the guild bank, in one atomic transaction.

- **Grace period.** Because rage-quit is only possible after a proposal passes but before it executes, members who dislike an outcome can exit while the treasury still holds their share — they are never forced to fund a decision they voted against.
- **Pro-rata redemption.** The payout equals `(your shares ÷ total shares) × treasury`, spread across the full asset mix rather than cashed out at a single price.
- **Guild kick / ragekick.** The membership can also force-exit a member — burning their shares and returning their proportional funds — to remove a bad actor without seizing their capital.
- **Loot vs shares.** Splitting economic rights (loot) from voting rights (shares) lets a DAO admit passive capital that can still rage-quit but cannot steer governance.

## Why exit rights matter

A treasury-controlling DAO concentrates real money behind a majority vote, which creates two failure modes that exit rights directly address:

- **Majority capture.** Without an exit, a coordinated majority can vote to spend or redirect shared funds against a minority's wishes. Rage-quit caps the damage: the worst case for a dissenter is redeeming their own share and leaving, not losing it.
- **Skin in the game.** Because anyone can leave with their proportional treasury at any time, a proposal that destroys value gives members a reason to exit — so the mere _existence_ of the exit disciplines what gets proposed. [a16z crypto's DAO canon](https://a16zcrypto.com/posts/article/dao-canon/) treats credible exit as a foundational governance guarantee, and practitioners at [DAOhaus](https://daohaus.substack.com/p/rage-quit-exit-rights-and-real-skin) frame it as the mechanism that makes membership voluntary rather than captive.

The trade-off is treasury instability: a wave of exits can drain a DAO precisely when it is under stress, and a persistent gap between a token's market price and its "redeemable" treasury value invites arbitrage — the pattern [critics call turning governance into a cash-out button](https://cryptoslate.com/a-223m-dao-vote-could-turn-governance-into-a-cash-out-button/).

That trade-off is real, but the [Aragon DAO](/wiki/daos/infrastructure/aragon-dao) case shows the arbitrage does not wait for an exit right to exist. Aragon had no rage-quit: ANT holders had a promise of treasury control and no mechanism to enforce it. The discount between ANT's market price and the treasury behind it drew buyers anyway, and with no formal way out the only route to the money ran through a majority vote — so the claim arrived as a hostile takeover rather than a redemption, and the association blocked it. A DAO with rage-quit cannot be raided for its treasury, because there is no locked discount to arbitrage in the first place. **The absence of an exit right does not remove the pressure; it converts it into a governance fight.**

## Exit rights in the wild: GnosisDAO's 2026 redemption votes

Between [Moloch](/wiki/daos/public-goods/molochdao) and the mega-treasuries, [Nouns DAO](/wiki/daos/social/nouns-dao) showed exit rights working at scale: its 2023 fork mechanism let a dissenting 20% of holders split off with their proportional share of the treasury, which they did in [two separate forks](https://blockworks.co/news/nouns-fork-two-dao-treasuries-spending). The debate then moved from framework contracts to billion-dollar treasuries in 2026, when [GnosisDAO](/wiki/daos/networks/gnosisdao) took two votes on the same idea seven weeks apart and got opposite answers.

**GIP-150 was defeated.** Posted on [21 April 2026](https://forum.gnosis.io/t/gip-150-should-gnosisdao-let-gno-holders-redeem-their-pro-rata-share-of-the-treasury/12263), it offered any GNO holder a one-time, opt-in exchange of tokens for a pro-rata share of the treasury at net asset value. Illiquid off-chain investments — roughly $25M the DAO had not previously disclosed — and Gnosis Ltd's enterprise value were to be handled by a synthetic claim token, `gLTD-CLAIM`, paying a fixed share of future distributions above a return-of-capital hurdle. The case rested on the treasury dashboard delivered under GIP-148: $22.5M had been deployed to Gnosis Ltd across three quarters while the discount to NAV widened rather than closed. It lost on [Snapshot](https://snapshot.box/#/s:gnosis.eth/proposal/0x32a1ca3d77203dd9e684e25c0b3ca4db62f3a8462e5261573348f6d7d21d21a0): 167,692 GNO for, 432,545 against, on 95 votes.

**GIP-151 passed by dropping the contested half.** Posted on [12 June 2026](https://forum.gnosis.io/t/gip-151-should-gnosisdao-offer-a-one-time-pro-rata-treasury-redemption/12337) by the same author, but this time "developed jointly with the Gnosis founding team", it kept the one-time pro-rata redemption and removed the synthetic claim token and any attempt to value the operating business — stated plainly as a way to avoid "any dispute over the valuation of illiquid or strategic holdings". Redeemers take liquid assets in kind plus a discounted share of capital called to date by GnosisVC; holders who stay keep their full claim on Gnosis Ltd. The eligible base was fixed at 1,364,058 GNO, the 3,000,000 total supply less the DAO's own holdings and Gnosis Ltd's, and redeemed GNO returns to the DAO and leaves circulation permanently. It carried [157,748 GNO for against 2,499](https://snapshot.box/#/s:gnosis.eth/proposal/0x657fbf8892200d24e887c68245cee73b59c466394192be1c10673b39814c74c4), clearing the 75,000 quorum at about 215% on 49 votes.

The pair says more than either vote alone. The proposal that failed asked the DAO to price everything it owned; the one that succeeded asked it to price only what was liquid, and the opposition collapsed from 432,545 GNO to 2,499. But the winning vote also drew roughly a quarter of the weight and half the voters of the one it replaced. Retrofitting an exit right onto an established DAO turns out to be less a fight about whether members may leave than about what they are entitled to carry out with them — and the narrower the answer, the easier it passes.

## Rage-quit at scale: Lido's Dual Governance

Moloch's rage-quit governs millions; [Lido's Dual Governance](/wiki/daos/staking/lido-dao) applies the same idea to the largest staking pool on Ethereum, and it is the clearest evidence available of what a retrofitted exit right does once it is live. LDO holders govern, but stETH holders carry the risk, so since 2025 every Lido governance action on Ethereum passes through a timelock that stETH holders can extend by escrowing stETH: **1%** of supply buys a delay that slides from 5 to 45 days, and **10%** freezes governance until the dissenters have withdrawn their ETH. It is rage-quit rebuilt for a two-token DAO — LDO proposes, stETH leaves. ([Dual Governance 101](https://blog.lido.fi/dual-governance-101-explainer/))

Two features of that design are worth carrying into any exit-right discussion, and both are legible only in the deployed contracts rather than the explainers. Read on **7 August 2026** at Ethereum block **25,705,002**:

- **The exit is slow, and gets slower with use.** After a rage quit, ETH cannot be claimed for **60 days**, and each consecutive rage-quit round adds another **15 days**, to a ceiling of **180**. Moloch's exit is atomic; Lido's is a two-to-six-month decision, which prices repeat use of the hatch rather than merely permitting it. ([DualGovernanceConfig.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/libraries/DualGovernanceConfig.sol))
- **It has never been used.** The [DualGovernance](https://etherscan.io/address/0xC1db28B3301331277e307FDCfF8DE28242A4486E#readContract) state machine has read `Normal` since 8 August 2025 — `vetoSignallingActivatedAt` is still `0` and `getRageQuitEscrow()` still returns the zero address, which the contract documents as meaning no rage quit has occurred. The [signalling escrow](https://etherscan.io/address/0x165813A31446a98c84E20Dda8C101BB3C8228e1c#readProxyContract) holds **0.0000114 stETH** against a first seal of roughly **94,329 stETH**, and all twelve proposals put through the timelock have executed. ([deployed contracts](https://docs.lido.fi/deployed-contracts/))

That is the general lesson, not a Lido-specific one. An exit right bolted onto a large token-weighted DAO is a _coordination_ instrument, not an individual one: no single holder can trigger it, so it only ever fires if a dispersed base organises. Compare [GnosisDAO](/wiki/daos/networks/gnosisdao) above, where the same right had to be put to a vote of the very majority it constrains, and Moloch, where any member can leave alone on any block. The size of the threshold is what decides which of those three a DAO has actually built.

## How Caper approaches this

Caper builds a continuous exit right into every caper by default — no grace-period window to catch, no bolt-on vote required. A member can [redeem out at any time](/wiki/governance/voting) by burning their soulbound vote tokens together with the caper tokens they are exiting; in return the [caper's treasury](/wiki/foundations/what-is-a-caper) pays out a pro-rata share. Crucially, that exit share is the member's _canonical vote weight_ — it scales with the same metric that determines their power in a vote, so influence and redeemable stake stay aligned rather than diverging into the arbitrage gap that redemption-vote critics worry about. The treasury itself is funded through the [bonding curve](/wiki/markets/bonding-curve), so exits settle against a transparent, on-chain balance rather than a negotiated snapshot.

## References

- [MolochVentures/moloch — v1 contracts README](https://github.com/MolochVentures/moloch/blob/master/v1_contracts/README.md). The origin implementation: shares and loot, the proposal grace period, and the atomic pro-rata rage-quit.
- [a16z crypto, "The DAO canon"](https://a16zcrypto.com/posts/article/dao-canon/). Treats credible exit as a foundational governance guarantee.
- [DAOhaus, "Rage quit, exit rights and real skin in the game"](https://daohaus.substack.com/p/rage-quit-exit-rights-and-real-skin). The practitioner framing of exit as what makes membership voluntary.
- [GIP-150 forum thread](https://forum.gnosis.io/t/gip-150-should-gnosisdao-let-gno-holders-redeem-their-pro-rata-share-of-the-treasury/12263) (21 April 2026) and its [Snapshot record](https://snapshot.box/#/s:gnosis.eth/proposal/0x32a1ca3d77203dd9e684e25c0b3ca4db62f3a8462e5261573348f6d7d21d21a0). The rejected standing design, including the `gLTD-CLAIM` synthetic claim token.
- [GIP-151 forum thread](https://forum.gnosis.io/t/gip-151-should-gnosisdao-offer-a-one-time-pro-rata-treasury-redemption/12337) (12 June 2026) and its [Snapshot record](https://snapshot.box/#/s:gnosis.eth/proposal/0x657fbf8892200d24e887c68245cee73b59c466394192be1c10673b39814c74c4). The narrowed proposal that passed, with the 1,364,058 GNO eligible base.
- [Protos, "RFV raiders target Gnosis DAO"](https://protos.com/rfv-raiders-target-gnosis-dao-for-treasury-redemption-proposal/). The skeptical read of redemption campaigns.

## Soulbound tokens in governance

URL: https://caper.network/wiki/dao-governance/concepts/membership/soulbound-tokens
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | Non-transferable ("soulbound") tokens as a governance primitive – binding a vote, credential, or reputation to an account that cannot sell it |
| **Coined by** | Vitalik Buterin, [“Soulbound”](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) (Jan 2022), after World of Warcraft's soulbound items |
| **Formalised in** | [“Decentralized Society: Finding Web3’s Soul”](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763) (Weyl, Ohlhaver & Buterin, 2022) – soulbound tokens (SBTs) |
| **Token standard** | [ERC-5192](https://eips.ethereum.org/EIPS/eip-5192) – Minimal Soulbound NFTs (a `locked()` flag on ERC-721) |
| **Largest live experiment** | Optimism's Citizens' House – four rounds of invitation-based citizenship, then a Season 8 rewrite that replaced invitation with registration |
| **What four years changed** | The badge is no longer permanent (eligibility is recalculated every Season), no longer individual-only (chains and apps hold badges), and no longer issuer-independent (it is revoked and re-issued on request) |
| **Central tension** | Resists vote-buying and Sybils, but relocates the contest to whoever sets the eligibility test |

A **soulbound token** is a token that, once it lands in an account, cannot be transferred or sold – it is bound to that account, or "soul." The term was popularised by Vitalik Buterin's January 2022 essay [Soulbound](https://vitalik.eth.limo/general/2022/01/26/soulbound.html), which borrows it from World of Warcraft, where the best items become soulbound the moment a player picks them up. For a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) the idea cuts to the core of governance design: if the right to govern cannot be bought, then voting power tracks who _earned_ it rather than who can afford it.

Four years of production use have tested that claim, and the largest test – Optimism's Citizens' House – has since rewritten almost every assumption the original design rested on. This page covers why non-transferability matters, the "Decentralized Society" vision that formalised it, the standards and live deployments, what the Optimism record actually shows, the open criticisms, and how [Caper](/wiki/foundations/what-is-a-caper) uses a soulbound vote token.

## Why non-transferability matters for governance

Ordinary governance tokens are freely tradable, which quietly turns governance into a market: whoever values control most can simply buy the votes. Buterin's argument is that for governance rights, [“transferability is counterproductive”](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) – because concentrated interests are the ones most willing to accumulate governance from everyone else, transferable votes flow _toward_ the actors most likely to abuse them. This is the plutocratic failure mode that [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) struggles to escape.

[Vote-escrow (ve) tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) is a partial answer: locking a token for a fixed term makes the resulting vote weight temporarily non-transferable. But the lock can leak back into a market – Aerodrome's `veAERO` position is itself a transferable NFT, so the "locked" vote acquired a spot price and could be sold outright. Soulbound tokens close that gap by making the credential permanently non-transferable at the token level, not just time-locked.

## Souls, SBTs, and Decentralized Society

The concept was formalised in the 2022 paper [“Decentralized Society: Finding Web3’s Soul”](https://www.radicalxchange.org/updates/papers/desoc.pdf) by Puja Ohlhaver, E. Glen Weyl, and Vitalik Buterin ([SSRN 4105763](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763)). Its claim is that Web3 so far encodes only transferable, financialised assets, and that a richer society needs non-transferable **soulbound tokens (SBTs)** to encode the commitments, credentials, and affiliations a "Soul" accumulates over time. Because an SBT cannot be bought or sold, it can carry provenance and reputation that a tradable token cannot.

The paper lists governance applications directly: SBTs enable [Sybil-resistant governance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) (an identity you cannot rent), community-based key recovery, and more honest [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding), where matching weight depends on _distinct_ souls rather than distinct wallets. In each case the point is the same: non-transferability lets a token stand for _who you are and what you have done_, not merely what you hold.

## Standards and live deployments

The minimal on-chain standard is [ERC-5192](https://eips.ethereum.org/EIPS/eip-5192), which extends ERC-721 with a single `locked()` view and an EIP-165 interface flag so a wallet or marketplace can tell a token is non-transferable. Several DAOs run soulbound credentials in production:

- **Optimism's Citizens' House.** The Collective's second chamber votes one member, one vote, and its membership badge is non-transferable – so holders who accumulate `OP` gain nothing in this house beyond the single badge, a deliberate check the [Token House](/wiki/dao-governance/concepts/voting/token-weighted-voting) cannot provide. Its powers now run wider than [retroactive public-goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding): Optimism's own FAQ lists approval of the Collective Intent, veto power over protocol upgrades, and [election of representatives to the Developer Advisory Board](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/faq-citizenship.mdx). How that badge is handed out has changed completely – see the next section.
- **[Human Passport](/wiki/dao-governance/tooling/membership/human-passport) (formerly Gitcoin Passport).** A [stamp-aggregation credential](https://passport.human.tech/) that combines many weak identity signals into a single Sybil-resistance score, used to gate quadratic funding rounds without any one identity provider being decisive. It is now one of the two proof-of-personhood options Optimism accepts from prospective Citizens.
- **Non-transferable vote-locks.** Curve's `veCRV` lock is non-transferable by design – the closest ve-era ancestor of the soulbound idea – even though later forks re-financialised the position (see [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow)).

## The model after four years: what the Optimism record shows

Optimism has run the largest and best-documented soulbound governance experiment in production, and it publishes its own post-mortems. The arc is not the one the 2022 papers projected.

### The invitation phase

Citizenship began as a trust graph. Optimism's history of the House records that [Round 1 began with “24 participants selected by the Optimism Foundation,” Round 2 expanded “to 71 participants, with existing Citizens inviting new members,” and Round 3 grew “to 146 participants through continued invitation”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx). Citizens were chosen, in the Foundation's own framing, "because they were most likely to meet these goals—rather than because they held an intrinsic right to representation."

### The finding that undercut it

Round 6 tested the trust graph against a control. The Foundation reports that [“no significant differences were found between badgeholders (selected via the web-of-trust model) and a random community sample”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx), and that both groups "tended to represent an 'enthusiast' persona—those with time and interest in governance who weren't necessarily Superchain stakeholders." On the dimensions Optimism measured, an invitation graph built out of soulbound credentials selected the same kind of person a lottery would have. Round 5 had already found something adjacent: expertise improved answers to "which projects are most useful?" but not to value-laden questions about what the Collective should prioritise.

### Season 8: registration replaces invitation

The House was then rebuilt around eligibility rather than referral. Three classes of Citizen now register directly, and the criteria are published:

- **Chains** qualify if they [“account for at least 2% of the total revenue share contributed by all chains over the past Season, or are among the top 15 chains by revenue contribution in the past Season”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/faq-citizenship.mdx). One person registers and votes on behalf of the chain.
- **Onchain applications** register through an admin of the project in Optimism's Atlas registry. An organisation holding both an eligible chain and an eligible app receives one badge, not two.
- **Superchain end-users** must meet an activity requirement and [“verify proof of personhood through either Passport or World id”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx) – and [“registration is limited to the first 1000 Citizens”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx).

Optimism also removed the incentive: [“There will be no financial rewards or incentives for being a Citizen or voting in Season 8 and beyond”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx).

### Two properties the 2022 model assumed, now gone

**Permanence.** [“Citizenship eligibility is recalculated at the beginning of every Season, and criteria are subject to change”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx); the FAQ puts it plainly – [“Being a Citizen now doesn't guarantee future Citizens' House membership”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/faq-citizenship.mdx). A soul that expires every season is a subscription, not a soul.

**Issuer independence.** [“If you change your governance wallet after receiving the Citizen badge, the badge will be automatically revoked and re-issued to the new wallet”](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx). That one sentence dissolves the key-loss problem the DeSoc paper worried about, and it does so by conceding the point the same paper flagged as the hard one: the issuer can revoke and re-mint at will. Non-transferability binds the holder. It does not bind the issuer.

### Where the money went

Non-transferability keeps a credential off the secondary market. It says nothing about the primary one. A chain earns a seat in a one-member-one-vote house by contributing at least 2% of Superchain revenue share, or by ranking in the top fifteen on the same measure. Nobody can buy the badge from a holder; eligibility for it is denominated in revenue.

That is the general lesson for any DAO reaching for soulbound governance, and it is not an argument against it. Making a credential non-transferable genuinely closes the resale market, which is where the crudest [vote-buying](/wiki/dao-governance/concepts/voting/vote-markets) lives. What it cannot do is remove the contest – it moves the contest to whatever test the issuer uses to decide who qualifies. Design the eligibility test with the same suspicion you would apply to a token distribution, because it is one.

## Criticisms and open problems

Soulbound governance is not a free lunch, and the DeSoc authors flag most of the tensions themselves. Four years of deployment have moved several of them from theory to record:

- **Privacy.** A public, permanent record of the affiliations and votes bound to an account leaks exactly the kind of profile people may not want on-chain. The proposed answer is zero-knowledge proofs over private SBTs, which is still largely research rather than deployed practice. See [private and shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting).
- **Key loss and recovery.** If a soul cannot be moved, a compromised or lost key cannot be escaped by transferring out. DeSoc's answer is community recovery. Optimism's answer, in production, is simpler and more revealing: the issuer revokes the badge and re-issues it to the new wallet.
- **"Who issues souls?"** Any issuer that gates a soulbound credential becomes a power centre. This is no longer a hypothetical objection – Season 8 citizenship is granted, recalculated, revoked and re-issued by one foundation against criteria it publishes and may change.
- **Reputation is not judgment.** An earned, non-transferable record can ossify – it rewards past participation, which is not the same as being right about the next decision. Optimism's own Round 6 comparison found its earned badgeholder set statistically indistinguishable from a random sample of the community.

## How Caper approaches this

Caper mints a soulbound [vote token](/wiki/governance/voting) as the on-chain record of participation. In the contract it is a `DIVISIBILITY_NONE` resource (whole units only), described in its own metadata as a "Soulbound proof-of-vote token," and exactly one is minted each time a member votes. It is non-transferable by construction: the token's `depositor` role is restricted to the DAO component itself (`global_caller`), with the updater set to `deny_all`, so a holder can never deposit one into another account. A holder may only withdraw the token to burn it and redeem – there is no peer-to-peer path, and nothing to buy or sell.

Crucially, that soulbound record is _not_ the whole story – Caper is not "your bag doesn't count." Vote weight is the product of a member's held governance tokens and their earned votes, normalised by the totals in circulation: weight is `(held × votes) / (supply × circulation)`. The earned, unbuyable vote count is a _multiplicative factor_ alongside stake, so a large bag alone cannot capture control (a member who has never voted carries a zero factor, and the very first vote is snapshotted before its token is minted, so it lands at zero weight), while a long voting history with no stake carries none either. The same weight sets each member's pro-rata [exit](/wiki/governance/execution) claim on the treasury, and the vote tokens are burned as they are spent. The result is the property soulbound tokens are reached for in the first place: the decisive, unbuyable part of who governs is _earned_, not purchased – without discarding the stake that keeps skin in the game. See [voting mechanisms](/wiki/governance/voting-mechanisms) for the full weighting model.

The eligibility question the Optimism record raises has a narrow answer here, and it is worth stating rather than claiming more: a caper's vote tokens are minted by voting, so the only test for acquiring one is having voted before. There is no committee, no season, and no revocation path – but equally, no proof of personhood, so a caper's soulbound record is Sybil-resistant only to the extent that holding tokens and paying fees is.

## References

- [Vitalik Buterin – Soulbound (2022)](https://vitalik.eth.limo/general/2022/01/26/soulbound.html)
- [Ohlhaver, Weyl & Buterin – Decentralized Society: Finding Web3's Soul (SSRN, 2022)](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763) · [PDF](https://www.radicalxchange.org/updates/papers/desoc.pdf)
- [ERC-5192: Minimal Soulbound NFTs](https://eips.ethereum.org/EIPS/eip-5192)
- [Optimism Community Hub – Experimentation with Citizenship (source)](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx)
- [Optimism Community Hub – Becoming a Citizen (source)](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/citizenship-selection.mdx)
- [Optimism Community Hub – Citizen FAQ (source)](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/faq-citizenship.mdx)
- [Optimism Docs – Governance FAQ](https://docs.optimism.io/governance/gov-faq)

_A note on the Optimism citations._ The handbook that used to live at `community.optimism.io/citizens-house/…` has been folded into `docs.optimism.io`, and every old path in that subtree now returns HTTP 200 while serving the same unrelated protocol-upgrades page. Those URLs look alive to any link checker and are not. This page therefore cites the handbook's source files in Optimism's `community-hub` repository, which are canonical and resolve correctly. Read 11 August 2026.

## SubDAOs, working groups & pods

URL: https://caper.network/wiki/dao-governance/concepts/membership/subdaos-and-working-groups
Updated: 2026-08-03

| Concept | Modular sub-organization of a DAO – decomposing a single large collective into smaller, semi-autonomous units so coordination scales |
| --- | --- |
| Core forms | **SubDAOs** (own token + treasury), **working groups** (budgeted teams, no separate token), **pods** (a multisig + membership layer) |
| Motivation | Token-weighted voting over every operational decision does not scale; delegation and specialisation move work to focused units |
| Reference example | [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao) Endgame "Stars"; [ENS DAO](/wiki/daos/infrastructure/ens-dao) working groups |
| Common tooling | [Safe](/wiki/daos/infrastructure/safe-dao) multisigs, [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles, [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), [Colony](/wiki/dao-governance/tooling/frameworks/colony), Metropolis (Orca) pods |
| Related | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation), [Legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) |

A DAO that starts as one token holding one treasury and one voting queue eventually hits a wall: routing every hire, grant, and integration through a global token vote is slow, low-turnout, and swamps holders with decisions they have no context for. The response is **modular structure** – breaking the monolith into smaller units that own a slice of the mandate and act without waiting for the whole token base to weigh in. Three patterns dominate, distinguished mainly by how much autonomy and separate capital each unit gets: **SubDAOs**, **working groups**, and **pods**.

## Why DAOs decompose

[Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) is a blunt instrument for day-to-day operations. Quorum is hard to reach, most holders rationally abstain, and a treasury of anonymous voters cannot supervise a design team or negotiate a partnership. Large protocol DAOs converge on the same fix that scaling human organisations always reach for: **specialisation and delegation**. A focused unit is given a budget, a scope, and the authority to spend inside it, and the token base retreats to setting mandates and ratifying budgets rather than approving every action. This is the operational face of [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) – power is distributed _outward_ into units, not just downward over time.

The three forms sit on a spectrum of autonomy. A **working group** is an internal team on a budget – no separate token, funds flow from the parent treasury. A **pod** is a lightweight on-chain container – a multisig plus a membership layer – used to give any team custody and permissions without a governance overhaul. A **SubDAO** goes furthest: its own token, its own treasury, and its own governance, federated to the parent by shared infrastructure and economic ties rather than direct control.

## SubDAOs

A SubDAO is a semi-autonomous DAO nested under a parent. It typically issues its own governance token, runs its own proposal process, and holds its own treasury, while remaining tied to the parent through shared reserves, product integration, and reward flows. The canonical example is [Sky](/wiki/daos/stablecoins/sky-dao) (rebranded from MakerDAO in [August 2024](https://www.theblock.co/post/313235/makerdao-mkr-sky-dai-stablecoin-usds)), whose [Endgame](https://sky.money/) plan restructures the protocol into a network of SubDAOs it brands as **Stars** – each a self-governing unit with its own token that plugs into the core Sky Protocol for USDS liquidity and rewards. The first Star, [Spark](https://spark.fi/), spun a lending protocol (SparkLend plus a savings product) out of Maker and launched the **SPK** governance token.

The appeal is focus and blast-radius control: a Star can move fast and even fail without taking the parent down with it. The cost is **token proliferation** – every SubDAO adds a governance token to bootstrap, a treasury to secure, and a fresh surface for capture or apathy, so the coordination problem is divided rather than dissolved.

## Working groups

A working group keeps decomposition lighter: a standing team with an elected mandate and a budget drawn from the parent treasury, but _no_ separate token. [ENS DAO](/wiki/daos/infrastructure/ens-dao) is the reference implementation. It runs [three working groups](https://basics.ensdao.org/working-groups) – Meta-Governance, ENS Ecosystem, and Public Goods – each led by **three stewards** elected to 12-month terms, with spending executed through a [Safe multisig](https://docs.ens.domains/dao/) that requires three-of-four signatures (the three stewards plus an appointed secretary). Budgets are approved by the whole DAO in a funding window, then the group spends inside that envelope without further token votes.

Working groups keep governance surface small – one token, one treasury, delegated execution – at the price of weaker separation: the parent DAO retains direct control and the groups depend on it for legitimacy and funds. The same pattern appears as "guilds" or "committees" across many DAOs; the [compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) and accountability of these teams is a governance problem in its own right.

Working groups are the cost centre most DAOs report as “governance”. ENS’s published budgets, including what its structure cost while paused for a retrospective, are worked through on [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs).

## Pods

A pod is the primitive underneath both patterns: a small, permissioned on-chain unit that can hold funds and act, without redesigning the whole organisation. Orca Protocol – now [Metropolis](https://metropolis.mirror.xyz/ozkx0ZMwIzyahRJiQKpNv_8r7vAhOo-8tucjONhXJHI) – popularised the term, defining a pod as a [Gnosis Safe](/wiki/daos/infrastructure/safe-dao) multisig wrapped in a membership layer, where access is granted through **membership NFTs** that act like keycards. Pods can be composed – one pod can manage another's members, or membership can be gated on holding a token or passing a vote – so an organisation can assemble a shifting tree of teams without breaking the parts that already work.

Pods are structure without a new token: they inherit the parent's economics and simply carve out custody and permissions. That makes them the cheapest way to delegate, and the reason multisig-plus-membership tooling underlies most working groups and many SubDAOs in practice.

## Frameworks and tooling

The decomposition patterns are supported by a layer of DAO frameworks:

- [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) – its OSx stack supports nested DAOs and pluggable governance, so a parent can install sub-organisations as first-class on-chain entities ([aragon.org](https://aragon.org/)).
- [Colony](/wiki/dao-governance/tooling/frameworks/colony) – organises work into hierarchical **domains** (sub-teams) with a [reputation](https://docs.colony.io/) system that weights influence by contribution rather than raw token holdings.
- [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) – its **Roles** modifier lets a DAO grant a pod or working group scoped permissions over the parent treasury (spend only these assets, call only these contracts), enabling delegation without handing over the keys ([zodiac.wiki](https://www.zodiac.wiki/)).
- Metropolis (Orca) and Safe – the multisig-and-membership base layer most pods and groups are actually built on.

## Trade-offs and risks

Decomposition trades one hard problem for several smaller ones. The gains – focus, faster execution, contained failure, and clearer accountability – come with real costs:

- **Fragmentation.** Every new unit is another treasury to secure and another governance process to keep alive; capture or apathy in a SubDAO is still capture.
- **Principal-agent drift.** Delegating spend to a group weakens the token base's ability to supervise it; scoped permissions (Zodiac Roles) and budget windows mitigate but do not remove this.
- **Token proliferation.** SubDAO tokens dilute attention and liquidity and multiply the [attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).
- **Coordination overhead.** Units that are too autonomous drift from the parent's mandate; too dependent, and nothing was really decentralised.

Modular structure is best read as an answer to why [DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) at scale – not a guarantee against it.

The risk that gets written about least is the one at the end. Decomposition is almost always specified without a closing clause, so a body that has outlived its mandate keeps its budget and its permissions until somebody spends governance capital to shut it down. How that is done in practice – the dissolution proposal type, what happens to unspent budget and mid-flight obligations, and where the mandate goes afterwards – is covered in [council dissolution and governance unwinding](/wiki/dao-governance/concepts/analysis/council-dissolution).

## How Caper approaches this

Caper starts from the opposite end of the spectrum. Instead of one large DAO that later carves out sub-units and mints them tokens, on Caper _every_ unit is its own [caper](/wiki/foundations/what-is-a-caper) from birth – a standalone DAO with its own bonding-curve token and treasury. Coordination between capers is then expressed as [governed proposals](/wiki/governance/proposals) rather than an org chart. A caper's treasury can pass an **INVEST** proposal to buy another caper's token, taking a real economic stake in it, and a **VOTE** proposal to cast that stake in the other caper's governance – so a parent caper (such as $CAPER) can seed and steer a network of capers by holding and voting their tokens, not by supervising internal pods.

Because every caper carries the same primitives, the structure is **fractal**: a caper can spin a division out as its own sub-caper – creating one is [permissionless](/wiki/foundations/what-is-a-caper), so a team or the parent's treasury can bring it into being – back it with an INVEST stake, and that sub-caper can in turn spawn and fund units of its own, self-similar at every level. Each unit is a standalone economic entity: its bonding-curve token and treasury are its own **P&L**, rising or falling on its own results rather than being cross-subsidised on a parent's balance sheet. A parent's exposure is exactly its holding of the sub-caper's token plus its [treasury share](/wiki/governance/proposals) – so delegating a line of work means backing a unit that sinks or swims on its merits, not carrying it as an internal cost centre.

The result resembles a federation of SubDAOs, but decentralised from the start: there is no monolith to decompose, no separate working-group multisig to trust, and every cross-unit action – funding or voting – is an on-chain proposal weighted by the same [canonical vote weight](/wiki/governance/proposals) as any other decision. The coordination is a market of capers rather than a hierarchy inside one.

## Sybil resistance in DAOs

URL: https://caper.network/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Topic** | Stopping one actor from posing as many to capture a non-plutocratic vote |
| **Named after** | The Sybil attack (Douceur, 2002) — one entity forging many identities |
| **Approaches** | Token cost (plutocratic) · Proof-of-personhood · Social-graph vouching · Credential/stamp aggregation · Participation gating |
| **Systems** | World ID · BrightID · Proof of Humanity · [Human Passport](/wiki/dao-governance/tooling/membership/human-passport) |
| **Central tension** | Sybil resistance ↔ privacy, inclusivity, and coercion-resistance |
| **Related** | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

**Sybil resistance** is a DAO's defence against one person secretly controlling many identities in order to swing a vote. The name comes from a [2002 paper by John Douceur](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/) (itself borrowing the title of a book about multiple-personality disorder), which showed that in any open, permissionless system without a trusted identity authority, a single adversary can forge enough distinct identities to overwhelm honest participants. For a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) the stakes are direct: the moment voting power is measured by anything _other_ than money — one-person-one-vote, [quadratic voting](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), reputation — a cheap way to mint fake members is a cheap way to seize the treasury.

## Why token voting sidesteps — and re-creates — the problem

Plain [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) is Sybil-resistant by construction: splitting your tokens across a thousand wallets gives you exactly the same total voting power, so fake identities buy nothing. That resistance is bought at a steep price — it is simply **plutocracy**, where whoever holds the most tokens decides. Every attempt to soften plutocracy by weighting votes more equally — giving each _person_ a say rather than each _token_ — immediately re-opens the Sybil door, because now each additional identity is worth something. Sybil resistance and resistance to plutocracy pull against each other, and bridging them is the central unsolved problem of egalitarian on-chain governance. ([a16z governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## Proof of personhood

The dominant answer is **proof of personhood**: a credential asserting that a wallet belongs to a distinct, unique human, without necessarily revealing _which_ human. The leading approaches trade off differently on privacy, decentralization, and resistance to fakery:

- **Biometric** — [World ID (Worldcoin)](https://world.org/) scans a person's iris with a physical "Orb" and issues a unique, privacy-preserving credential. Strong uniqueness guarantees, but it centralizes hardware and raises biometric-privacy concerns.
- **Social graph** — [BrightID](https://www.brightid.org/) establishes uniqueness through a graph of mutual verifications in video calls, on the theory that fake accounts cannot easily forge dense, genuine social connections.
- **Vouching + registry** — [Proof of Humanity](https://proofofhumanity.id/) maintains an on-chain registry of humans, each entry backed by a video and a deposit, and challengeable by anyone for a reward.
- **Credential aggregation** — [Human Passport](/wiki/dao-governance/tooling/membership/human-passport) (built at Gitcoin as Gitcoin Passport) combines many weaker "stamps" (accounts, credentials, prior on-chain activity) into a single Sybil-resistance score, avoiding reliance on any one identity provider.

Zero-knowledge techniques increasingly sit on top of these, letting a voter prove "I am a unique registered human" without linking the vote back to the underlying identity. ([Vitalik Buterin: What do I think about biometric proof of personhood?](https://vitalik.eth.limo/general/2023/07/24/biometric.html))

## Where it matters most: quadratic voting and funding

Sybil resistance is not an abstract nicety — it is the load-bearing assumption under [quadratic voting and funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding). Quadratic schemes deliberately make additional influence from a _single_ identity expensive (cost grows with the square of votes), which only dampens whales _if_ each participant is one person. Without a working personhood layer, an attacker splits into many identities and the quadratic penalty evaporates entirely. This is why [Gitcoin](https://www.gitcoin.co/)'s quadratic-funding rounds spend heavily on Sybil defence: undetected fake donors don't just steal matching funds, they silently break the mechanism's core fairness promise. ([Siddarth et al., "Who Watches the Watchmen?"](https://arxiv.org/abs/2008.05300))

## Airdrop farming: Sybil attacks for money, not votes

The Sybil attacks DAOs actually meet at scale are not attempts to swing a vote — they are attempts to collect a distribution many times over. An [airdrop](/wiki/economics/airdrops-and-token-distribution) pays per qualifying address, so an attacker who can generate a thousand addresses that each clear the eligibility bar collects a thousand allocations, and no personhood layer stands between them and the money. The defence has therefore been behavioural clustering rather than identity: group addresses by funding source, transaction timing and interaction pattern, and disqualify the clusters.

Two artefacts show how far that got. Hop Protocol opened [a public GitHub repository](https://github.com/hop-protocol/hop-airdrop) where anyone could file a Sybil report against its own airdrop, paying reporters out of the recovered allocation — crowdsourced detection in place of an identity system. The Arbitrum Foundation then reused the output: its [published eligibility rules](https://docs.arbitrum.foundation/airdrop-eligibility-distribution) disqualify outright any address flagged in the Hop bounty, alongside two subtractive heuristics — minus one point if every transaction in the wallet falls inside a single 48-hour window, minus one if the wallet holds under 0.005 ETH and has touched fewer than two contracts.

Both details are worth sitting with. A bug-bounty issue tracker became the industry's shared blocklist, which is what an identity layer looks like when nobody has built one. And the heuristics are deductions rather than exclusions, so a farmer can lose two points and still qualify — a deliberate choice to under-punish rather than strip a genuine user, and an admission that the classifier is not good enough to be trusted with a hard cut.

## The hard limits

No personhood system is complete, and each has an honest failure mode. **Coercion and vote-selling** survive proof of personhood entirely — a verified-unique human can still be paid or pressured to vote a certain way, and a market in rented votes needs no fake identities. **Privacy and exclusion** cut the other way: biometric and government-ID methods risk surveillance and lock out anyone unwilling or unable to enrol, while looser social methods are easier to game. And every registry faces the base-rate problem that even a small false-acceptance rate, at scale, admits thousands of duplicates. The practical consensus is that Sybil resistance is a spectrum to be raised, not a box to be checked — which is why many DAOs layer personhood scores on top of, rather than instead of, some economic stake.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does not try to verify that each member is a unique human — it makes extra identities pointless instead. Voting weight is the product of a member's stake _and_ their demonstrated [participation](/wiki/governance/voting), and participation is tracked by a [soulbound token](/wiki/dao-governance/concepts/membership/soulbound-tokens) minted one per vote that can never be transferred or bought. A freshly created wallet therefore starts with zero participation and casts a zero-weight first vote, so spinning up extra empty identities adds nothing: each one would have to independently acquire real stake _and_ vote, repeatedly, to earn any weight at all. The cheap half of a Sybil attack — manufacturing identities — buys no influence; the expensive half — genuine stake and repeated participation from every identity — is exactly what an honest, engaged member already does. It is a participation gate, not a proof of personhood, and it deliberately trades the egalitarian one-human-one-vote ideal for something a contract can enforce without biometrics or a trusted registry. That same earned weight also sets each member's pro-rata [exit](/wiki/governance/execution) claim on the treasury.

## References

- John R. Douceur, [The Sybil Attack](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/) (2002) — the founding statement of the problem.
- Divya Siddarth et al., [Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocols](https://arxiv.org/abs/2008.05300) (2020).
- Vitalik Buterin, [What do I think about biometric proof of personhood?](https://vitalik.eth.limo/general/2023/07/24/biometric.html) (2023).
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).

## Bootstrap budgets and ratification votes

URL: https://caper.network/wiki/dao-governance/concepts/treasury/bootstrap-budgets-and-ratification-votes
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Also called** | Bootstrap budget · administrative budget · initial funding · ratification vote |
| **What it is** | The DAO's first operating budget, set by a foundation or transition body before token holders are able to vote on it |
| **The three shapes** | Ratified after the fact · appropriated in advance in the DAO's own token · grant-funded ahead of the treasury transfer |
| **Worked cases** | [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao) (2023) · [Uniswap DAO](/wiki/daos/dexs/uniswap-dao) (2022–2023) · Radix (2026) |
| **Related** | [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs), [Council dissolution](/wiki/dao-governance/concepts/analysis/council-dissolution), [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) |

A **bootstrap budget** is the money a DAO spends before it is able to decide anything. Someone has to pay for the legal entity, the first contributors, the audits and the infrastructure, and that spending starts before there is a functioning vote to authorise it – so in practice a foundation, a development company or an elected transition body sets the first budget, and the DAO's first budget vote is held afterwards. What that vote is actually deciding varies, and the difference is worth naming: it can be a genuine appropriation, a renegotiation of terms, or a ratification of transfers that already happened.

This is the mirror image of [council dissolution](/wiki/dao-governance/concepts/analysis/council-dissolution). Both are moments where authority sits with a body the token holders did not elect through the DAO's own process – at the start because the process does not exist yet, at the end because it is being wound down. Both are also where the gap between formal governance rights and actual control over funds is widest.

## Why the first budget is never the first vote

Three constraints push the budget ahead of the vote, and none of them is avoidable by better intentions.

- **The entity precedes the treasury.** A DAO cannot hold a bank account, sign an employment contract or pay an auditor until some legal [wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) exists, and forming that wrapper costs money. The first spend is therefore always pre-governance by construction.
- **Launch spending is front-loaded and time-boxed.** Audits, listings, market making and legal opinions cluster around the launch date, when the voter base is newest and turnout is least reliable.
- **The people writing the budget are the only people who know it.** At launch the operating detail – headcount, vendor contracts, runway – lives entirely with the founding team. A token holder voting on it in week one is voting on a document they cannot audit.

The consequence is that the DAO's leverage over its own first budget is much narrower than its formal voting rights suggest. It rarely gets to decide whether the money is spent. It gets to decide what conditions attach to the remainder.

## Ratification after the fact: Arbitrum, 2023

The clearest worked example is [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao)'s first proposal. [AIP-1](https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30) was put up in March 2023 as an omnibus that, among other things, asked token holders to ratify the Arbitrum Foundation's setup – including an "Administrative Budget Wallet" already holding **7.5% of the ARB supply**. Delegates read it as being asked to approve a transfer that had already occurred, and voted it down: [the Snapshot record](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x3be7368a662d1cf12fa4da768d626edbc013be0dc7b994fef2e24d9a54e4033a) closes at **100,343,537 against to 16,418,340 for**, with 14,120,336 abstaining across 26,141 voting addresses – roughly **77% against**.

What happened next is the part worth studying, because it shows exactly what the rejection did and did not achieve. A follow-up proposal asked the Foundation to [return 700M ARB to the DAO treasury](https://forum.arbitrum.foundation/t/proposal-return-700m-arb-to-the-dao-treasury/13490) outright. That also failed, and by a wider margin: [118,334,390 against to 20,526,942 for](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x3ae4c725f7cb82d450b6fe8517178b2a0a51d1105beaad0adb421df1bc8f8cc4) across 43,392 addresses, about **84% against**. The same electorate that refused to bless the allocation also refused to claw it back.

What passed was the renegotiation. [AIP-1.1](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360) disclosed that **0.5% of supply had already been transferred out** of the budget wallet, put the remaining **7% (700M ARB) under a four-year linear lockup** running from the date of the Snapshot approval – about 175M ARB unlocking per year – and published a first-year operating budget of **$36M**, split $16M general and administrative, $9M R&D, $5M technical infrastructure and $6M events, marketing and communications, to be funded 50% in USD and 50% in ARB. It carried [137,012,025 for to 1,224,386 against](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae) across 45,230 addresses, roughly **98% in favour**. A companion governance proposal, [AIP-1.2](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x373dfa89fc9c5ccba8ed83fa3fa4f233edd270075b5f8f4f3902b408318d9d17), passed with a similar margin.

Read the four votes as a sequence and the pattern is unambiguous. Ratification failed, reversal failed, and terms-plus-disclosure passed overwhelmingly. The DAO's real instrument was never the yes/no on the allocation. It was the [lockup schedule](/wiki/economics/token-unlocks-and-vesting), the reporting requirement, and the itemised budget it could measure the next request against.

## Appropriated in advance, and still not fixed: Uniswap, 2022–2023

[Uniswap](/wiki/daos/dexs/uniswap-dao) did it the other way round. The Uniswap Foundation was [put to a temperature check](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xee4851601143b1e9655be7168ca2d0f119fba31afadf2a7f808ea12b7bb4e9df) in August 2022 and its funding approved by the DAO before it began operating – **$74M in total**, split roughly **$52.3M in grants and $21.7M in operations**, sized to run through the end of 2024. An ex ante appropriation, which is the textbook answer to the Arbitrum problem.

It still did not produce a fixed budget, for a reason specific to DAOs: the request was denominated in the DAO's own token. The first tranche was written as **2,547,002 UNI targeting $20M**, and by the time it settled on 25 August 2022 UNI had fallen 13.7% to $7.05, so the Foundation [received $17.3M](https://gov.uniswap.org/t/rfc-complete-initial-funding-of-the-uniswap-foundation/21956) rather than $20M. A year later it returned to ask for the remainder, **$62.37M** – the $56.7M outstanding plus a **10% buffer against exactly that volatility** – and that request went [to an on-chain vote](https://gov.uniswap.org/t/governance-proposal-complete-initial-funding-of-the-uniswap-foundation/22020) in October 2023.

The lesson generalises past this one case. A budget voted in the DAO's own token is a budget whose real size is set by the market between the vote and the transfer, and the correction is always another vote. That is one of the mechanical reasons a DAO holding only its own token has less budgetary control than its balance sheet implies – the reason [treasury diversification](/wiki/dao-governance/concepts/treasury/dao-treasury-management) is a governance question and not just a portfolio one.

## When the treasury arrives after the entity: Radix, 2026

A third shape is currently playing out at Radix, and it inverts the ordering again: here the bootstrap grant is explicitly small, and the treasury transfer is conditional on the DAO existing first. The Radix Foundation [announced in 2026](https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) that it approved **a two-stage grant of $67,000 and 10m XRD** to fund the DAO's set-up and initial operation, with the community-elected Accountability Council leading the entity formation, and stated that "when a community entity is established, the intention is for the remaining treasury to transfer to it, subject to the legal and compliance steps any such transfer requires."

Sequenced that way, the pre-governance spend is a rounding error against the treasury it precedes, which removes the Arbitrum-style ratification problem almost entirely. It creates a different one. Until the transfer completes, the DAO governs a set-up grant while the assets it was formed to steward sit with the outgoing body, and the transfer itself is gated on legal steps no vote controls. A DAO in that position has full formal authority over almost none of its eventual balance sheet, which is a live risk rather than a settled arrangement – and one worth re-checking against the primary source rather than assuming, since a stalled transfer looks identical to a pending one right up until it doesn't complete.

## What the DAO actually retains

Across all three shapes the token holders' effective levers are the same short list, and none of them is the headline vote.

- **The unlock schedule.** Converting an outright allocation into a linear release is the single change that reliably survives contact with a hostile electorate, because it costs the recipient nothing today and it is enforceable without trust.
- **Itemisation, at a granularity that can be checked later.** A budget published as four line items is a budget the next request can be measured against. A budget approved as one number is not.
- **Tranching.** The next tranche is the only reliable point of leverage, which is why splitting a multi-year budget into dated requests matters more than the total.
- **Denomination.** Whether the budget is expressed in the DAO's token or in stable value determines who carries the price risk between the vote and the transfer.
- **Reporting obligations.** The cheapest thing to win in a bootstrap negotiation and the most useful later, since it is what makes [operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) comparable across periods at all.

What the DAO generally cannot recover is money already moved. Arbitrum's electorate tried and declined by a larger margin than the original rejection. Treating the first budget as reversible is the mistake; treating it as the last unconditional grant the founding body will receive is the accurate reading.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no pre-governance phase to budget for, because it has no launch to fund. The treasury fills from the [bonding curve](/wiki/markets/bonding-curve) as people buy, from the first buy onward, so there is never an interval in which money has been raised but governance is not yet running – and there is no founding allocation to ratify later, because the founder is compensated by the per-buy skim, which never enters the treasury at all. See [raising funds](/wiki/markets/raising-funds) for how capital actually arrives.

The practical effect is that every outflow from a caper's treasury is a proposal, from the first one. There is no unconditional first tranche and nothing that got spent before the vote existed – which removes this particular failure mode rather than managing it, at the cost of not being able to spend anything before there is a community to authorise it.

## References

- [AIP-1: Arbitrum Improvement Proposal Framework](https://forum.arbitrum.foundation/t/aip-1-arbitrum-improvement-proposal-framework/30) – forum.arbitrum.foundation, March 2023. The omnibus that asked for ratification of the Administrative Budget Wallet.
- [AIP-1 Snapshot record](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x3be7368a662d1cf12fa4da768d626edbc013be0dc7b994fef2e24d9a54e4033a) – the closing tally: 16,418,340 for, 100,343,537 against, 14,120,336 abstain, 26,141 voting addresses.
- [Proposal: Return 700M $ARB to the DAO Treasury](https://forum.arbitrum.foundation/t/proposal-return-700m-arb-to-the-dao-treasury/13490) and its [Snapshot record](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x3ae4c725f7cb82d450b6fe8517178b2a0a51d1105beaad0adb421df1bc8f8cc4) – the clawback attempt, 118,334,390 against to 20,526,942 for.
- [Proposal: AIP-1.1 – Lockup, Budget, Transparency](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360) – the 0.5%-already-transferred disclosure, the four-year linear lockup on the remaining 7%, and the itemised $36M first-year budget. [Snapshot record](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x7203289844e807781e8d2ec110d4b97a79a29944cae06a52dbe315a16381a2ae): 137,012,025 for to 1,224,386 against.
- [AIP-1.2 – Foundation and DAO Governance](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x373dfa89fc9c5ccba8ed83fa3fa4f233edd270075b5f8f4f3902b408318d9d17) – Snapshot record, 137,606,930 for to 280,122 against.
- [[Temperature Check] Create the Uniswap Foundation](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xee4851601143b1e9655be7168ca2d0f119fba31afadf2a7f808ea12b7bb4e9df) – August 2022, the first of the two checks preceding the funding vote.
- [[RFC]: Complete initial funding of the Uniswap Foundation](https://gov.uniswap.org/t/rfc-complete-initial-funding-of-the-uniswap-foundation/21956) – gov.uniswap.org, September 2023. The $74M approval, the 2,547,002 UNI first tranche that delivered $17.3M, and the $62.37M remainder request. Taken to a vote as [[Governance Proposal]](https://gov.uniswap.org/t/governance-proposal-complete-initial-funding-of-the-uniswap-foundation/22020).
- [Foundation Update: Moving to Maintenance Mode](https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) – radixdlt.com, 2026. The two-stage $67,000 and 10m XRD set-up grant, and the treasury transfer conditioned on a community entity existing.

## Contributor compensation in DAOs

URL: https://caper.network/wiki/dao-governance/concepts/treasury/dao-contributor-compensation
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Topic** | Contributor compensation in DAOs |
| **What it is** | How a DAO pays the people who build and run it, with no employer, payroll, or HR department |
| **Common models** | Salaries & streaming · bounties · grants · retroactive funding · peer allocation |
| **Paid from** | The [DAO treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management), authorized by a [governance vote](/wiki/dao-governance/concepts/voting/proposal-lifecycle) |
| **Central tension** | Fair, sustainable pay vs. token-price volatility, contributor churn, and unclear legal status |
| **Reading** | [a16z — DAOs, a canon](https://a16zcrypto.com/posts/article/dao-canon/) |

**Contributor compensation** is how a DAO pays the people who build, maintain, and govern it. It is one of the hardest operational problems a DAO faces, because a DAO has no employer of record: there is no company to sign an employment contract, run payroll, withhold taxes, or offer benefits. Instead, every payment comes out of the shared [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and must ultimately be authorized through [governance](/wiki/dao-governance/concepts/voting/proposal-lifecycle) — which turns "paying a teammate" into a public, on-chain, community-approved act. Because compensation is typically the single largest recurring outflow from a treasury, how a DAO answers this question directly determines its runway and its survival.

## Ways DAOs pay contributors

No single model dominates; most mature DAOs run several at once, matched to the type of work. Whichever the DAO picks, the payment still has to leave the treasury with a paper trail behind it — invoicing and accounts-payable tooling such as [Request Finance](/wiki/dao-governance/tooling/treasury/request-finance) is the layer that turns an approved budget into bills, approvals and books.

- **Salaries and streaming.** Ongoing roles are paid a recurring wage, increasingly as a real-time _stream_ rather than monthly lump sums — protocols like [Superfluid](https://docs.superfluid.org/) let a DAO pay by the second and cancel the stream the moment a contributor stops, so pay tracks work continuously instead of in arrears.
- **Bounties and task-based pay.** Discrete, scoped deliverables are posted with a fixed reward and paid on completion — low-commitment, easy to open to newcomers, but weak for retaining long-term contributors.
- **Grants.** The DAO funds an external team or working group to build something, usually against milestones. Quadratic-funding rounds such as [Gitcoin](https://www.gitcoin.co/) let a community's small donations decide allocations rather than a committee.
- **Retroactive funding.** Pay _after_ impact is proven rather than promised. [Optimism's Retro Funding](https://gov.optimism.io/c/grants/retrofunding/46) (RetroPGF) has distributed tens of millions of OP to contributors whose work already shipped, inverting the risk of speculative up-front grants – though Optimism [paused the programme in January 2026](https://www.optimism.io/blog/season-9-from-experiment-to-organization) for at least twelve months, so the model is currently better evidenced than it is available.
- **Peer allocation.** Contributors decide each other's pay. [Coordinape](https://docs.coordinape.com/) runs "circles" in which each member distributes a fixed budget of GIVE tokens per epoch to the peers whose contributions they valued, converting distributed judgment into a reward split.

## Organizing the work behind the pay

Compensation only makes sense once responsibility is scoped, so DAOs wrap work in structures that a budget can attach to. **Working groups** and **guilds** gather contributors by function — design, engineering, governance, treasury — and receive a periodic budget they allocate internally. Larger organizations spin off [sub-DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos): semi-autonomous units with their own mandate and multisig, funded by the parent but free to run their own compensation. This lets a DAO delegate the messy, high-frequency work of paying people down to the smallest group that actually has the context to judge contribution, while the top-level [proposal process](/wiki/dao-governance/concepts/voting/proposal-lifecycle) only ratifies the aggregate budget.

What those structures cost to run, once compensation, legal retainers and tooling are added up, is set out with published figures on [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs).

## Paying in the native token

DAOs frequently pay part of compensation in their own [governance token](/wiki/dao-governance/concepts/treasury/dao-tokenomics), which is attractive on paper: it costs no stablecoins, and it turns contributors into [voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) stakeholders whose incentives point at the protocol's long-term value. The costs are real, though. Contributors carry the token's price volatility as personal income risk; unvested grants can create heavy sell pressure when they unlock; and paying core work in a governance token quietly concentrates [voting power](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) in the hands of insiders. The standard mitigation is **vesting** — multi-year schedules with a cliff — which aligns contributors with a time horizon longer than the next token pump, at the cost of locking up income they cannot spend. Most healthy programs blend a stablecoin base (to pay rent) with a vesting token grant (to align upside). The same exposure runs through governance payroll: [delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs) that set budgets in dollars but pay in the governance token spend the most tokens exactly when the token is cheapest, which is what forced Arbitrum to cut its per-proposal budgets 28–40% in July 2026. The constraint reads more clearly in the DAO that cannot use the lever: [Beefy](/wiki/daos/lending/beefy)'s supply is fixed at 80,000 tokens with no mint function and nothing left undistributed, so its entire [$145,500-a-month](https://snapshot.box/#/s:beefydao.eth/proposal/0xb6ed8689ee9870bbb17b9c1ee4a8c722712e3c495146b84d96a546c051c48048) contributor budget is paid in stablecoins out of vault revenue. A DAO with no seigniorage has no soft option.

## The unsolved problems

Even well-run compensation systems wrestle with the same open tensions:

- **Valuation and fairness.** Without managers or market salaries, deciding what a contribution is worth is genuinely hard; peer-allocation and retroactive systems are attempts to distribute that judgment, but both can reward visibility over substance. [Protocol Guild](/wiki/daos/public-goods/protocol-guild) takes the other route and declines to judge at all, paying ~184 Ethereum core maintainers on a formula of tenure and full- or part-time status alone — objective and hard to game, at the cost of being unable to tell a decisive contributor from a merely present one. Its own ops team has since drafted an "impact weighting" alternative, which would reintroduce exactly the judgment the formula was built to avoid.
- **Churn and burnout.** Contributors can leave instantly with no notice period, and pseudonymous, part-time work makes retention harder than in a firm.
- **Legal and tax status.** With no employer, contributors are typically self-employed across many jurisdictions, and the DAO itself may lack a [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) to contract or withhold — an unresolved compliance gray zone.
- **Transparency vs. privacy.** On-chain pay is fully public by default, which aids accountability but exposes every contributor's income to the world.
- **Sustainability.** Compensation is usually the biggest drain on the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management); a DAO that over-commits to salaries in a bull market can run out of runway when its token falls.

## How Caper approaches this

Caper does not add a separate payroll layer — it pays contributors through the same governance path as any other treasury spend. A member submits a **payout proposal** naming a recipient, a currency, and an amount; if the caper [votes it through](/wiki/governance/voting), execution transfers exactly that currency and amount from the [caper's treasury](/wiki/foundations/what-is-a-caper) straight to the recipient's account. There is no privileged spending key and no off-chain invoice: every payment to a contributor is a proposal the whole caper approved and can see on-chain. Recurring pay is simply repeated payouts rather than a bespoke streaming primitive, which keeps the rule the same for a one-off bounty and an ongoing salary — the treasury only ever moves when a [proposal](/wiki/governance/proposals) says it should.

## DAO tokenomics

URL: https://caper.network/wiki/dao-governance/concepts/treasury/dao-tokenomics
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | How a governance token is designed, distributed, and valued |
| **Supply levers** | Fixed cap · emissions/inflation · [vesting](/wiki/economics/token-unlocks-and-vesting) · [buyback & burn](/wiki/economics/fee-switches-and-value-accrual) |
| **Distribution** | Airdrop · treasury reserve · contributors · investors · liquidity mining |
| **Core tension** | Economic rights (value) vs voting rights (control) — coupled or split? |
| **Vote-escrow** | Lock tokens for time-weighted power (veCRV) — aligns holders, spawns bribe markets |
| **On Caper** | Bonding-curve issuance, no emissions schedule; weight = stake × participation |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Voting & delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation), [Bonding curve](/wiki/markets/bonding-curve) |

**DAO tokenomics** is the design of a decentralized organization's native token: how many exist, how they enter circulation, who receives them, and what holding one entitles you to. In a DAO the token usually does double duty — it is both a claim on the organization's economic upside _and_ the instrument of control over it — so its design decides, at once, who profits and who governs. Get it wrong and the two goals collide: a token distributed to maximise a launch valuation can hand control to short-term speculators, while one distributed to align long-term stewards can starve the treasury of the capital it needs. a16z's [DAO canon](https://a16zcrypto.com/posts/article/dao-canon/) treats token design as the foundational choice every other governance decision inherits.

## Supply: how many tokens, and how they enter

The first lever is the **supply schedule** — the total number of tokens and the rate at which they reach circulation.

- **Fixed cap.** A hard maximum minted at genesis (Uniswap's 1B UNI). Predictable and scarce, but with nothing left to issue, later contributor rewards must come out of the treasury or from tokens already reserved.
- **Emissions / inflation.** New tokens minted continuously to reward participants — liquidity providers, stakers, contributors. Emissions bootstrap activity but dilute existing holders, and "mercenary" capital often farms the rewards and leaves, so many DAOs taper emissions over time. Where that taper lives decides whether it is governable at all: read at contract source, Curve's is a schedule no address can amend, Uniswap's is a capped permission its DAO has never used, and Compound's ended by running out ([emissions without a vote](/wiki/dao-governance/concepts/treasury/emissions-without-a-vote)).
- **Vesting.** Tokens granted to founders, early contributors, and investors are typically locked and released on a schedule (often a one-year cliff then multi-year linear vesting) so insiders cannot dump at launch and their incentives stay tied to the long term. A large vesting **unlock** is a scheduled supply shock the market watches closely – and, because vesting locks transfers but usually not votes, a governance event as well. See [token unlocks and vesting schedules](/wiki/economics/token-unlocks-and-vesting).
- **Buyback & burn.** Some DAOs use protocol revenue to buy tokens on the open market and burn them, returning value to holders by shrinking supply — a crypto analogue of a share buyback, and a way to route fees to holders without a taxable dividend.

## Distribution: who gets the tokens

Where the supply _goes_ at launch shapes governance more than any later vote. Common allocations:

- **Airdrops** to past users — the model [Uniswap](/wiki/daos/dexs/uniswap-dao) made famous with its 400-UNI drop — reward the people who actually used the protocol and decentralize ownership quickly, but airdropped tokens are also the easiest to sell.
- **Treasury reserve** — a large share held by the DAO itself, to be deployed by future governance for grants, incentives, and operations. This is the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) the organization later governs.
- **Core contributors and team** — vested allocations that pay the people building the protocol.
- **Investors** — early backers who funded development, usually on the longest vesting schedules and the sharpest source of "VC capture" criticism.
- **Liquidity mining / public sale** — tokens distributed for providing liquidity or bought directly, seeding a market price and a tradable float.

The recurring failure is **concentration**. However carefully a token is distributed, holdings tend to pool: studies of large DAOs repeatedly find voting power concentrated in well under 1% of addresses, so a token that is nominally "one token, one vote" is in practice governed by a handful of whales and delegates. Concentration is the root cause of most of the [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) catalogued elsewhere in this wiki, and the problem [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) inherits by construction.

## Separating economic rights from voting rights

Because a governance token bundles _value_ and _control_, its holders can face a conflict: the profit-maximising choice and the protocol-maximising choice are not always the same, and a holder with no lasting stake can vote for the former. Vitalik Buterin's [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) sharpens the point: a voter who _borrows_ tokens to vote has "zero net exposure" to the outcome — full control, no downside — which is the mechanical root of vote-buying and the [bribe markets](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) that grew up around governance. Much of modern tokenomics is an attempt to re-couple the two, so that whoever holds the votes also holds the risk.

**Vote-escrow (ve) models** are the best-known answer. Pioneered by [Curve's veCRV](https://curve.readthedocs.io/dao-vecrv.html), they require holders to _lock_ their tokens for a fixed term — up to four years — to receive voting power (and a boosted share of rewards), with power scaling by lock length and decaying as the lock runs down. Locking forcibly ties control to a multi-year commitment: you cannot vote and immediately sell. The design succeeded so well it triggered the **["Curve Wars,"](/wiki/daos/dexs/curve-dao)** in which protocols competed to accumulate veCRV to direct Curve's emissions — and spawned an open **bribe market** where locked voters are paid for their votes, re-introducing the very vote-buying it aimed to suppress. The lesson generalizes: no purely token-based scheme fully escapes the value-versus-control tension; it can only move where the leak appears.

## Valuing a governance token

What a governance token is _worth_ is genuinely contested, because much of what it confers — the right to vote — has no direct cash flow. Where a token also carries economic rights (a claim on fees, a buyback, or a treasury share), analysts value it on those flows; where it is "governance-only," its price rests on the expected future value of control, which is far harder to pin down and a live subject of academic work — see, e.g., [Designing a Token Economy: Incentives, Governance, and Tokenomics](https://arxiv.org/abs/2602.09608) (2026). This is the [token-valuation](/wiki/economics/token-valuation) problem in the economics section, and it is why the sharpest tokenomics designs try to give the token a concrete economic claim rather than leaving it a pure governance right.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) takes a deliberately different route to nearly every choice above. There is **no emissions schedule, no vesting cliffs, and no allocation table** to negotiate: a caper's tokens are issued by a [bonding curve](/wiki/markets/bonding-curve), minted on demand when someone buys and burned when someone sells, so "supply in circulation" is simply whatever the market has bought — not a figure set by a launch spreadsheet. The founder's allocation is not a pre-mined lump but accrues a small slice of every buy, tapering toward zero as the caper fills up, and a fixed fraction of that same slice is routed to the protocol-wide [$CAPER treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) — so early-buyer dilution is bounded and legible rather than hidden in a vesting schedule.

On the value-versus-control tension, a caper does not lean on locking. Instead of ve-style time-locks, [voting weight](/wiki/governance/voting) combines the _stake_ a member holds with the _participation_ they have actually shown — so influence accrues to members who show up, and a holder who merely passes tokens through earns little say. Crucially, that same earned weight sets each member's [claim on the treasury at exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) – and that claim is the weight itself, tokens held combined with votes cast, not a pro-rata slice of tokens alone: voice and exit are the same number, which re-couples control to genuine economic exposure without a bribe-prone lock market. The token's economic backing is concrete rather than speculative — it is redeemable against a real treasury — which sidesteps the "governance-only, hard-to-value" problem at its root. The exact mechanics live on the linked [markets](/wiki/markets/bonding-curve) and [governance](/wiki/governance/voting) pages; this article is the map of the wider landscape they sit in.

## References

- a16z crypto, [The DAO canon](https://a16zcrypto.com/posts/article/dao-canon/) and [Governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).
- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021) — borrowed-token "zero net exposure" and the value/control split.
- Curve, [Voting Escrow (veCRV)](https://curve.readthedocs.io/dao-vecrv.html) — the canonical vote-escrow / lockup model.
- OpenZeppelin, [ERC20Votes](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Votes) — checkpointed governance-token balances underpinning on-chain voting.
- Chainlink, [DAO governance and governance tokens](https://blog.chain.link/dao-governance/).
- [Designing a Token Economy: Incentives, Governance, and Tokenomics](https://arxiv.org/abs/2602.09608) (arXiv, 2026).

## DAO treasury management

URL: https://caper.network/wiki/dao-governance/concepts/treasury/dao-treasury-management
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | DAO treasury management |
| **What it is** | Stewarding the pooled on-chain assets a DAO collectively owns |
| **Core objectives** | Capital preservation → liquidity → income |
| **Common rule of thumb** | 12–18 months of runway in stablecoins |
| **Custody** | Multisig ([Safe](/wiki/dao-governance/tooling/treasury/safe)) or contract-controlled vault |
| **Deployed by** | Governance-approved proposals only |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Rage-quit & exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [Raising funds](/wiki/markets/raising-funds), [ENS DAO](/wiki/daos/infrastructure/ens-dao) |

A **DAO treasury** is the pool of on-chain assets a decentralized organization collectively owns, held by a smart contract rather than a company bank account and deployable only when a [governance vote](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) authorizes it. **Treasury management** is the practice of keeping that pool solvent, diversified, and productively deployed — arguably the single most consequential operational discipline a DAO has, because a treasury is what turns a voting community into an organization that can actually pay for things. Aggregated across the ecosystem, DAO treasuries hold billions of dollars; the discovery hub [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) tracked assets-under-management, spending, and participation across roughly 14,000 organizations until its public site went offline in mid-2026.

## The concentration problem

The defining risk of a DAO treasury is that most of it is usually a single, highly correlated asset: the DAO's own governance token. a16z crypto's [treasury management guide](https://a16zcrypto.com/posts/article/treasury-management-guide/) reports that roughly **85% of DAOs hold their entire treasury in one crypto asset**, typically their native token. That figure flatters a DAO in a bull market and traps it in a bear one: a treasury that is nominally worth hundreds of millions can only be spent by selling the very token whose price the sale depresses, so the assets are worth least exactly when the DAO most needs to spend them. The largest DAO treasuries make the risk concrete: [Mantle](/wiki/daos/networks/mantle) holds much of its multi-billion-dollar treasury in its own MNT token. The standard remedy is **diversification** — converting a portion of native-token holdings into stablecoins and blue-chip assets so that operating expenses are funded from assets uncorrelated with the DAO's own market.

How that conversion is executed is a decision in its own right. Selling a large native-token block on the open market moves the price against the seller, so DAOs generally reach instead for [OTC placements and market-maker loans](/wiki/dao-governance/concepts/treasury/otc-placements-and-market-maker-loans) — an off-market sale to named buyers, or tokens lent to a trading firm as quoting inventory. Both are voted in public, and both carry costs that the proposal format tends to hide.

## Objectives and runway

Mature treasury policies borrow the language of corporate treasury desks and rank objectives in order: **capital preservation** first, then **liquidity**, then **income**. The [a16z guide](https://a16zcrypto.com/posts/article/treasury-management-guide/) recommends keeping **at least 12 — ideally 18 — months of operating expenses** in accessible cash or stablecoins, sized against a realistic model of monthly burn — whose largest line is almost always [contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — under conservative revenue assumptions. Runway discipline is what separates DAOs that survive a multi-year downturn from those that ratify an ambitious budget at the top of a cycle and run out of spendable assets before delivering it. Some DAOs go further and pursue **[protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity)** — owning the market depth that backs their own token instead of renting it, a model [OlympusDAO](/wiki/daos/stablecoins/olympusdao) pioneered through bonding.

## Custody, execution, and transparency

Because no individual may unilaterally move the funds, a treasury is held either in an **m-of-n multisig** — most commonly a [Safe](/wiki/dao-governance/tooling/treasury/safe) — or directly in a governance contract that releases assets only on a passed vote. Spending follows the DAO's [governance process](/wiki/dao-governance/concepts/fundamentals/dao-governance-models): a proposal names the recipient and amount, the membership votes, and an approved transfer executes on-chain. Frameworks such as [Aragon](https://legacy-docs.aragon.org/products/aragon-client/explore-template-dao/what-are-apps/finance-app) bundle treasury permissions, voting, and payments together; analytics platforms such as [Dune](https://dune.com/) and [Boardroom](https://boardroom.io/) give members a public, real-time view of what the treasury holds and how it is being spent — the size, composition, and runway figures that feed a DAO's [overall health metrics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics). That radical transparency — every balance and every disbursement visible on-chain — is both a DAO treasury's greatest accountability advantage and a standing invitation to governance attackers. Large treasuries increasingly delegate day-to-day allocation to a non-custodial manager such as [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey), granted scoped permissions over a DAO-owned [Safe](/wiki/dao-governance/tooling/treasury/safe) via the [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles Modifier — it can deploy funds into pre-approved strategies but can never withdraw them to itself.

That arrangement is one instance of a broader pattern: authority the DAO grants once and does not re-vote, bounded by scope, magnitude, direction and a cooldown rather than by a ballot. [Standing authorizations and delegated mandates](/wiki/dao-governance/concepts/treasury/standing-authorizations) reads four production examples at contract source and sets out which bounds they share and which they omit.

## The treasury as an attack surface

A large, transparent, vote-controlled treasury is a prize, and several of the most-studied [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) target it directly: an adversary who can cheaply acquire or borrow a voting majority can pass a proposal that drains the treasury to themselves. This tension has pushed treasuries toward two safeguards. The first is **timelocks and vetoes** that delay execution long enough for the community to react. The second is **redemption rights** — a floor that lets members reclaim their pro-rata share rather than be captured. In June 2026 GnosisDAO passed **GIP-151** at ~215% of quorum, authorizing GNO holders to redeem tokens for a pro-rata slice of a treasury of roughly $228M (about $109M liquid) — the largest live test yet of [treasury redemption](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) as a governance backstop ([CryptoSlate](https://cryptoslate.com/a-223m-dao-vote-could-turn-governance-into-a-cash-out-button/), [Gnosis forum](https://forum.gnosis.io/)). By contrast, DAOs with the largest treasuries — [Arbitrum](/wiki/daos/networks/arbitrum-dao) and [Optimism](/wiki/daos/networks/optimism-collective) among them — lean on delegate structures and grant frameworks to deploy capital without exposing the whole balance to a single vote ([Arbitrum forum](https://forum.arbitrum.foundation/), [Optimism Collective](https://gov.optimism.io/)).

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) inverts the usual treasury story: instead of raising a lump sum and then worrying about custody and runway, its treasury is a protocol-controlled vault that fills continuously from activity. Every buy on the [bonding curve](/wiki/markets/bonding-curve) pays a small trade fee into the caper's own treasury, and [proposal and vote fees](/wiki/markets/raising-funds) accrue there too — there is no signer set to compromise and no multisig to socially engineer. Capital is deployed only through governance: a **PAYOUT** proposal transfers assets to a recipient, and an **INVEST** proposal buys into another caper's curve and books the resulting tokens back into the treasury, so a caper can diversify into other capers by vote. And the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is built in rather than bolted on: any holder can redeem for a pro-rata share of the treasury, weighted by their canonical vote weight, so majority-capture of the treasury is bounded by every other member's standing option to walk away with their share. (Verified against the Caper contract, not aspirational.)

## Emissions without a vote: who sets a token's monetary policy

URL: https://caper.network/wiki/dao-governance/concepts/treasury/emissions-without-a-vote
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | Where a DAO token's issuance rate is actually decided, and how often that is anywhere a vote can reach |
| **Core question** | If the supply of a governed token changes this year, which passed proposal changed it? For the three tokens read below, the answer is none. |
| **Three shapes** | A schedule the DAO cannot amend (Curve) · a capped permission the DAO has never used (Uniswap) · a hardcoded drip that ended by running out (Compound) |
| **What the vote does reach** | Allocation, not amount: Curve's gauge weights, Compound's per-market COMP speeds |
| **Measured** | Ethereum mainnet, 12 August 2026, blocks 25,740,317–25,740,331, by direct `eth_call`; every figure below is reproducible with the four calls in the method section |
| **Read at source** | [Curve ERC20CRV.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/ERC20CRV.vy) · [Curve GaugeController.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/GaugeController.vy) · [Uniswap Uni.sol](https://github.com/Uniswap/governance/blob/master/contracts/Uni.sol) · [Compound Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) · [Compound Reservoir.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Reservoir.sol) |
| **Related** | [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) · [Standing authorizations](/wiki/dao-governance/concepts/treasury/standing-authorizations) · [Vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) · [Protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) |

A DAO's most consequential recurring decision is how many new tokens exist next year. It dilutes every holder, funds every incentive programme, and sets the floor under the token's price. It is also, in the three largest cases this page reads at source, **not a decision the DAO takes**. The issuance number was fixed once, by whoever wrote the token contract, and the ballot box never gets near it.

This is not the same observation as [standing authorizations](/wiki/dao-governance/concepts/treasury/standing-authorizations), where a DAO votes once to delegate a class of future actions inside bounds it chose. Here there was no delegating vote at all: the schedule predates the governance system, and in one of the three cases no address on Earth can change it. The distinction matters because governance dashboards count proposals, and a monetary policy that produces no proposals looks, from the dashboard, like a monetary policy nobody is arguing about.

## Shape one: a schedule the DAO cannot amend

[Curve](/wiki/daos/dexs/curve-dao)'s CRV is issued by an inflation schedule written into the token contract itself. [ERC20CRV.vy](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/ERC20CRV.vy) declares `RATE_REDUCTION_TIME` as one year and `RATE_REDUCTION_COEFFICIENT` as `1189207115002721024`, which is 21/4 scaled by 1018. At each annual boundary the emission rate is divided by that coefficient, cutting issuance by 15.91% a year, forever.

Read live on 12 August 2026, the contract answers `mining_epoch() = 5`, `rate() = 3663926723928765860` (3.6639 CRV per second, or 115,545,593 CRV a year) and `start_epoch_time() = 1755037048`, which is 22:17:28 UTC on 12 August 2025. Add the reduction interval and epoch six begins at 22:17:28 UTC on **12 August 2026** – the same day this page was written – dropping the rate to 3.0810 CRV per second, or 97,161,875 CRV a year. Against a `totalSupply()` of 2,409,286,293 CRV, this year's issuance is 4.80% of the float.

No proposal precedes that cut, and none could stop it. The only function that writes `self.rate` is `_update_mining_parameters`, and the only way in is the external `update_mining_parameters()`, whose entire access control is one line: `assert block.timestamp >= self.start_epoch_time + RATE_REDUCTION_TIME`. Its own docstring says it plainly – "callable by any address, but only once per epoch". The token's `admin` may set the minter once, hand over adminship and change the token's name; it has no power over the rate at all. A DAO that wanted a different CRV emission curve would have to issue a different token.

Two details reward reading the source rather than the marketing. First, the schedule is _permissionless to advance but not automatic_: someone has to send the transaction, and the contract warns that "total supply becomes slightly larger if this function is called late". Second, `available_supply()` returns 2,419,552,174 CRV against a minted `totalSupply()` of 2,409,286,293 – a gap of **10,265,881 CRV** that the schedule has already released and no gauge has yet claimed. The schedule runs whether or not anyone collects.

## Shape two: a permission the DAO has never used

[Uniswap](/wiki/daos/dexs/uniswap-dao)'s UNI is the opposite construction: the mint power exists, it belongs to governance, and it has never been exercised. [Uni.sol](https://github.com/Uniswap/governance/blob/master/contracts/Uni.sol) caps a mint at `mintCap = 2` percent of supply, spaces mints by `minimumTimeBetweenMints = 1 days * 365`, and gates them behind `mintingAllowedAfter`. The `mint` function requires the caller to be `minter`, which reads on-chain as `0x1a9c8182c09f50c8318d769245bea52c32be35bc` – a timelock with a 48-hour `delay()` whose own admin is the Uniswap governor. The permission is genuinely the DAO's.

Two on-chain values show it has never been used. `mintingAllowedAfter()` returns `1704067200`: exactly midnight UTC on 1 January 2024. Line 116 of the contract rewrites that field to `block.timestamp + minimumTimeBetweenMints` on every successful mint, so a round constructor-set midnight surviving in that slot is proof no mint has landed. And `totalSupply()` returns exactly `1000000000000000000000000000` – one billion UNI to the wei, the genesis number unchanged.

So for two years and seven months the Uniswap DAO has held a standing, capped, self-executing authority to issue up to 2% of UNI a year, and has not once put it to a vote. The absence is the finding: an unused power still sets an expectation, and every holder's dilution risk is a proposal away from becoming real.

## Shape three: a drip that ended by running out

[Compound](/wiki/daos/lending/compound-dao)'s COMP cannot be minted at all. [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) declares `uint public constant totalSupply = 10000000e18` – a compile-time constant, with no mint function anywhere in the contract. Ten million COMP is all there will ever be, and no vote changes that.

Distribution was handled instead by a [Reservoir](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Reservoir.sol): a contract holding COMP and releasing it to the Comptroller at `dripRate` tokens per block. Read live, the reservoir at `0x2775b1c75658Be0F640272CCb8c72ac986009e38` answers `dripRate() = 500000000000000000` – half a COMP per block – with `token()` pointing at COMP and `target()` at the Comptroller, and `dripStart()` at block 10,229,427. All three are set in the constructor and the contract exposes no setter for any of them; its only state-changing function is `drip()`, which anyone may call and which "will only drip up to the amount of tokens available".

That reservoir's COMP balance today is **zero**. The distribution that defined Compound's liquidity mining did not end with a proposal to end it. It ended because a number chosen in June 2020 finished paying out a fixed pot, on a schedule that no COMP holder ever voted on and none could have amended. Whatever COMP flows now has to be moved by a governance transaction, one grant at a time – the Comptroller itself holds 0.00013 COMP.

## What the vote actually reaches

In all three cases governance is busy, and in all three it is busy downstream of the number that matters. Curve's [GaugeController](https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/GaugeController.vy) lets veCRV holders call `vote_for_gauge_weights`, subject to a `WEIGHT_VOTE_DELAY` of ten days per gauge, with weights stepping on week boundaries – a continuous, high-stakes, heavily-lobbied election over the _split_ of an emission whose _size_ is not on any ballot. That gap is the whole reason the [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow) market exists: when you cannot change how much is printed, the only thing left to buy is where it goes.

Compound is the same division drawn differently. `_setCompSpeeds` in the [Comptroller](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Comptroller.sol) is gated by `require(adminOrInitializing(), "only admin can set comp speed")`, so the DAO sets the per-market supply and borrow speeds – the allocation – while the total it was allocating from came out of an immutable drip.

The practical test for any DAO is therefore not "does governance control the token?" but three narrower questions. Can any address change the issuance rate? If yes, whose, and under what cap and cooldown? And when the schedule ends or the pot empties, does anything at all announce it? A DAO that cannot answer the third question will discover its incentive programme has stopped the way Compound's did: from an empty balance, not from a vote.

## Check any token yourself

None of this needs an indexer, an API key, or a governance dashboard. Every figure on this page came from `eth_call` against a public RPC endpoint, and the method generalises to any ERC-20 a DAO claims to govern.

1. **Is the supply fixed?** Call `totalSupply()` (`0x18160ddd`) and compare it to the genesis number in the project's own launch post. Exact equality to a round number is strong evidence nothing has ever been minted.
2. **Who may mint?** Read the verified source for a mint function and find its access control. Then resolve the address it names – a timelock or governor means the DAO holds the power; a schedule inside the token means nobody does.
3. **What are the bounds?** Look for a cap and a cooldown (Uniswap's `mintCap` and `minimumTimeBetweenMints`), or a rate and a reduction interval (Curve's `rate` and `RATE_REDUCTION_TIME`). A permission with no cap and no cooldown is not monetary policy, it is a key.
4. **Is it still running?** Check the balance of whatever contract is supposed to be paying – the reservoir, the vesting escrow, the distributor. A distribution contract with a zero balance has stopped, whatever the documentation still says.

The fourth check is the one every governance dashboard misses, because a distribution that ends by exhaustion generates no proposal, no event a governance indexer watches, and no announcement.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no monetary policy to vote on, because it has no issuance schedule. The full supply of a caper's governance token – 100 billion units, the `CURVE_CAP` constant every caper shares – is minted once when the caper is created, into an inventory vault, with no mint role and no burn role attached to the resource. Nothing in the contract can enlarge or shrink it later, and there is no proposal type that tries.

What moves is the split between the vault and holders, along the [bonding curve](/wiki/markets/bonding-curve): buying takes tokens out of inventory at a price the curve sets, selling puts them back. So the question this page asks of Curve, Uniswap and Compound – "which passed proposal changed the supply?" – has no analogue here. A caper's [votes](/wiki/governance/voting) are about what the treasury does, never about how many tokens exist.

That is a narrower design, not a better one in every respect: a fixed supply cannot fund an incentive programme by printing, so a caper that wants to pay for something has to pay out of its treasury and show the payment. The trade is deliberate. Dilution is the one governance risk a holder cannot audit after the fact, and the simplest way to make it auditable is to make it impossible.

## Hypercerts (impact certificates)

URL: https://caper.network/wiki/dao-governance/concepts/treasury/hypercerts
Updated: 2026-08-05

|  |  |
| --- | --- |
| **Topic** | Hypercerts (impact certificates) |
| **What it is** | An open token standard for _impact claims_ – a semi-fungible certificate that records who did a piece of work, over what period and scope, so it can be funded (especially [retroactively](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding)) across any mechanism |
| **Token standard** | [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155) semi-fungible token; claim metadata pinned on [IPFS](https://ipfs.tech/) |
| **Origin** | Proposed by David Dalrymple at [Funding the Commons](https://fundingthecommons.io/) (June 2022); framework published by [Protocol Labs](https://pl.xyz/blog/hypercert-new-primitive/) (Aug 2022, author Holke Brammer) |
| **Stewarded by** | [Hypercerts Foundation](https://hypercerts.org/) ([open source](https://github.com/hypercerts-org)) |
| **Used by** | [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), [Celo Public Goods](https://forum.celo.org/t/celopg-h1-progress-report/8126), GreenPill, and other public-goods and [DeSci](/wiki/desci/desci-funding) funders |

## Overview

A **hypercert** is an open, on-chain _certificate of impact_: a token that states that a specific piece of work was done, by whom, over what time period, and toward what goal. It is not itself a funding mechanism – it is the shared _accounting layer_ that funding mechanisms point at. The name is a contraction of "hyperstructure certificate," and the pitch is that public-goods work should have a durable, transferable record the same way a company's output has equity.

The primitive was introduced by David Dalrymple at the [Funding the Commons](https://fundingthecommons.io/) conference in June 2022 and written up by [Protocol Labs](https://pl.xyz/blog/hypercert-new-primitive/) in August 2022. It sits directly upstream of the [retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) experiments run by [Optimism](/wiki/daos/networks/optimism-collective) and [Gitcoin](/wiki/daos/public-goods/gitcoin-dao): those programmes need a canonical object to reward, and a hypercert is designed to be that object.

## How a hypercert works

Each hypercert is an [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155) semi-fungible token whose claim data lives as metadata on [IPFS](https://ipfs.tech/). The claim is structured along a fixed set of dimensions, so two hypercerts can be compared, merged, or split without ambiguity. Per the [Protocol Labs specification](https://pl.xyz/blog/hypercert-new-primitive/), a claim records:

- **Scope of work** – what was actually done.
- **Time of work** – the period over which the work happened.
- **Contributors** – the accounts credited for it.
- **Scope of impact** and **time of impact** – what the work is claimed to have affected, and when.
- **Rights** – what a holder of the certificate is actually entitled to (e.g. the right to claim credit for retroactive funding).

Because the token is semi-fungible, a single claim can be **fractionalized** and its fractions sold to, or held by, many funders – and hypercerts can be **split and merged** along those dimensions, so multiple backers can support distinct slices of one project's impact. The design is deliberately mechanism-agnostic: hypercerts are meant to feed "private sales, public auctions, expert panels, and quadratic voting systems" alike, avoiding a new silo for every funding round.

## The retroactive-funding thesis

Hypercerts exist to make one idea practical: **it is easier to agree on what was useful than to predict what will be.** Retroactive funding pays for outcomes after they land rather than proposals before they start – the same "results, not promises" logic Vitalik Buterin and others set out in the [original retroactive public goods funding essay](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c). The catch is a coordination gap: a builder who works now on the expectation of being paid later needs a credible, non-duplicable record that _they_ did the work. As the Protocol Labs write-up puts it, "if you can reasonably expect to get funded retroactively for your work once you produce a positive impact, then you can work now, in expectation of a probabilistic future cash flow."

A hypercert is that record. It turns a diffuse "we did some good" into an ownable, auditable claim that a later [retro round](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) – or a market, or a panel – can price. It also gives the record _persistence_: once minted, an impact claim is not forgotten when the round that might have funded it moves on.

## Where it is used

The clearest adopters are the public-goods funders whose whole model depends on rewarding realized impact:

- **[Gitcoin](/wiki/daos/public-goods/gitcoin-dao).** Gitcoin ran a [GreenPill hypercerts experiment](https://gitcoin.co/case-studies/greenpill-hypercerts-experiment-impact-certificates-in-practice) to fund chapter activity, and its [Grants 24](https://gitcoin.co/campaigns/gitcoin-grants-24-gg24) round (donations Oct 14–28, 2025) offered "peer-reviewed hypercerts" as one of the round-specific mechanisms allocators could choose, alongside [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) and conviction voting.
- **[Celo Public Goods](https://forum.celo.org/t/celopg-h1-progress-report/8126).** Celo's public-goods programme uses hypercerts to represent claimed impact in its retroactive rounds, built on the same EasyRetroPGF tooling lineage.
- **[DeSci funders](/wiki/desci/desci-funding).** The impact-certificate model is a natural fit for research, where a paper, dataset, or replication is a discrete unit of impact that funders may want to reward after the fact rather than via a grant proposal.

The protocol itself is stewarded by the [Hypercerts Foundation](https://hypercerts.org/) and developed in the open at [github.com/hypercerts-org](https://github.com/hypercerts-org).

## Limits and open questions

A certificate standardizes the _claim_; it does not settle the hardest part, which is **measuring impact and deciding who judges it**. A hypercert can faithfully record that work happened without establishing that the work mattered, and the valuation step still falls to a market or an evaluator – exactly the load that overwhelmed human reviewers in [Optimism](/wiki/daos/networks/optimism-collective)'s [RetroPGF](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) rounds. Fractionalization also invites speculation: if fractions trade freely, the price of a hypercert can drift toward what buyers expect it to be worth to future funders rather than its underlying impact, reintroducing the guess-the-future problem retro funding set out to avoid. Adoption, too, remains concentrated in the crypto public-goods niche rather than broad philanthropy. None of this is fatal – a shared, persistent record is genuinely useful – but a hypercert is best read as _plumbing for_ impact funding, not a verdict on impact.

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) is a DAO protocol, not a grants programme, and it does not issue impact certificates or run retro rounds. But it shares the load-bearing instinct behind hypercerts: **what you actually did, not what you promised or what you hold, should decide your claim.**

In a caper, voting mints a non-transferable [proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens) – an indivisible resource you cannot buy, sell, or be airdropped; it accrues only by having voted. Governance weight is then computed on-chain as **(tokens held × your votes) / (vote supply × tokens in circulation)**, and the _same_ figure sets your share of the treasury when you [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Your participation record and your claim on the money are one number. Where a hypercert is a transferable, tradeable certificate of impact, Caper's is the opposite: an earned, soulbound record that cannot change hands. Both refuse to let a promise or a purchase stand in for a contribution – they just draw the line in different places, and Caper draws it so that the earned half of the product cannot be bought at any price. (Holdings are still a multiplicative factor, so capital counts; a large bag alone simply cannot capture control.)

## References

- [Protocol Labs – "Hypercerts: A new primitive for public goods funding" (Aug 2022)](https://pl.xyz/blog/hypercert-new-primitive/)
- [Hypercerts Foundation](https://hypercerts.org/) · [hypercerts-org on GitHub](https://github.com/hypercerts-org)
- [Optimism – "Retroactive Public Goods Funding"](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)
- [Gitcoin – GreenPill hypercerts experiment case study](https://gitcoin.co/case-studies/greenpill-hypercerts-experiment-impact-certificates-in-practice)
- [Celo Public Goods – Hypercerts](https://forum.celo.org/t/celopg-h1-progress-report/8126)

## OTC placements and market-maker loans

URL: https://caper.network/wiki/dao-governance/concepts/treasury/otc-placements-and-market-maker-loans
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Concept** | Selling or lending treasury tokens off-market instead of on an exchange |
| **Two instruments** | OTC placement (an outright sale to named buyers); market-maker loan (tokens lent for inventory, usually with an embedded call) |
| **What the DAO gets** | Cash runway, exchange listings, quoted liquidity, strategic holders |
| **What the DAO gives up** | Supply at a price it fixed in advance, and — in the loan case — an option it usually writes for free |
| **Canonical loan deal** | [Index Coop IIP-83](https://gov.indexcoop.com/t/iip-83-wintermute-market-making-proposal/2575) (Sept 2021): 100,000 INDEX (1% of supply) lent to Wintermute for one year |
| **Canonical placement** | [Lido Treasury Diversification #2](https://research.lido.fi/t/treasury-diversification-2/2570) (July 2022): 20M LDO for $29,043,051.43 DAI |
| **Counterintuitive fact** | Lido sold at a _50% premium_ to a 7-day TWAP, not the usual discount — and the tokens carried full voting power immediately |
| **Related** | [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [Protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) · [Token unlocks and vesting](/wiki/economics/token-unlocks-and-vesting) |

## The problem: a treasury full of its own token

Most DAOs are rich on paper and poor in practice. The [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) holds a large block of the DAO's own governance token and very little of anything a contributor can be paid in. Selling that block on the open market is the obvious fix and the worst one: the float is thin, the sale is visible, and the price the DAO realises falls as it sells. So DAOs reach for two instruments that move supply without touching the order book.

An **OTC placement** is an outright sale of treasury tokens to named counterparties at a negotiated price, settled bilaterally. A **market-maker loan** lends tokens to a trading firm so it has inventory to quote with, and is repaid in tokens or in cash at the firm's choice — which makes the loan a call option the DAO has written. Both are governed by a public vote, which is why the terms of deals that would be confidential anywhere else are readable in full on DAO forums.

Neither instrument has a home in the DAO's own accounting vocabulary. A placement looks like revenue in the quarter it closes and like dilution for years afterwards; a loan looks like an asset that has left the building. Both are [tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) decisions dressed as operations.

## The market-maker loan, and the option hidden inside it

The structure is standard enough that Lido's own request for proposals listed it as the expected shape: when Lido asked market makers to bid in February 2022, it told them to state ["all relevant parameters. (Possibly: treasury loan, embedded call options, length.)"](https://research.lido.fi/t/request-for-proposals-market-making/1737) That RFP followed a [four-option sentiment check](https://research.lido.fi/t/market-makers-and-cex-listings/1641) that closed with 57% of votes for opening a public call rather than negotiating privately — the DAO deciding, first, that the terms should be argued in the open.

The clearest public example predates it. In September 2021 Index Coop passed [IIP-83](https://gov.indexcoop.com/t/iip-83-wintermute-market-making-proposal/2575), lending **100,000 INDEX — 1% of supply — to Wintermute Trading for one year**. Repayment, [per the published terms](https://gov.indexcoop.com/t/updated-proposal-market-making-proposal-from-wintermute-trading/2502), was Wintermute's choice of three:

- the full 100,000 INDEX back; or
- $5 million in stablecoins or ETH, if an Index product or INDEX itself reached a Tier-1 centralised exchange with Wintermute's help; or
- $7.5 million otherwise.

Read it as an option and the economics are plain. Wintermute returns cash whenever the tokens are worth more than the cash, and returns tokens whenever they are worth less. The DAO has sold a one-year call on 1% of its supply, struck at an effective $50 or $75 per INDEX. A forum member did that arithmetic during the vote and objected that the DAO was ["selling a circa $1.5m option for zero value"](https://gov.indexcoop.com/t/iip-83-wintermute-market-making-proposal/2575); another walked through the payoff explicitly — if INDEX traded at $250 a year later with no listing, Wintermute would repay $7.5 million and keep $25 million of tokens — and called it a ["heads I win, tails Index loses"](https://gov.indexcoop.com/t/iip-83-wintermute-market-making-proposal/2575) structure. The proposal [passed on Snapshot with 127,634 votes for and 19,281 against](https://snapshot.org/#/index-coop.eth/proposal/QmZJzVGRgsu4AZVWyr4zqeuQLYfbjmq3n7dGGJmrNNKp7b), roughly 87% in favour.

The premium was never separately priced, and that is the general defect rather than a quirk of one deal: the loan is negotiated as a service contract, so the option rides along inside it and no line item ever names it. The counterparty side is candid about the components when asked. A market maker proposing to quote stSOL on Solana told the Lido forum that ["normally, MMs would ask for a fee as well as the 'inventory' (assets) to quote the token, but I only wanted the inventory"](https://research.lido.fi/t/lido-on-solana-liquidity-on-openbook-and-jupiter-spacemonkey-mm/3397) — fee and inventory as two separable asks, one of which most DAOs never see itemised.

Index Coop's relationship with Wintermute ran to term and was not renewed on the same footing. In December 2022 the DAO [reopened the search](https://gov.indexcoop.com/t/index-coop-invites-market-makers-to-partnership-talks/4455), noting it was "past our agreement term end dates" and wanted a fresh look now that larger institutional partners were in play — the ordinary end of a [service-provider relationship](/wiki/dao-governance/concepts/analysis/dao-service-providers), renewed by expiry rather than by review.

## The OTC placement, and Lido's premium

A placement is simpler: the DAO sells a block of treasury tokens to buyers it names, at a price it fixes, for stablecoins it can spend. The received wisdom is that such blocks trade at a discount, because the buyer is absorbing size and accepting a lockup. Lido's largest placement did the opposite.

In July 2022, in the depths of the bear market, [Treasury Diversification #2](https://research.lido.fi/t/treasury-diversification-2/2570) proposed selling **20 million LDO — 2% of supply — at a 7-day TWAP plus a 50% premium**, a price of $1.452153 per LDO, for **$29,043,051.43 in DAI**. Dragonfly Liquid took 10 million and other strategic participants the remaining 10 million. The DAO's stated goal was two years of operating runway in stablecoins, and the premium was justified as giving new partners "skin in the game" while blunting the incentive to flip.

The term that matters most is not the price. It is this one: **"Acquired tokens will be unlocked. Full voting power will be granted immediately upon closing of the sale."** The buyers paid above market for a block that carried governance rights from day one, with nothing vested and nothing cliffed. That is the exact inverse of the norm the same ecosystem applies to its own contributors, where [multi-year vesting with a one-year cliff](/wiki/economics/token-unlocks-and-vesting) is treated as the minimum evidence of alignment. Control was delivered instantly; only the founders' and contributors' claims are made to wait.

The premium is legible once you see what was actually sold. A discount compensates a buyer for illiquidity and price risk. A premium is what a buyer pays when the thing acquired is not just exposure but a governed position in a protocol whose direction they intend to influence — a price for the vote, not for the token. The 105-post thread that followed argued the point at length, and the deal closed.

## How to read a deal before voting on it

Both instruments are legitimate. What makes them dangerous is that their cost is structurally invisible in the format DAOs vote in. Four questions extract it:

- **What is the option worth?** A loan repayable in tokens _or_ cash at the borrower's election is a written call. Price it — strike, size, tenor, implied volatility — and put the number in the proposal. If nobody in the DAO can price it, the DAO is not equipped to sell it.
- **What is the effective strike relative to spot?** IIP-83's $50 and $75 were far above INDEX's price at the time, which is what made the structure defensible to most voters. A near-the-money strike on 1% of supply is a very different trade wearing the same clothes.
- **Does the block vote, and from when?** Tokens sold unlocked with immediate voting power change the [electorate](/wiki/dao-governance/concepts/voting/token-weighted-voting), not just the balance sheet. A 2% placement to a handful of aligned funds is a governance event.
- **What happens at term?** Both Index Coop deals show the same failure mode as [service-provider contracts](/wiki/dao-governance/concepts/analysis/dao-service-providers) generally: they end by expiry, not by an evaluation against the KPIs the original proposal listed. Write the review into the deal or it will not happen.

The instruments also age. Lido's treasury, having sold 2% of supply for runway in 2022, was by August 2025 debating the opposite trade — a [dynamic buyback programme](https://research.lido.fi/t/dynamic-buyback-program-for-ldo/10494) directing 70% of incoming liquid tokens to LDO buybacks against a $145M liquid balance, with thresholds pausing buybacks below $50M. A treasury that placed tokens at a premium in a bear market and bought them back from a surplus three years later has, on net, run a discretionary trading book. That is a real strategy; it is rarely the one the DAO voted for.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does not have the problem these instruments solve, because it never accumulates a block of its own token that it then has to place. Buying in happens on the caper's [bonding curve](/wiki/markets/bonding-curve): tokens are minted along the curve as capital arrives, and the same closed-form curve prices the sell leg, so there is a standing bid and ask without a counterparty being hired to provide one. The contract's `compute_xrd_received` integrates the curve between two supply points to price a sale, and the configured trade fee — 0.5% at instantiation, and rewritable by `update_fees` like the other three fees — is what the protocol charges for the round trip. There is no inventory to lend because the curve _is_ the inventory.

The exit right closes the other half. Any member can call `exit` at any time, and the share of the treasury they receive is their canonical vote weight `(t·v)/(V·T)` — the same `compute_vote_weight` the protocol uses for voting, computed pre-burn from the governance tokens and the soulbound vote tokens together, both of which the call asserts are non-empty and consumes. So a member does not need a market maker to get out, and a large holder cannot enlarge their claim by buying tokens alone. (Verified against `contracts/logic/src/lib.rs`.)

What a caper gives up is real and worth stating. There is no mechanism to sell a strategic block to a named partner, no way to bring an institution onto the cap table on negotiated terms, and no lever to buy listings or deepen a centralised-exchange book — the things Index Coop and Lido were actually buying. A caper trades the ability to do those deals for never having to price an option it does not know how to price.

## References

- [Index Coop — IIP-83: Wintermute Market Making Proposal (6 Sept 2021)](https://gov.indexcoop.com/t/iip-83-wintermute-market-making-proposal/2575), and the [updated proposal thread with full terms](https://gov.indexcoop.com/t/updated-proposal-market-making-proposal-from-wintermute-trading/2502).
- [Snapshot — IIP-83 vote result (index-coop.eth)](https://snapshot.org/#/index-coop.eth/proposal/QmZJzVGRgsu4AZVWyr4zqeuQLYfbjmq3n7dGGJmrNNKp7b): 127,633.67 FOR / 19,281.50 AGAINST.
- [Index Coop — Index Coop Invites Market Makers To Partnership Talks (5 Dec 2022)](https://gov.indexcoop.com/t/index-coop-invites-market-makers-to-partnership-talks/4455).
- [Lido Research — Market makers and CEX Listings (2 Feb 2022)](https://research.lido.fi/t/market-makers-and-cex-listings/1641), the four-option sentiment check.
- [Lido Research — Request for Proposals: Market Making (23 Feb 2022)](https://research.lido.fi/t/request-for-proposals-market-making/1737).
- [Lido Research — Treasury Diversification #2 (18 July 2022)](https://research.lido.fi/t/treasury-diversification-2/2570), 105 posts.
- [Lido Research — Lido on Solana: liquidity on Openbook and Jupiter (13 Dec 2022)](https://research.lido.fi/t/lido-on-solana-liquidity-on-openbook-and-jupiter-spacemonkey-mm/3397), a market maker stating its own terms.
- [Lido Research — Dynamic Buyback Program for LDO (7 Aug 2025)](https://research.lido.fi/t/dynamic-buyback-program-for-ldo/10494).

## Protocol-owned liquidity (POL)

URL: https://caper.network/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity
Updated: 2026-07-27

| Concept | Protocol-owned liquidity (POL) |
| --- | --- |
| Also called | Protocol-controlled value (PCV), owned liquidity, permanent liquidity |
| Category | Treasury & tokenomics |
| Core idea | A DAO's treasury _owns_ the liquidity for its own token instead of renting it from mercenary liquidity providers with emissions |
| Solves | The mercenary-capital problem of [liquidity mining](/wiki/economics/liquidity-mining) — liquidity that leaves the moment rewards dry up |
| Pioneered by | [OlympusDAO](/wiki/daos/stablecoins/olympusdao) (bonding) and [Fei Protocol](https://medium.com/fei-protocol/new-approaches-to-liquidity-in-defi-624f2e50937b) (PCV), c. 2021 — the "DeFi 2.0" wave |
| Central trade-off | Permanence and fee income vs. treasury capital tied up in a volatile LP position |

**Protocol-owned liquidity** (POL) is a treasury strategy in which a DAO uses its own capital to provide the liquidity for its token, rather than paying outside liquidity providers to do it. The treasury holds the [AMM](https://en.wikipedia.org/wiki/Automated_market_maker) position itself, so the depth that lets people trade the token belongs to the protocol and cannot be withdrawn by anyone else. It is the treasury-side answer to a structural weakness that dominated early [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics): liquidity that was only ever rented, and left as soon as the rent stopped.

## The problem it solves: rented liquidity

The default way to bootstrap a token market in the 2020–2021 cycle was **liquidity mining**: a protocol emits its own governance token to reward anyone who deposits into its trading pools ([Consensys: an alternative to liquidity mining](https://consensys.io/blog/defi-2-0-an-alternative-solution-to-liquidity-mining)). This buys deep liquidity quickly, but the capital it attracts is **mercenary** — it chases the highest yield and rotates out the instant a better farm appears or emissions taper. The protocol ends up permanently diluting its holders to rent liquidity it never owns, and a token whose depth depends on emissions is one incentive-cut away from a thin, gappy market.

The critique that named the problem came from the [Fei Protocol](https://medium.com/fei-protocol/new-approaches-to-liquidity-in-defi-624f2e50937b) team, who proposed _protocol-controlled value_ (PCV): if the protocol holds the reserves and LP positions itself, it stops paying rent and starts earning the trading fees instead. Owning the liquidity converts a recurring emissions expense into a durable treasury asset.

## How DAOs acquire it

Several mechanisms all arrive at the same end — the treasury on the other side of the token's market:

- **Bonding.** [OlympusDAO](/wiki/daos/stablecoins/olympusdao) pioneered POL by selling its token (OHM) at a discount in exchange for LP tokens or reserve assets, which the treasury then keeps permanently ([Olympus docs: POL](https://docs.olympusdao.finance/main/overview/pol/)). The pitch was explicit: own liquidity so that "users and protocols are always able to swap OHM, regardless of market conditions."
- **Algorithmic market operations (AMOs).** [Frax](/wiki/daos/stablecoins/frax-finance) runs autonomous contracts that deploy idle reserves into [Curve](/wiki/daos/dexs/curve-dao) and Uniswap pools to build POL, constrained so they cannot push the stablecoin off peg ([Frax docs: AMO overview](https://docs.frax.finance/amo/overview)).
- **Liquidity-as-a-service.** [Tokemak](https://docs.tokemak.xyz/) lets protocols direct pooled reserves toward their own token pairs, effectively renting depth from a shared reserve instead of bribing individual LPs.
- **Vote-directed emissions.** Under [vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow), a DAO can lock a governance token to steer emissions toward its own pool — and the [vote markets](/wiki/dao-governance/concepts/voting/vote-markets) that grew around [Convex](/wiki/daos/lending/convex-finance) let a treasury _rent_ that direction cheaply. This is renting, not owning, but many treasuries treat a locked veToken stack as a POL-adjacent asset.

## What owning liquidity buys a treasury

- **Permanence.** Owned liquidity does not flee. The market for the token survives an incentive cut, a drawdown, or a rival farm — the property Olympus calls "permanent liquidity" ([Olympus docs](https://docs.olympusdao.finance/main/overview/pol/)).
- **Fee income instead of rent.** The treasury earns the swap fees its own position generates, turning a cost centre into a revenue line ([Fei: new approaches to liquidity](https://medium.com/fei-protocol/new-approaches-to-liquidity-in-defi-624f2e50937b)).
- **Less dilution.** Every token not emitted to a mercenary LP is a token not diluting existing holders — a direct improvement to the emission schedule discussed under [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics).
- **A measurable backing.** Because the reserves sit in the treasury, holders can point to on-chain assets standing behind the token, which feeds the transparency and runway goals of [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## Criticisms and risks

POL is not free, and its most famous exponent became its cautionary tale:

- **The reflexive-growth trap.** Olympus paired POL with very high staking emissions ("(3,3)"), and when the reflexive buy-and-stake loop reversed, OHM fell more than 90% from its peak — drawing sustained "Ponzi" scrutiny ([CoinDesk, Dec 2021](https://www.coindesk.com/policy/2021/12/05/olympus-dao-might-be-the-future-of-money-or-it-might-be-a-ponzi)). POL is a treasury technique; it does not rescue an unsustainable emission schedule bolted on top of it.
- **Capital inefficiency.** Liquidity the protocol owns is capital it cannot spend on grants, contributors, or runway. A treasury that over-allocates to its own LP is thin exactly when it needs to act.
- **Impermanent loss and price exposure.** An owned LP position carries [impermanent loss](https://en.wikipedia.org/wiki/Automated_market_maker) and marks to the token's own volatility, so a falling token shrinks the very backing that was meant to reassure holders — a concentration risk covered under [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).
- **Renting in disguise.** POL built by renting vote-directed emissions inherits the short-termism of the [vote market](/wiki/dao-governance/concepts/voting/vote-markets): it is only "owned" for as long as the locks and bribes keep flowing.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does not need a separate POL programme, because the liquidity is native to the [bonding curve](/wiki/markets/bonding-curve) itself. Every buy sends XRD into the caper's own reserve, and that reserve is what honours a sale — the curve is its own market maker, and the depth backing it belongs to the caper, not to an outside LP that can leave (verified against the reserve accounting in `contracts/logic/src/lib.rs`).

- **No emissions to rent liquidity.** There is no liquidity-mining programme and no mercenary capital to lose: the reserve accrues automatically from trading, so a caper never dilutes holders to buy depth it doesn't own.
- **The reserve collateralises exit.** Because the reserve stands behind every sale, an outvoted member can leave and withdraw their canonical share on the way out ([the exit right](/blog/the-exit-right)). Owned liquidity here is not just a treasury flex — it is the thing that makes a credible [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) possible.

Where Olympus had to _acquire_ protocol-owned liquidity and then defend it, a caper starts with it: the market and its backing are the same object.

## Retroactive public goods funding (RetroPGF)

URL: https://caper.network/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding
Updated: 2026-08-05

|  |  |
| --- | --- |
| **Concept** | Retroactive public goods funding — paying for work _after_ it has demonstrably worked, instead of awarding grants up front on a promise |
| **Core thesis** | [“it’s easier to agree on what _was_ useful than what _will be_ useful”](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) — Optimism, 20 July 2021 |
| **Canonical implementation** | Optimism’s Retro Funding (formerly RetroPGF) — six numbered rounds 2021–2024, then metrics-driven “missions” in 2025 |
| **Who decides** | “Badgeholders” / Citizens voting in the [Citizens’ House](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx) — 24 voters in Round 1, growing to ~146 by Round 3 via a “web of trust” |
| **Status (July 2026)** | **Paused.** [“The Retro Funding program will not run for at least the next 12 months”](https://www.optimism.io/blog/season-9-from-experiment-to-organization) (8 January 2026); a proposal to re-allocate the ~775M OP reserved for it [was slated for Season 9](https://gov.optimism.io/t/guide-to-season-9/10529) |
| **Central difficulty** | Impact still has to be _judged_. Optimism’s own retrospective found voting [felt “a bit like a popularity contest”](https://optimism.io/blog/retropgf-3-learnings-reflections) |
| **Related** | [Quadratic voting & funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) · [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [Futarchy](/wiki/dao-governance/concepts/voting/futarchy) · [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) |

**Retroactive public goods funding** (RetroPGF, later renamed **Retro Funding**) is a grant-making method that reverses the usual order of operations: instead of a committee predicting which projects will be valuable and funding them in advance, it waits until work has been done, judges what actually proved useful, and pays for that. The idea was set out by [Optimism in July 2021](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) — with a section contributed by Vitalik Buterin — and rests on a single claim: _“it’s easier to agree on what was useful than what will be useful.”_

The appeal is obvious to anyone who has run a grants program. Prospective grants are bets on people and pitches, and most of the information that would settle the bet arrives after the money is gone. Retroactive funding waits for that information. Between 2021 and 2025, Optimism spent tens of millions of OP tokens testing whether the thesis survives contact with a real treasury and real voters. This page covers the mechanism, the rounds, what Optimism itself concluded went wrong, the January 2026 pause, and the handful of other ecosystems that have tried it.

## The 2021 design: a results oracle and a market that front-runs it

The original proposal has two halves, and the second is routinely forgotten. The first half is the **results oracle**: [“A DAO, which we can call ‘the Results Oracle’, funds public good projects… retroactively, rewarding projects that it recognizes as having already provided value.”](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) That is the part everybody implemented.

The second half is what was supposed to make it more than a well-timed grants committee. Projects issue tokens, and because everyone knows a results oracle will eventually pay out for demonstrated impact, those tokens become — in the post’s own words — [“essentially creating a prediction market for what the results oracle will fund.”](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) Speculators who believe a project will later be judged valuable buy its tokens early, which funds the work _now_. The oracle sets a floor: [“if it allocates a reward of $X, and the project has a total supply of N tokens, then it publishes an open order to buy up to the entire supply of those tokens at a price of $X/N per token.”](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) Retroactive judgement, prospective capital. The oracle never has to predict anything; the market does the predicting and takes the risk.

Optimism folded the ambition into its [Working Constitution](https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55) (April 2022) as a stated purpose: “The primary function of the Collective is to minimize the discrepancy between collective impact and individual profit” — the slogan _impact = profit_. In practice the funded-project-token market never materialised at scale, and Retro Funding ran as the oracle alone: a periodic vote distributing a pot to projects that had already shipped.

## The rounds

Optimism ran six numbered rounds. The scale grew roughly thirty-fold, and the mechanism changed almost every time — each change an attempt to fix what the previous round exposed.

|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **Round** | **When** | **Pot** | **Voters** | **Mechanism** |
| RetroPGF 1 | Q4 2021 | $1M (pre-OP-token) | 24, picked by the Foundation | Ballot via quadraticvote.co; 58 of 76 nominees paid |
| RetroPGF 2 | March 2023 | 10M OP | 69 of 71 voted | Mean; all 195 nominated projects paid |
| RetroPGF 3 | Nov–Dec 2023 | 30M OP | ~145–146 | Median with a quorum of 17; 1,594 applied → 501 paid |
| Retro Funding 4 | July 2024 | 10M OP | 108 of 133 voted | [Metrics-based](https://gov.optimism.io/t/retro-funding-4-impact-metrics-a-collective-experiment/8226) — voters weighted metrics, not projects |
| Retro Funding 5 | Oct 2024 | 8M OP | 111 (84 Citizens + 27 guests) | Category subgroups |
| Retro Funding 6 | Nov 2024 | 2.4M OP | 78 of 102 Citizens + 60 of 76 guests | Guest votes at 1:1 |

In 2025 the round structure was replaced by continuously-measured [missions](https://www.optimism.io/blog/retro-funding-2025): Dev Tooling and Onchain Builders, each up to 8M OP, evaluated monthly against onchain metrics rather than by a vote on projects. Optimism described the programme at that point as backed by [“850M OP dedicated to Retro Funding”](https://www.optimism.io/blog/retro-funding-2025) — one of the largest sums any ecosystem has earmarked for public goods.

The trajectory is worth naming plainly: each redesign removed human judgement. Round 3’s voters judged projects directly and drowned. Round 4 had them judge _metrics_ instead. The 2025 missions had an algorithm judge continuously. The mechanism kept solving its voter problem by giving voters less to do.

## What went wrong — in Optimism’s own words

The most useful critique of Retro Funding is not external. Optimism’s [RetroPGF 3 retrospective](https://optimism.io/blog/retropgf-3-learnings-reflections) is unusually candid, and every finding below is the Collective’s own.

- **It became a popularity contest.** A badgeholder, quoted in the retrospective: _“Now, RPGF feels skewed and personally, a bit like a popularity contest.”_ The mechanism: _“This resulted in selection bias, in which some badgeholders selected applications which they were already familiar with… while not voting on applications which they were not familiar with.”_ Being known beat being useful.
- **Voters could not physically do the job.** [“The broad round scope overwhelmed badgeholders and applicants.”](https://optimism.io/blog/retropgf-3-learnings-reflections) The median badgeholder spent **16 hours** — to triage 643 projects for a 30M OP pot.
- **Impact resisted measurement.** [“The absence of standardized, verifiable, and comparable impact metrics… made it difficult to objectively measure the impact.”](https://optimism.io/blog/retropgf-3-learnings-reflections) The retrospective goes further and questions the premise: _“It’s questionable how accurate and efficient RetroPGF can become in rewarding impact, if its allocation decisions rely on individuals selecting which applications to vote on and then subjectively evaluating their impact.”_
- **Impact did not equal profit.** The single most damning number: the top 20% of projects by _sequencer fee revenue contributed_ received only **5% of rewards** ([RetroPGF 3 retrospective](https://optimism.io/blog/retropgf-3-learnings-reflections)). Measured against the one hard proxy for value delivered to the chain, the distribution was close to backwards.
- **Hand-picking the voters bought nothing.** Optimism’s [own research into citizenship](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx) compared its carefully cultivated badgeholders against a random community sample: _“No significant differences were found between badgeholders (selected via the web-of-trust model) and a random community sample.”_ Both were the same “enthusiast” persona. The web of trust — Round 1’s 24 Foundation picks, Round 2’s 71, Round 3’s 146 by invitation — had produced a selection process no better than drawing names.
- **Self-dealing was real, and adjudicated.** A review of 55 randomly-sampled Round 3 ballots found a Code of Conduct violation: a Protocol Guild member voted for Protocol Guild, and had their [voting badge removed for Round 4](https://gov.optimism.io/t/retropgf-3-conflicts-of-interest-season-5-citizens/7506). One case in a small sample, handled openly — but it is the conflict every retroactive committee carries, since the people qualified to judge impact are the people entangled in it.

Vitalik’s [own review of Round 1](https://vitalik.eth.limo/general/2021/11/16/retro1.html) had flagged the same failure four years earlier: winners were _“more well-known projects”_, plus a friendship bias and a monoculture in which essentially every winner was a technology project. The design never shook it. Academic work has since shown that all four of the voting mechanisms Optimism used are [not strategyproof](https://arxiv.org/html/2508.16285), and that the Round 3/4 quorum rule induces formal failures of monotonicity and participation.

## The 2026 pause

On **8 January 2026**, in the post announcing Season 9, Optimism stated: [“The Retro Funding program will not run for at least the next 12 months.”](https://www.optimism.io/blog/season-9-from-experiment-to-organization) The rationale given: _“As Optimism enters a new phase focused on execution, scale, and enterprise adoption, the Retro Funding program will be paused to reevaluate how it fits into Optimism’s long term strategy.”_ The governance-side [Guide to Season 9](https://gov.optimism.io/t/guide-to-season-9/10529) (7 January 2026) is blunter: _“The Foundation will not propose any Retro Funding Missions in Season 9 or 10.”_

The reserved tokens are in play. Per the Season 9 guide, _“A proposal to re-allocate all or a portion of the tokens reserved for Retro Funding (~775M OP), and/or other uses, will be put forward by the Foundation during Season 9.”_ (The blog hedges the same sentence to “may be put forward… in the coming months”.) At the time of writing this wiki has not verified whether that reallocation vote was held or how it resolved — Season 9 ran to 3 June 2026.

Language matters here, so: Optimism has **paused** Retro Funding, not cancelled it, and says [“Public goods remain core to Optimism’s vision.”](https://www.optimism.io/blog/season-9-from-experiment-to-organization) The 12-month floor runs to at least January 2027. But the plain reading is that the largest retroactive-funding experiment in crypto — 850M OP earmarked, roughly 20M OP paid out in 2024 alone — is stopped, its remaining ~775M OP is a candidate for reallocation toward enterprise adoption, and the reason given is not that the mechanism failed but that the organisation’s priorities moved. Governance in Season 8 had already removed the last incentive to participate: [“There will be no financial rewards or incentives for being a Citizen or voting in Season 8 and beyond.”](https://www.optimism.io/blog/governance-in-season-8-the-next-phase)

## Beyond Optimism

Retro funding travelled, though most copies are smaller and several “retro” programmes are retroactive in name only. Three distinctions are worth holding.

**Genuinely retroactive — impact judged after the fact:**

- **Filecoin** ran three rounds: [200,000 FIL across 99 projects](https://filecoin.io/blog/posts/unveiling-fil-retropgf-1-retroactively-funding-filecoin-public-goods/) in Round 1, 300,000 FIL / 97 projects in Round 2, and [585,000 FIL](https://filecoin.io/blog/posts/filecoin-retropgf-round-3-powering-proven-impact-with-585k-fil/) in Round 3 ([fil-retropgf.io](https://www.fil-retropgf.io/)).
- **Celo** ran **CeloRPGF0** in H1 2024 as the retroactive half of a combined quadratic-funding and retro programme, which CGP115 funded with [125,000 cUSD and 250,000 CELO across both mechanisms](https://forum.celo.org/t/celo-public-goods-qf-rpgf-program-for-h1-2024/7566). [89 of 160 registered projects cleared CeloRPGF0 review](https://forum.celo.org/t/celopg-h1-progress-report/8126). It ran on EasyRetroPGF and used [Hypercerts](/wiki/dao-governance/concepts/treasury/hypercerts) to represent claimed impact.
- **Zcash** is the most interesting recent adopter: coinholder-directed retroactive grants funded by **12% of block rewards** flowing to a protocol lockbox, with [inaugural results in November 2025](https://forum.zcashcommunity.com/t/53487) (9 proposals voted, 5 approved, over 1,000,000 ZEC voted) and now quarterly. Note what it fixes: the funding is protocol-level and automatic, and the judges are coinholders rather than an invited committee.
- **Pocket Network**’s [PEP-72](https://forum.pokt.network/t/pep-72-retroactive-pokt-goods-funding-rpgf/5187) distributed 60,000 OP + 70,000 ARB + 750,000 POKT (~$475,000) — funded partly _out of_ grants Optimism and Arbitrum had given POKT. A retro-funding cascade, downstream.

**Retroactive target, quadratic mechanism** — closer to [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) pointed backwards: [Arbitrum’s Citizens Retrofunding Round 1](https://forum.arbitrum.foundation/t/the-arbitrum-citizens-retrofunding-round-1-results-recap/19985) (100k ARB, late 2023), and Gitcoin’s own [Citizens Retroactive Funding](https://gov.gitcoin.co/t/17215) ($153k in GTC). Gitcoin also supplied much of the tooling: WEST built a Round 3 frontend for Optimism and open-sourced it as [EasyRetroPGF](https://github.com/gitcoinco/easy-retro-pgf), the stack Celo and others reused.

**Frequently miscategorised:** [Protocol Guild](/wiki/daos/public-goods/protocol-guild) is continuous vesting rather than a round, but weights shares retroactively — “The earlier a contributor’s `start_date`, the higher their overall Split share, rewarding them retroactively for historical contributions.” [Octant](https://github.com/golemfoundation/octant) is often grouped with RetroPGF but its allocation code is quadratic funding over staking yield — prospective matching, closer to Gitcoin Grants. And [Avalanche’s Retro9000](https://www.avax.network/about/blog/retro9000-a-40m-grant-program-rewards-developers-building-avalanche-l1s) (up to $40M) is retroactive in _disbursement_ — you build first, then get paid — without the impact-assessment vote that defines the model.

## What the experiment actually taught

The 2021 thesis is probably still true: hindsight really is cheaper than foresight, and it is easier to agree on what was useful than what will be. What five years of rounds demonstrated is that this is _not the binding constraint_. Knowing the past is easy; **agreeing on it at scale, under a deadline, with money attached, by people who are entangled with the projects they are scoring** — that is the hard part, and retroactivity does nothing about it. The judgement problem was never in the tense.

The other lesson is structural. The half of the design that made retro funding elegant — project tokens as a prediction market that front-runs the oracle, so capital reaches builders before the reward lands — is the half nobody built. Without it, retroactive funding is a grants committee with better information and worse timing: the work still has to be financed somehow while it happens, and “ship first and hope a committee notices” is a funding model only the already-funded can afford. That, rather than any voting-mechanism defect, may be the deepest reason the winners kept looking like the projects that were already well-known.

## How Caper approaches this

Caper does not run a grants programme, and nothing here is a retro-funding mechanism. But it shares the underlying ambition — make the record of what you actually did, rather than what you hold or promise, determine what you get — and it is instructive to see where the two designs diverge, because Caper’s version is far narrower and that narrowness is the point.

In a caper, voting mints a **non-transferable proof-of-vote token**: an indivisible resource (`DIVISIBILITY_NONE`) you cannot buy, sell, or be airdropped. It only accumulates by having voted. Governance weight is then computed by the contract as `(held × your votes) / (vote supply × tokens in circulation)` — and the same helper computes your share of the treasury when you [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Your voting record and your claim on the money are the same number. Be clear about what that does and does not mean: your holdings are a _multiplicative factor_, so this is not a bagless system — capital still counts. What it means is that a large bag alone cannot capture control, because the earned half of the product cannot be purchased at any price.

Set against Retro Funding’s failure modes, the contrast is mostly about who judges. Optimism’s central problem was that impact had to be assessed by people — and its own retrospective found they were overwhelmed at 16 hours a head, biased toward projects they already knew, sometimes conflicted, and collectively no more discerning than a random sample. Caper has no badgeholders, no committee, and no impact assessment, because it measures exactly one thing and measures it mechanically: did you show up and vote. That is a vastly poorer notion of contribution than “impact” — it says nothing about whether you voted _well_ — and it is not a substitute for funding public goods. The honest claim is narrow: the one contribution Caper does reward, it rewards without anyone’s judgement, on a record nobody can buy their way into.

## References

- [Optimism — “Retroactive Public Goods Funding” (20 July 2021)](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) — the founding post, with Vitalik Buterin contributing the results-oracle section.
- [Vitalik Buterin — “Retrospective on the Retroactive Public Goods Funding round” (16 Nov 2021)](https://vitalik.eth.limo/general/2021/11/16/retro1.html)
- [Optimism — RetroPGF 3: learnings and reflections](https://optimism.io/blog/retropgf-3-learnings-reflections) — the candid retrospective.
- [Optimism community-hub — Experimentation with citizenship](https://github.com/ethereum-optimism/community-hub/blob/main/pages/citizens-house/experimentation-with-citizenship.mdx) — web-of-trust growth and the badgeholders-vs-random finding.
- [Working Constitution of the Optimism Collective](https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55) · [The evolution of Retro Funding in 2025](https://www.optimism.io/blog/retro-funding-2025)
- [Optimism — “Season 9: from experiment to organization” (8 Jan 2026)](https://www.optimism.io/blog/season-9-from-experiment-to-organization) · [gov.optimism.io — Guide to Season 9 (7 Jan 2026)](https://gov.optimism.io/t/guide-to-season-9/10529) — the pause.
- [Mechanism analysis of Optimism’s RetroPGF voting rules (arXiv:2508.16285)](https://arxiv.org/html/2508.16285)
- [Open Source Observer — inside the Retro Funding 5 ballot box](https://docs.oso.xyz/blog/rf5-ballot-box/)

## Standing authorizations and delegated mandates

URL: https://caper.network/wiki/dao-governance/concepts/treasury/standing-authorizations
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | Authority a DAO grants once and does not re-vote: committee mandates, parameter stewards, guardians and auto-adjusting modules |
| **Core rule** | A single passed proposal defines a _class_ of future actions plus the bounds they must satisfy; anything inside those bounds executes with no further vote |
| **Also called** | Delegated mandate, blanket authorization, steward or guardian powers, instant-access module |
| **Bounds actually used** | Magnitude (how much), direction (which way), frequency (how often), scope (which parameters) |
| **Bound rarely used** | Duration — three of the four production mechanisms surveyed below carry no expiry at all |
| **Read at source** | [Lido Easy Track](https://github.com/lidofinance/easy-track/blob/master/contracts/EasyTrack.sol) · [Maker DssAutoLine](https://github.com/makerdao/dss-auto-line/blob/master/src/DssAutoLine.sol) · [Aave RiskSteward](https://github.com/bgd-labs/aave-v3-risk-stewards/blob/main/src/contracts/RiskSteward.sol) · [Compound Comptroller](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Comptroller.sol) |
| **Related** | [Optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance) · [Security councils](/wiki/dao-governance/concepts/fundamentals/security-councils) · [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) |

A **standing authorization** is a decision a DAO takes once about a class of future actions rather than about a single action. Instead of voting to raise a debt ceiling, the DAO votes on a formula that raises it; instead of voting on each grant, it votes on a committee with a budget and a spending envelope. Every action that lands inside the envelope executes without a further ballot.

This is the most common answer to a problem the wiki documents from the other side on [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy): an electorate that cannot summon a quorum for routine business will not become more engaged if you give it more routine business. Lido's own documentation states the motivation plainly — Easy Track was built "as a solution to the problem of the DAO getting tired of governance". The cost is that a DAO which delegates enough of its recurring decisions can arrive at a state where the treasury is busy and the ballot box is empty, and nothing in the mechanism announces that it has happened.

## What makes an authorization standing

An ordinary proposal names a recipient, an amount and a moment. A standing authorization names none of those. It fixes four things instead, and the interesting variation between real designs is which of the four they bother to fix:

- **Scope** — which parameters or accounts the mandate may touch. Universally present; a mandate with no scope is just an admin key.
- **Magnitude** — how far a single exercise may move the parameter, or how much it may spend.
- **Direction** — whether the holder may only act one way. The strongest constraint available, because a one-way power cannot be used to undo the DAO's own decisions.
- **Frequency** — a cooldown between exercises, which converts a fast attack into a slow one the DAO has time to notice.

A fifth bound — **duration**, an expiry after which the mandate lapses unless renewed — is the one most often missing. It is also the only bound that forces the DAO to hold the vote again.

## Four mechanisms, read at source

### Lido: Easy Track motions

[Lido](/wiki/daos/staking/lido-dao)'s [Easy Track](https://docs.lido.fi/guides/easy-track-guide/) (introduced as [LIP-3](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-3.md)) gives named committees the right to start a motion that passes by default. A motion is enacted if objections stay below a threshold for the motion's duration; [`enactMotion`](https://github.com/lidofinance/easy-track/blob/master/contracts/EasyTrack.sol) carries no role gate at all, so once the window closes anyone may execute it. Objections are one per address, weighted by LDO balance at the motion's snapshot block, and the motion is deleted the instant the running total crosses the threshold rather than at the end of the window.

The committees are listed in Lido's own guide and span node-operator staking limits, the Simple DVT and Community Staking modules, the LEGO grants programme, the Liquidity Observation Lab, the Rewards Share programme, the RCC, PML and ATC operating entities, the TRP multisig, gas rebates and treasury swaps. That is a wide surface of recurring spending that no LDO holder votes on individually.

What is worth reading in [`MotionSettings.sol`](https://github.com/lidofinance/easy-track/blob/master/contracts/MotionSettings.sol) is the gap between what the contract permits and what the DAO configured. The contract allows an objections threshold as loose as `MAX_OBJECTIONS_THRESHOLD = 500` basis points (5%), a duration as short as `MIN_MOTION_DURATION = 48 hours`, and as many as `MAX_MOTIONS_LIMIT = 24` live motions. Lido runs at 0.5%, 72 hours and 20. The DAO chose to be bound an order of magnitude more tightly than its own code requires on the objection dial, and more tightly on the other two — a deliberate margin that only shows up if you compare the deployment against the source.

### Maker: the debt-ceiling instant-access module

[Maker](/wiki/daos/stablecoins/sky-dao)'s [`DssAutoLine`](https://github.com/makerdao/dss-auto-line/blob/master/src/DssAutoLine.sol) removes a governance vote from the loop entirely rather than delegating it to people. Governance calls `setIlk(ilk, line, gap, ttl)` once, fixing a maximum ceiling, a step size and a cooldown. After that `exec(ilk)` is external and unauthenticated: _anyone_ may call it, and it sets the ceiling to `min(debt + gap, line)`.

The asymmetry in that function is the design. An _increase_ is refused if `block.timestamp < lastInc + ttl`, so the ceiling can only be raised once per cooldown; a _decrease_ is subject to no such check and may be applied by anyone at any time. The mandate is rate-limited in the direction that adds risk and unlimited in the direction that removes it. This is direction and frequency bounded together, with no human holder to trust at all.

### Aave: risk stewards

[Aave](/wiki/daos/lending/aave-dao)'s [`RiskSteward`](https://github.com/bgd-labs/aave-v3-risk-stewards/blob/main/src/contracts/RiskSteward.sol) hands a risk council the right to move supply caps, borrow caps, e-mode settings, interest-rate curves and price caps without a governance vote. Its [interface](https://github.com/bgd-labs/aave-v3-risk-stewards/blob/main/src/interfaces/IRiskSteward.sol) reduces the whole mandate to a two-field struct per parameter, `RiskParamConfig { uint40 minDelay; uint256 maxPercentChange }`, and `_validateParamUpdate` enforces exactly those two: it reverts `DebounceNotRespected` when the parameter moved more recently than `minDelay`, and `UpdateNotInRange` when the change exceeds `maxPercentChange`. A separate guard rejects any update to zero.

Governance keeps two levers as owner — `setRiskConfig` to retune the bounds and `setAddressRestricted` to carve individual assets out of the mandate. There is no expiry anywhere in the contract.

### Compound: the pause guardian

[Compound](/wiki/daos/lending/compound-dao)'s [`Comptroller`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Comptroller.sol) is the cleanest example of a purely directional mandate. Each of `_setMintPaused`, `_setBorrowPaused`, `_setTransferPaused` and `_setSeizePaused` carries the same pair of requirements: the caller must be the pause guardian or the admin, and then `require(msg.sender == admin || state == true, "only admin can unpause")`. The guardian may stop the protocol and may never restart it. Its worst case is a denial of service that governance can reverse; it cannot be used to open anything.

## The dial nobody sets

Read together, the four mechanisms converge on the same three bounds and skip the fourth. Easy Track bounds magnitude through per-factory limits and frequency through the 72-hour window; `DssAutoLine` bounds magnitude by `gap`, direction by the increase-only cooldown and frequency by `ttl`; `RiskSteward` bounds magnitude by `maxPercentChange` and frequency by `minDelay`; the pause guardian bounds direction absolutely. None of them expires.

That is a defensible engineering choice — an expiring pause guardian is a hole waiting for a lapsed renewal — but it has a governance consequence that is rarely stated. Because the mandate does not expire, the DAO is never forced to revisit it, and the natural review trigger is an incident rather than a calendar. A mandate granted to a committee that has since lost its members, or scoped to a market the DAO no longer runs, stays live and stays invisible, which is the same failure the wiki records under [council dissolution](/wiki/dao-governance/concepts/analysis/council-dissolution): bodies are far easier to create than to wind up.

The practical counterweight is a [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) on the mandate's own configuration, so retuning the bounds is itself slow and visible, plus a periodic inventory of who currently holds what. Neither is a substitute for an expiry.

## Where duration is bounded: elected cohorts

The mechanism that does carry a hard expiry is not a parameter mandate but a seat. [Arbitrum](/wiki/daos/networks/arbitrum-dao)'s [DAO Constitution](https://docs.arbitrum.foundation/dao-constitution) gives its Security Council twelve members split into two cohorts of six, with an election every six months that replaces one cohort. A seat is therefore a twelve-month term that ends whether or not anyone proposes to end it, and the authorization it carries dies with it unless the holder is re-elected.

The election rules are themselves shaped against capture: a contender must be pledged at least 0.2% of all Votable Tokens to reach the ballot, a sitting member of one cohort may not stand for a seat in the other, and in the final voting window votes cast after T+35 days carry linearly decaying weight through T+49 — a deliberate penalty on deciding the outcome at the last moment. The pattern to take from it is that DAOs already know how to time-bound authority; they apply it to people and not to parameters. See [security councils and emergency powers](/wiki/dao-governance/concepts/fundamentals/security-councils) for the powers themselves.

## When the mandate replaces the vote

The end state a standing authorization can reach is visible on this wiki in one fully documented case. [Long COVID Labs](/wiki/desci/ecosystem/long-covid-labs)' [proposal DP-6](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x8ddf514864948045bf156468e9d3ec1e223771912a04e03e4c7b5bc81ed434e6), which closed on 7 October 2025 with fifteen addresses voting, authorized a token generation event, a funded liquidity pool, and — the clause that matters here — authority for the operating multisig to pursue further DEX and CEX listings "without requiring new governance proposals". No proposal has been put to that DAO since. The treasury has visibly continued to execute the budget the DAO approved; the ballot box has been idle for the whole period.

Nothing there was a breach. Every action taken sat inside a mandate the holders granted on the record. But it shows what the missing duration bound produces at the limit: a DAO whose last governance act was to make further governance acts unnecessary. The measurable symptom is not a failed vote — it is the absence of votes alongside continuing treasury activity, which is a diagnostic any DAO can run against itself and almost none do. It is worth pairing with [delegate accountability](/wiki/dao-governance/concepts/voting/delegate-accountability), where the same silence is read from the voter's side rather than the treasury's.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no standing authorization of any kind, and this is a structural fact rather than a policy. Its treasury moves only through the settlement of one specific proposal: every execution entry point in the contract takes a cashtag and a proposal id, and every option a proposal can carry is one of five typed kinds — pay a recipient, buy another caper's token, sell one back down its curve, cast a vote inside another caper, or (for $CAPER only) upgrade the platform logic. There is no recurring option, no stream, no committee address, and no role that can act on the treasury between proposals.

The trade is real and runs both ways. A caper cannot delegate its routine spending to a grants committee, so it pays the full attention cost of every decision; the mechanisms above exist precisely because that cost is what exhausts large DAOs. What it buys is that the diagnostic in the previous section can never come back positive: treasury activity and governance activity are the same events, so a caper cannot be busy and ungoverned at once. The pressure valve is on the other side — a member who dislikes where the treasury is going does not need a veto or a committee seat, only [the exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights).

## References

- Lido, [Guide to Easy Track](https://docs.lido.fi/guides/easy-track-guide/) — objections threshold, motion duration and the committee list.
- Lido, [`MotionSettings.sol`](https://github.com/lidofinance/easy-track/blob/master/contracts/MotionSettings.sol) and [`EasyTrack.sol`](https://github.com/lidofinance/easy-track/blob/master/contracts/EasyTrack.sol) — the contract-level bounds and the objection accounting.
- Lido, [LIP-3: Easy Track motions](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-3.md).
- MakerDAO, [`DssAutoLine.sol`](https://github.com/makerdao/dss-auto-line/blob/master/src/DssAutoLine.sol) — `setIlk`, and the asymmetry inside `exec`.
- BGD Labs, [`RiskSteward.sol`](https://github.com/bgd-labs/aave-v3-risk-stewards/blob/main/src/contracts/RiskSteward.sol) and [`IRiskSteward.sol`](https://github.com/bgd-labs/aave-v3-risk-stewards/blob/main/src/interfaces/IRiskSteward.sol) — `RiskParamConfig` and `_validateParamUpdate`.
- Compound, [`Comptroller.sol`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Comptroller.sol) — the pause guardian's one-way requirement.
- The Arbitrum Foundation, [Arbitrum DAO Constitution](https://docs.arbitrum.foundation/dao-constitution), Section 4: Security Council Elections.

## Conviction Voting

URL: https://caper.network/wiki/dao-governance/concepts/voting/conviction-voting
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Topic** | Continuous, time-weighted fund allocation for DAO treasuries |
| **Core rule** | Support ("conviction") on a proposal charges up the longer tokens stay staked, and decays when they leave |
| **Passes when** | Accumulated conviction crosses a dynamic threshold scaled to the share of treasury requested |
| **Origin** | Michael Zargham (Social Sensor Fusion) → [Commons Stack](https://github.com/commonsbuild) + [BlockScience](https://github.com/BlockScience), 2019 |
| **First in production** | [1Hive Gardens](https://github.com/1Hive/conviction-voting-app) on Gnosis Chain |
| **Best for** | Steady grant/treasury outflows — not binary yes/no protocol votes |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Quadratic voting & funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) |

**Conviction voting** is a continuous-funding mechanism in which a voter's influence over a proposal grows the longer they keep tokens staked behind it, and fades once they withdraw. There are no ballots and no voting deadline: supporters signal a preference at any time by staking [governance tokens](/wiki/dao-governance/concepts/voting/token-weighted-voting) on the proposals they want funded, their **conviction** charges up over days according to an exponential curve, and a proposal executes automatically the moment its accumulated conviction crosses a threshold set by how large a slice of the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) it asks for. It is one of the most mature alternatives to periodic, quorum-gated voting, and it is aimed squarely at the problem it solves best — a steady stream of grant and treasury-allocation decisions that a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) does not want to marshal a fresh vote for every time.

## How conviction accumulates

When a member stakes tokens on a proposal, that support does not count at full strength immediately. Instead conviction builds up over time toward a ceiling set by the staked amount, following a discrete exponential-decay update — each block, existing conviction is multiplied by a decay parameter _α_ (just below 1) and the current stake is added on top. The same α that charges conviction up also bleeds it away: pull your stake and your conviction on that proposal decays back toward zero at the same rate. The parameter is usually described by its **half-life**; 1Hive's reference Aragon app, for example, shipped with a decay of `0.9999599`, giving conviction a roughly **three-day half-life** ([1Hive/conviction-voting-app](https://github.com/1Hive/conviction-voting-app)).

The consequence is that **sustained commitment, not a single-block snapshot, is what moves money**. A whale who borrows capital to swing a vote at the last minute — the standard attack on deadline-based [token voting](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) — gains almost nothing here, because conviction cannot be bought instantly; it has to be _held_. A small group that keeps its tokens parked on a proposal for a week can out-decide a larger holder who shows up briefly.

## The dynamic passing threshold

Conviction voting has no quorum and no fixed pass bar. A proposal executes when its conviction exceeds a threshold that **scales with the fraction of the common pool it requests**: a proposal asking for a sliver of the treasury needs relatively little sustained support, while one asking for a large share needs far more, and beyond a configured maximum ratio (1Hive used `maxRatio = 0.2`, capping any single proposal at ~20% of funds) no achievable amount of conviction can pass it. Because the threshold is a function of the request size and the total pool, many proposals can be "open" and accruing conviction at once, and the community's finite total stake naturally rations itself across them — you are always implicitly trading off support for one proposal against another ([parameters: maxRatio, rho, decay](https://github.com/1Hive/conviction-voting-app)).

## Origin and production use

Conviction voting grew out of **Dr. Michael Zargham's** doctoral research on multi-agent coordination, where it was first framed as _Social Sensor Fusion_ — treating each staker as a noisy sensor whose signal you integrate over time rather than sampling once. From 2019 it was developed into a governance mechanism by the [Commons Stack, BlockScience, Aragon, and the 1Hive community](https://medium.com/commonsstack/announcing-the-conviction-voting-cadcad-model-release-8e907ce67e4e), and formally modelled and parameter-tuned in [cadCAD simulations](https://github.com/1Hive/conviction-voting-cadcad) before deployment. **1Hive's Gardens** framework, built as an Aragon app on Gnosis Chain and used to allocate its HNY common pool, was the first production system to run it ([1Hive wiki](https://wiki.1hive.org/)). It has since been picked up by other Commons-style and public-goods communities as a treasury-allocation layer. The largest live instance is [Giveth](/wiki/daos/public-goods/giveth)'s **GIVgarden**, also a Gardens deployment on Gnosis Chain, which publishes its parameters openly: a **30-day** conviction growth, a **2.50%** spending limit per proposal, **5%** minimum conviction, and **5,000**/**10,000** GIV action and challenge deposits, with challenged proposals escalating to the **Celeste** court ([GIVgarden docs](https://docs.giveth.io/givgarden)). It is a useful worked example of how the abstract parameters above get set in practice — and of the deposit-plus-court layer a production Garden adds around them, since conviction voting on its own has no mechanism for rejecting a proposal that is simply illegitimate.

## Where it fits — and where it doesn't

Conviction voting is deliberately narrow. Its strengths are real: it removes the "everyone must show up on the same day" attention tax of deadline voting — the same problem of [scaling collective attention](/wiki/dao-governance/concepts/voting/holographic-consensus) that DAOstack met with a prediction market — it makes rented-capital and flash-loan swings structurally useless, and it lets funding flow continuously instead of in lumpy voting cycles. But it is a **fund-allocation mechanism, not a general governance system** — it answers "which of these spending requests should the treasury pay?", not "should we upgrade the protocol?", for which a binary, timely, executable [proposal vote](/wiki/governance/proposals) is still the right tool. It is also **slow by design** (urgent decisions fit it poorly), and its base weighting is still [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting): a large holder who commits for the long haul still dominates, so conviction voting mitigates timing attacks and apathy without escaping the underlying [plutocracy critique](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks). Communities that also want to blunt whale dominance pair it with, or weigh it against, [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) and [Sybil-resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) layers.

## How Caper approaches this

Caper shares conviction voting's core instinct — that **durable commitment should count for more than a moment's balance** — but reaches it by a different route. A [caper](/wiki/foundations/what-is-a-caper) does not run a continuous conviction accumulator; it uses discrete, executable [proposals](/wiki/governance/proposals) whose weight is the canonical formula _w = (t · v) / (V · T)_, where _t_ is your governance-token balance and _v_ is your accumulated [participation](/wiki/governance/voting-mechanisms). The time dimension lives in that _v_ term: participation is earned by showing up to vote and is not something you can buy in a block, so a long-standing contributor carries structurally more weight than a large holder who just arrived — the same "you can't rent it, you have to earn it over time" property conviction voting gets from its decay curve, expressed as a soulbound participation record rather than a staked-duration integral. And because that identical weight also sets a member's [pro-rata exit share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), the incentive to accumulate participation honestly is built in. Where conviction voting keeps many funding requests open and lets sustained stake ration a common pool, Caper resolves each proposal to a definite executed outcome — different mechanics, aimed at the same failure of one-block, capital-only voting.

## Delegate accountability and dormant delegates

URL: https://caper.network/wiki/dao-governance/concepts/voting/delegate-accountability
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Topic** | What a delegate owes the holders behind them, and what happens when they stop voting |
| **Why it bites** | Delegation under [ERC-5805](https://eips.ethereum.org/EIPS/eip-5805) never expires, so weight can outlive the delegate's attention |
| **Answer 1 – expire it** | Optimism counts only _active_ votable supply: delegated power unused for six months leaves the quorum denominator |
| **Answer 2 – pay for it** | Arbitrum's RAD program pays delegates against a published monthly participation bar and prints who missed it |
| **Answer 3 – write the rule into the delegation** | Agora's Alligator subdelegation rules carry `notValidAfter` and a vote-close backstop |
| **Answer 4 – overrule it** | OpenZeppelin's `GovernorCountingOverridable` (v5.2.0) lets the holder cancel their delegate's vote while the poll is still open |
| **Chief failure** | A dormant delegate is a quorum tax: counted in the denominator, never in the tally |
| **Related** | [Voting power activation](/wiki/dao-governance/concepts/voting/voting-power-activation) · [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) · [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) · [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) |

Delegation is the mechanism that makes large token electorates workable: a holder who will never read a proposal assigns their weight to someone who will. [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) covers how that market forms and re-concentrates, and [voting power activation](/wiki/dao-governance/concepts/voting/voting-power-activation) covers the supply-side arithmetic underneath it. This page covers what happens afterwards – the accountability half. A delegate who stops voting does not return the weight, does not stop being counted, and in most DAOs is not removed by any mechanism at all. The holders behind them usually never notice, because nothing in the standard tells them.

## Delegation has no expiry

[ERC-5805](https://eips.ethereum.org/EIPS/eip-5805), the standard that governs delegated voting on Ethereum, describes delegation as a single assignment: an account delegates to itself, to a third party, or to `address(0)`, and the delegatee's checkpointed voting power moves accordingly. The interface it specifies is `delegates(account)`, `delegate(delegatee)`, `delegateBySig(...)`, `getVotes` and `getPastVotes`. There is exactly one `expiry` parameter in the whole standard and it belongs to `delegateBySig`, where it is the deadline on the _signature_, not on the delegation the signature creates. Nothing in the standard lapses, decays, or requires renewal.

That is a reasonable default for a token contract – the alternative is a contract that silently disenfranchises people – but it means a delegation made once during an airdrop claim in 2021 is still live in 2026 unless the holder returns and changes it. The delegate may have left the ecosystem, wound up their organisation, or lost the key. The weight stays where it was pointed.

## Why dormancy is not neutral

Undelegated tokens are inert: they count toward supply and toward nothing else. Delegated tokens held by a delegate who never votes are worse than inert, because in any DAO whose quorum is a fraction of _delegated_ supply they raise the bar that everyone else has to clear. The arithmetic of the three competing denominators is set out on [voting power activation](/wiki/dao-governance/concepts/voting/voting-power-activation); the consequence is the one that matters here. A delegate sitting on 2% of delegated supply and voting on nothing does not abstain neutrally. They add two points to the denominator of every quorum calculation while contributing nothing to the numerator, so the active electorate has to supply a strictly larger share of the votes to pass anything. Dormant delegation is a tax on the members who do show up, and it compounds quietly, because delegated weight is normally reported as a sign of engagement rather than as a liability.

It also distorts the standard defence of delegated governance. The claim that a DAO with 40% of supply delegated has a healthy electorate is only true if that 40% votes. Where it does not, the DAO has the worst of both: a hard quorum priced against the full delegated set, and a real turnout drawn from a fraction of it. See [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) for the participation side of the same gap.

## Answer 1: expire dormant weight out of the denominator (Optimism)

The [Optimism Collective](/wiki/daos/networks/optimism-collective)'s [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) solves the quorum tax by refusing to count dormant weight in the first place. Its Token House quorum is 30% of the "total **active** votable OP supply" as of the start of the voting period, and it defines both halves of that phrase: votable supply is the OP that has been delegated and can therefore vote, and it "is considered active if delegated voting power has been utilized within the past 6 months." A delegate who goes six months without casting a vote does not merely fail to help reach quorum; their weight stops being part of the number quorum is measured against. Abstain votes count as utilisation, so the bar for staying in the denominator is participation of any kind rather than agreement.

The mechanism is honest about being a policy rather than an autonomous contract rule. The figure lives in a [VotableSupplyOracle](https://github.com/voteagora/optimism-governor/blob/main/src/VotableSupplyOracle.sol) – a small `Ownable` contract that keeps a checkpointed history of the votable supply and is, in its own comment, "managed by Optimism Governance." The six-month test is computed off-chain and written to that oracle; the governor then reads the checkpoint. So the rule is enforced on-chain in the sense that quorum reads a number nobody can retroactively edit, and governed off-chain in the sense that a privileged owner decides what that number is. That is a real trust assumption and it is worth naming, but it buys something no stock [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) configuration offers: a quorum denominator that shrinks when delegates stop showing up.

## Answer 2: pay for participation, and publish the misses (Arbitrum)

The [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao) takes the opposite approach: leave the denominator alone and buy the attendance. Its Rewarding Active Delegates (RAD) program pays enrolled delegates per proposal against a published monthly bar, and the bar moves with the workload. The [June 2026 results](https://forum.arbitrum.foundation/t/rewarding-active-delegates-june-2026-results/31046) state the rule exactly: four or fewer proposals in a month sets the participation threshold at 50%, five or more sets it at 75%. June 2026 was the first month with five governance actions in scope, so the threshold went back to 75% – at least four votes out of five.

The published outcome is the useful part, because it is a rare public count of how many funded delegates clear an explicit attendance bar. Across those five proposals, 36 enrolled delegates cast votes on 123 delegate–proposal instances, which the report scores as 68.33% program participation. Twenty delegates were paid, sharing $29,000; the other sixteen – named in the report, and including several well-known governance firms – received nothing for the month on grounds of insufficient participation, insufficient voting power, or zero eligible voting power. The program also prices the _quality_ of the vote separately from the fact of it: a vote cast without a public rationale within five days keeps its eligibility but takes a 10% trim on that proposal's reward, and 66.67% of June's voted instances carried an on-time rationale.

Two structural weaknesses show up in the same records. The first is that paying for attendance measures attendance: a delegate can clear 75% by voting with the majority on five proposals they did not read, and the rationale trim is a 10% nudge rather than a real test. The second is budgetary. The [quarterly review for Q3 2026](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) cut every per-proposal budget by 28–40% – a constitutional on-chain vote fell from $15,000 to $10,000, a temperature check from $5,000 to $3,000 – because the budgets are denominated in USD but paid in ARB, and ARB had fallen from around $0.21 at the program's launch to around $0.077. An accountability mechanism funded by a governance token inherits that token's drawdowns, which is precisely when participation is hardest to sustain. The program as treasury spend – its price list, its published payroll corrections, and how it compares to paying for seats or paying in delegated weight – is covered on [delegate incentive programs](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs).

## Answer 3: let the holder write the rule into the delegation

The third approach leaves both the quorum and the incentive alone and changes what a delegation _is_. [Agora](/wiki/dao-governance/tooling/voting/agora)'s Alligator contract, deployed for Optimism's governor, replaces the standard one-address assignment with a rules object. The [SubdelegationRules struct](https://github.com/voteagora/optimism-governor/blob/main/src/interfaces/IAlligatorOP.sol) carries seven fields: `maxRedelegations`, `blocksBeforeVoteCloses`, `notValidBefore`, `notValidAfter`, `customRule`, `allowanceType` and `allowance`. Each is checked when a vote is cast through the delegation chain, and [the validation path](https://github.com/voteagora/optimism-governor/blob/main/src/alligator/AlligatorOP.sol) reverts with a named error when one fails – `NotValidAnymore` past `notValidAfter`, `NotValidYet` before `notValidBefore`, `TooManyRedelegations`, `TooEarly`.

Two of those fields are direct answers to dormancy. `notValidAfter` gives delegation an expiry date, so a holder can lend weight for a season rather than forever and force a renewal decision. `blocksBeforeVoteCloses` is subtler and more interesting: a subdelegate constrained by it can only cast within the final stretch of the voting period, which makes a backup delegate expressible in the contract itself – someone who acts only if the primary delegate has not, and cannot pre-empt them otherwise. `allowance` with a partial `allowanceType` completes the set by letting one holder split weight across several delegates rather than betting the whole balance on one address remaining active.

The cost is complexity: rules are set per delegation by the holder, which means the mechanism only helps holders engaged enough to configure it – a smaller group than the one that delegated and stopped paying attention. Expressiveness at the contract layer does not by itself reach the dormant delegator.

## Answer 4: let the holder overrule the delegate after the fact

Every answer so far asks something of the holder _in advance_ – renew a delegation, pick a better delegate, configure a rules object. That is the limit named at the end of Answer 3: the mechanism reaches the engaged holder, and the problem is the disengaged one. A fourth approach inverts the timing and asks nothing until the holder actually disagrees.

[GovernorCountingOverridable](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol), added to [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) in v5.2.0 on [8 January 2025](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md), lets a delegator cast an override on a proposal their delegate has already voted on. The delegate's tally is reduced by the overriding balance – the contract emits `VoteReduced` against the delegate and `OverrideVoteCast` for the holder – and each holder may override once, guarded by `GovernorAlreadyOverriddenVote`. Nothing has to be arranged beforehand: the delegation stands, the delegate keeps voting on everything else, and the holder intervenes only on the proposal they care about.

Two constraints bound how far this goes. The token has to inherit [VotesExtended](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol), which checkpoints delegations and balances rather than voting units alone, so a DAO already live on a plain `ERC20Votes` token cannot switch this on without changing the token – the same migration cost that has kept most Governor-family DAOs on the modules they launched with. And overrides can only be cast while the proposal is _active_, which the module's own source flags as a composition hazard: a governor that also runs early closure, such as `GovernorSuperQuorum`, can end the poll before the holders who disagreed have used the right the DAO just gave them.

Set against the other three, the trade is clear enough. Answers 1 and 2 act on the [quorum](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) and the delegate's incentives without touching the delegation. Answer 3 makes the delegation itself expressive but only for holders who configure it. Answer 4 is the only one that costs the holder nothing until the moment they want it – and the only one that requires the DAO to have chosen the right token contract years earlier.

## When the electorate drains instead: ENS

[ENS DAO](/wiki/daos/infrastructure/ens-dao) is the live case where the problem is not one dormant delegate but a delegated set that keeps shrinking. In a [July 2026 draft proposal](https://discuss.ens.domains/t/draft-reform-dao-governance-by-delegating-5m-ens-tokens/22247), ENS contributor Alex Van de Sande argued that total delegated votes have been "consistently going down" apart from two jumps that were the same tokens being re-delegated, that turnout has fallen from proposals routinely drawing 3M votes to proposals struggling to make quorum, and that one delegate now holds enough weight to both meet quorum alone and outvote the next 50 delegates combined. His diagnosis is a delegation cohort frozen at airdrop: tokens delegated once at claim, then sold to buyers who never delegate, so the electorate decays with every transfer while the supply stays constant. He notes that the DAO's own MetaGov stewards had already tried free re-delegation, distributing tokens to new contributors and paying holders to stake and delegate, "with mild successes" that did not reverse the trend.

The proposal's remedy – delegating 5M of the DAO's own ENS to stakeholders selected by metric rather than by election – is unresolved and contested, and it sits against a second live fight over whether [a Foundation with a five-seat board](https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329) should take on the DAO's operating functions. Both threads are worth reading as primary material on the same question: when delegated weight thins out, a DAO can respond by re-seeding the delegate set, by shrinking the denominator, or by moving the decisions somewhere delegates do not sit. ENS is publicly weighing all three.

## What accountability mechanisms can and cannot do

**They can make dormancy visible and costly.** Optimism's six-month rule and Arbitrum's published payout tables both convert "this delegate stopped voting" from private knowledge into a number the DAO acts on. Neither existed in the original delegated-governance design, where the only remedy was a holder noticing and re-delegating by hand.

**They cannot make a delegate read the proposal.** Every mechanism above measures the observable act – a vote cast, a rationale posted within five days – because judgment is not measurable on-chain. Paying against attendance can even invert the goal, rewarding a delegate for voting on a question they had no view on rather than sitting out honestly.

**They cannot fix a delegator who has stopped caring.** Expiry, subdelegation rules and partial allowances all require the holder to act again. The population they most need to reach is defined by not acting.

**They interact with the quorum design.** A DAO that both prunes dormant weight from the denominator and enforces a high fixed quorum can find its quorum getting easier in the same month its electorate got smaller. See [quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design); the two settings must be read together, not chosen separately.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no delegation primitive at all. There is no `delegate` entry point in the contracts, so there is no delegate to go dormant, no delegated-supply denominator to inflate, and nothing to expire. [Voting](/wiki/governance/voting) is first-person: the ballot is authorised by the voter's own account and requires a proof of at least one of that caper's tokens, and the weight it carries is the product of the voter's token balance and their balance of the caper's soulbound vote token, over the vote-token supply and the token's circulation. The vote token is minted only by voting, so the participation half of a member's weight cannot be lent, bought, or inherited from an inactive representative.

The consequence for dormancy is the sharp one: it is self-limiting rather than socialised. A member who stops voting stops accumulating the factor that gives their holdings weight, and their stake never sat in anyone else's column raising the bar for the members still voting. The same formula also governs the treasury [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) – the contract requires both a governance-token bucket and a vote-token bucket, so a holder who never voted has no participation-weighted claim on the treasury to exit with.

What this design gives up is the thing delegation exists for. A member with little time cannot lend their voice to someone who will study the proposal, and there is no professional delegate class to do the reading. Caper trades delegation's leverage for its accountability: nobody can represent you, and nobody can misrepresent you by doing nothing.

## References

- [Optimism Collective – Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) (Token House quorum as 30% of _active_ votable supply; the six-month utilisation test)
- [voteagora/optimism-governor – VotableSupplyOracle.sol](https://github.com/voteagora/optimism-governor/blob/main/src/VotableSupplyOracle.sol) (the checkpointed, governance-owned votable-supply figure)
- [voteagora/optimism-governor – IAlligatorOP.sol](https://github.com/voteagora/optimism-governor/blob/main/src/interfaces/IAlligatorOP.sol) (the `SubdelegationRules` struct) and [AlligatorOP.sol](https://github.com/voteagora/optimism-governor/blob/main/src/alligator/AlligatorOP.sol) (rule validation and its named errors)
- [Arbitrum DAO forum – Rewarding Active Delegates, June 2026 results](https://forum.arbitrum.foundation/t/rewarding-active-delegates-june-2026-results/31046) (participation thresholds, payouts, the unpaid list, the rationale trim)
- [Arbitrum DAO forum – RAD Budget Quarterly Review, 2Q2026](https://forum.arbitrum.foundation/t/rad-budget-quarterly-review-2q2026/31031) (the Q3 budget cuts and the ARB-denomination problem)
- [ENS DAO forum – [Draft] Reform DAO governance by delegating 5M ENS tokens](https://discuss.ens.domains/t/draft-reform-dao-governance-by-delegating-5m-ens-tokens/22247) (delegated-vote decay, turnout decline, delegate concentration)
- [ENS DAO forum – [Draft] [Executable] Next Era of ENS DAO](https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329) (the concurrent Foundation proposal and delegate response)
- [ERC-5805: Voting with delegation](https://eips.ethereum.org/EIPS/eip-5805) (the delegation interface, and the one `expiry` that is a signature deadline)
- [OpenZeppelin Contracts – GovernorCountingOverridable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol) (the override receipt, `VoteReduced`/`OverrideVoteCast`, and the active-proposal and early-closure constraints) and [VotesExtended.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol) (the delegation and balance checkpoints it requires)

## Futarchy

URL: https://caper.network/wiki/dao-governance/concepts/voting/futarchy
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Topic** | Governance by prediction market — "vote on values, but bet on beliefs" |
| **Core rule** | For each proposal, run two conditional markets forecasting a chosen metric (usually token price) under _pass_ vs _fail_; adopt whichever the market prices higher |
| **Decides via** | A time-weighted average price (TWAP) comparison over a fixed market window, not a headcount vote |
| **Origin** | Economist [Robin Hanson](https://mason.gmu.edu/~rhanson/futarchy.html), 2000 — "Shall We Vote on Values, But Bet on Beliefs?" |
| **On-chain use** | [MetaDAO](https://docs.metadao.fi/) (Solana, since Nov 2023); [GnosisDAO](https://gnosisdao.ghost.io/gnosisdao-governance-summary-february-2026/) advisory pilot (GIP-145, 2026) |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) · [Conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) · [Quadratic voting](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) |

**Futarchy** is a governance system in which decisions are settled by [prediction markets](https://mason.gmu.edu/~rhanson/futarchy.html) rather than by counting votes. Proposed in 2000 by the economist Robin Hanson, its one-line design is **"vote on values, but bet on beliefs"**: a community decides _what_ it wants to maximise — a measurable success metric — and speculative markets decide _which_ proposal is most likely to achieve it. For each decision, traders bet on the value of that metric in two conditional worlds, one where the proposal passes and one where it fails; whichever world the market prices higher becomes policy. It is the most market-native alternative to the ballot-based mechanisms most [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) use, and after two decades as a mostly theoretical curiosity it now runs live on-chain.

## Vote on values, bet on beliefs

Hanson's insight was to separate two questions a normal vote fuses together. A [token-weighted vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) asks holders to simultaneously express what they want and predict whether a given action will deliver it — and it rewards neither honesty nor accuracy, because a single vote almost never changes the outcome. Futarchy splits the two. The electorate (in a DAO, its token holders) democratically fixes a **welfare metric** — Hanson's original example was GDP-per-capita; on-chain it is almost always the DAO's own token price, a rough but liquid proxy for organisational value. Then, for every proposal, a **decision market** forecasts that metric conditional on the proposal passing versus failing. Because participants stand to win or lose real money on their forecasts, the mechanism is designed to pull information out of whoever holds it — an expert with a strong view can move the price by trading on it, rather than being outvoted by a larger but less-informed crowd. Values stay democratic; beliefs get priced.

## Decision markets on-chain

Turning Hanson's proposal into working software is mostly a market-design problem: the markets must be liquid enough to price accurately and hard enough to manipulate that the verdict can be trusted. [MetaDAO](https://docs.metadao.fi/governance/markets), the reference implementation on Solana, does it with **conditional tokens**. When a proposal goes live, the DAO takes roughly **half the liquidity** from its spot pool and moves it into two conditional markets — a _pass_ market and a _fail_ market — so neither starts empty. Spot tokens are split into conditional versions, and a **conditional trade reverts if its world does not happen**: buy in the pass market and the proposal fails, and your trade simply unwinds as though it never occurred. That structure lets traders take real positions on the outcome without betting on the wrong branch. After a fixed window — **three days** in MetaDAO's current configuration — the protocol compares a manipulation-resistant [lagging TWAP](https://docs.metadao.fi/governance/twaps) (time-weighted average price, which caps how far the recorded price can jump per update) between the two markets. If the pass market's TWAP beats the fail market's by more than a set threshold, the proposal executes automatically; otherwise it dies. The threshold and window are governance-tunable parameters, not fixed law.

## Where it is being tried

Futarchy spent most of its life as a thought experiment — Hanson floated it, [Vitalik Buterin sketched a crypto version in 2014](https://blog.ethereum.org/2014/08/21/introduction-futarchy), and a handful of projects toyed with it — but until recently no organisation ran on it. MetaDAO changed that: launched in November 2023 with a tiny treasury, it governs **itself** by futarchy and has since run binding proposals for more than a dozen other organisations, making it the first DAO where market prices, not token votes, are the final word on every material decision. In 2026 the model reached a blue-chip DAO in advisory form: [GnosisDAO's GIP-145](https://gnosisdao.ghost.io/gnosisdao-governance-summary-february-2026/), a nine-month "advisory futarchy" pilot with Futarchy Labs, put a widget on Snapshot proposals showing the estimated percentage impact of a proposal on the GNO price, backed by $100,000 in temporary GNO/WETH liquidity to bootstrap the markets. It runs _alongside_ the existing [Snapshot vote](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) — a price signal voters may consult but are not bound to follow — a telling middle path for a DAO not yet ready to hand policy entirely to a market.

Gnosis was not the first DAO to wire a market to its ballot. [Futarchy Labs](https://futarchy.fi/), which built the pilot, states in [GIP-145 itself](https://forum.gnosis.io/t/gip-145-should-gnosis-dao-run-a-9-month-advisory-futarchy-pilot-with-100k-temporary-liquidity/11816) that GnosisDAO would be _joining_ Kleros and Velora, and the Kleros Cooperative confirmed in the same thread that it had already been running futarchy.fi for several months, as an advisory tool and as a safeguard on contentious proposals. Gnosis's claim is to be the first _large_ DAO to adopt one.

What the pilot buys is a signal, not a rule, and its specification is unusually precise about how weak a signal it is willing to call. The Snapshot widget shows the spot conditional prices in the pass and fail markets and the percentage difference between them; a five-day TWAP is computed when there is enough liquidity to support one, and a recommendation is issued only when the absolute impact exceeds **1%**. The $100,000 is a loan, not a grant — GNO and WETH sent to a 2-of-3 multisig, usable only for providing liquidity and returnable within the nine months. The conditional markets themselves run on Gnosis Chain through [Swapr](https://swapr.eth.limo/), built on the [Gnosis conditional-tokens contracts](https://github.com/gnosis/conditional-tokens-contracts) that also underpins Polymarket, and the resulting positions are composable with CowSwap.

The pilot also priced its own adoption. Before the Snapshot vote opened, Futarchy Labs ran a conditional market on GNO under approval versus rejection; over five days the pass market's TWAP sat about **2.5%** above the fail market's. The vote itself is the sharper artefact. With two days left the proposer was [publicly asking people to turn out](https://forum.gnosis.io/t/gip-145-should-gnosis-dao-run-a-9-month-advisory-futarchy-pilot-with-100k-temporary-liquidity/11816) because quorum had not been met, and it closed at [117,291 GNO for and 5.99 against](https://snapshot.box/#/s:gnosis.eth/proposal/0x09cb43353c0ece5544919bf70a9810908098c728f27f9ca3e211871f7ad6bf1c) — 117,562 in total against a 75,000 quorum, on 67 votes. A mechanism pitched partly as an answer to [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) needed a turnout appeal to authorise itself, against essentially no opposition at all.

## Strengths, and where it breaks

Futarchy's appeal is that it attacks two chronic DAO failures at once: [voter apathy](/wiki/dao-governance/concepts/voting/voting-and-delegation) (you no longer need a quorum of informed voters, only a few informed traders) and the fact that ordinary voting rewards neither conviction nor being right. Its failure modes are equally sharp. **Thin markets** price badly and are cheap to push, which is why liquidity-bootstrapping is the central engineering problem and why the model works best where the token is already liquid. **Metric gaming** is the deeper hazard: whatever proxy you choose, you get Goodhart's law — optimise hard for token price and you can reward decisions that pump the price while hollowing out the thing the price was meant to measure. Choosing _whose_ welfare the metric captures is itself an unresolved political question, not a market one. And a rich actor can, in principle, subsidise a market to steer a decision, betting that the value of controlling the outcome exceeds the trading loss — a live concern the [governance-attack](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) literature takes seriously. Futarchy does not remove politics from a DAO; it relocates it to the choice of metric and the design of the market.

The incentive objection is sharper than the mechanism-design one, and GnosisDAO's own delegates raised it before voting the pilot through. If a proposal's estimated price impact is well under a percent, a trader is asked to take liquidity risk, smart-contract risk and lock-up uncertainty for a fraction of a percent of upside — so who supplies the informed capital the model depends on? [Futarchy Labs' answer](https://forum.gnosis.io/t/gip-145-should-gnosis-dao-run-a-9-month-advisory-futarchy-pilot-with-100k-temporary-liquidity/11816) is that a thin margin is itself information — it means the proposal barely matters — and that on Kleros the absolute impact on contested proposals frequently traded above 4%. That answer concedes the shape of the problem: futarchy is informative exactly where a decision is already divisive, and quietest on the routine business that makes up most of a DAO's docket.

## How Caper approaches this

Caper and futarchy start from the same complaint — that one-block, capital-only voting aggregates the wrong signal — but answer it in opposite registers. Futarchy externalises the judgement to a market and lets price stand in for collective belief; a [caper](/wiki/foundations/what-is-a-caper) keeps the judgement with its members and instead changes _what a vote weighs_. Voting power on a Caper [proposal](/wiki/governance/proposals) is the canonical formula _w = (t · v) / (V · T)_, where _t_ is your governance-token balance and _v_ is your accumulated [participation](/wiki/governance/voting-mechanisms) — a soulbound record earned by showing up to vote, which cannot be bought in a block the way a market position can. That makes a large but disengaged holder structurally weaker than a long-standing contributor, without asking anyone to price the DAO's future in a conditional AMM. It also sidesteps futarchy's metric problem: there is no single proxy to game, because each proposal resolves to a definite executed outcome rather than to a market's verdict on a number. And because that same weight sets a member's pro-rata [exit share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), the incentive to accumulate participation honestly is built in — a different bet than futarchy's, that _who decides_ is easier to get right than _what to measure_.

## References

- [Robin Hanson, "Shall We Vote on Values, But Bet on Beliefs?"](https://mason.gmu.edu/~rhanson/futarchy.html) (2000). The original proposal.
- [Vitalik Buterin, "An Introduction to Futarchy"](https://blog.ethereum.org/2014/08/21/introduction-futarchy) (Ethereum Foundation blog, 2014). The first sketch of an on-chain version.
- [MetaDAO documentation — decision markets](https://docs.metadao.fi/governance/markets) and [TWAPs](https://docs.metadao.fi/governance/twaps). Conditional tokens, the liquidity split, and the lagging TWAP that settles a proposal.
- [GIP-145 forum thread](https://forum.gnosis.io/t/gip-145-should-gnosis-dao-run-a-9-month-advisory-futarchy-pilot-with-100k-temporary-liquidity/11816) (17 November 2025). The full pilot specification, the Kleros and Velora precedents, the delegate incentive objection, and the pre-vote conditional market on GNO.
- [GIP-145 Snapshot record](https://snapshot.box/#/s:gnosis.eth/proposal/0x09cb43353c0ece5544919bf70a9810908098c728f27f9ca3e211871f7ad6bf1c). Closed 14 February 2026 at 117,291 for / 5.99 against / 265 abstain against a 75,000 quorum.
- [Gnosis conditional-tokens contracts](https://github.com/gnosis/conditional-tokens-contracts). The settlement primitive the pilot's markets are built on.

## Governance timelocks

URL: https://caper.network/wiki/dao-governance/concepts/voting/governance-timelocks
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Topic** | The enforced delay between a governance proposal passing and its on-chain execution |
| **Core rule** | A passed proposal is _queued_, not run; it can only be executed after a fixed waiting period elapses |
| **Also called** | Governance timelock, execution delay, timelock controller, review window |
| **Solves** | Gives token holders and users a window to react, exit, or raise the alarm before a malicious or mistaken change takes effect |
| **Typical delay** | ~2 days on major protocols ([Compound](https://docs.compound.finance/v2/governance), [Uniswap](https://docs.uniswap.org/concepts/governance/overview)); minutes-to-days depending on stakes |
| **Key risk** | A delay short enough to be useless, or a privileged key that can bypass it entirely |
| **Canonical implementations** | [Compound Timelock](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol), [OpenZeppelin TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance) |

A **governance timelock** is an enforced waiting period between the moment a proposal passes and the moment it can actually run. Instead of a winning vote executing immediately, its calls are _queued_ in a timelock contract and become executable only after a fixed delay has elapsed. The pattern was popularised by [Compound's `Timelock.sol`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol) and is now a near-universal component of on-chain governance, standardised as the [OpenZeppelin `TimelockController`](https://docs.openzeppelin.com/contracts/5.x/api/governance). It is the safety valve that turns a governance vote from an instant, irreversible command into a change everyone can see coming.

## Why timelocks exist

On-chain governance concentrates enormous power in a passing vote: the ability to upgrade a contract, drain a treasury, or repoint an oracle. If that power executed the instant a vote closed, a single malicious proposal — or a governance attack that borrowed enough votes for one block — could act before anyone could respond. The timelock breaks that immediacy. Between the vote and the action there is a public, on-chain queue and a countdown.

That window does three things. It gives **users an exit**: anyone who disagrees with a queued change can withdraw funds or unwind positions before it lands. It gives the **community time to react** — to coordinate a counter-proposal, alert exchanges, or trigger an emergency pause. And it makes **vote-borrowing attacks far less profitable**, because an attacker who flash-borrows governance tokens to pass a proposal has long since had to return them by the time the timelock lets the proposal execute. OpenZeppelin frames the timelock as the mechanism that lets a project [protect users by making privileged actions publicly visible before they take effect](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks).

## Where it sits in the proposal lifecycle

The timelock is the step between approval and execution. In a typical Governor-plus-Timelock system the flow runs: propose → vote → _queue_ → **timelock delay** → execute (see the full [DAO proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle)). [Compound's timeline](https://docs.compound.finance/v2/governance) is the reference shape: a 3-day voting period, then a 2-day timelock before the queued calls can run, so any protocol change takes at least a week end to end.

Many implementations also add a **grace period** after the delay — a bounded window in which the proposal _must_ be executed or it expires — so stale, forgotten proposals cannot be actioned months later. The timelock is also the enabling primitive for [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance), where a queued proposal executes automatically once the delay passes _unless_ a veto arrives inside the window.

## Choosing the delay: the core tradeoff

Timelock length is a direct tradeoff between **safety and agility**. A longer delay gives users more time to exit and the community more time to catch a bad proposal, but it also slows every legitimate change — including urgent security fixes. A delay that is too short protects no one; a delay that is too long makes the protocol unable to respond to a live exploit.

Large protocols resolve this tension with a **two-track** design: a long timelock for ordinary governance, plus a small, fast-moving [multisig](/wiki/dao-governance/tooling/treasury/safe) — a [_security council_](/wiki/dao-governance/concepts/fundamentals/security-councils) — that can act inside a much shorter window for emergencies. [Arbitrum's constitution](https://docs.arbitrum.foundation/dao-constitution) pairs constitutional timelocks with a 12-of-12 Security Council that can fast-track patches, and [Optimism's Superchain](https://docs.optimism.io/superchain/privileged-roles) documents a similar set of privileged, time-bounded roles. The council's own power is itself a centralisation risk, which is why its membership, thresholds, and scope are usually the most-scrutinised part of a DAO's security model.

## In production

- **[Compound](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol)** — the original on-chain Governor + Timelock, with a 2-day execution delay and enforced minimum/maximum delay bounds. Its design was forked across DeFi.
- **[OpenZeppelin TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance)** — the audited, reusable standard most new DAOs deploy, with separate proposer, executor, and canceller roles and a configurable `minDelay`.
- **[Uniswap](https://docs.uniswap.org/concepts/governance/overview)** — a Governor Bravo derivative whose passed proposals queue into a timelock before execution.
- **[Arbitrum](https://docs.arbitrum.foundation/dao-constitution)** and **[Optimism](https://docs.optimism.io/superchain/privileged-roles)** — L2 DAOs that combine constitutional timelocks with an emergency Security Council. Queued actions are typically surfaced by governance dashboards such as [Tally](/wiki/dao-governance/tooling/voting/tally).

## Limits and failure modes

A timelock is only as strong as what it actually gates. Common failure modes include a **privileged admin key or upgradeable proxy** that can change contract logic _without_ passing through the timelock — a bypass that makes the visible delay theatre; an **executor or canceller role** concentrated in too few hands; and a delay set so short that no real user could act inside it. Timelocks also cannot stop a proposal that is malicious _and_ unnoticed — the window only helps if someone is watching, which is why the timelock is paired with monitoring, alerting, and an engaged electorate rather than trusted to work alone.

The window a timelock creates is the on-chain analogue of a broader principle: the value of the exit lies in being able to leave _before_ a decision binds you. See [rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), and — for the opposite end state, where a contract is made immutable so _nothing_ can be changed — [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization).

## How Caper approaches this

Caper builds an execution delay directly into its proposal machinery. Every proposal carries an execution window that opens when voting closes and stays open for a fixed _execution-delay period_ — a delay the protocol describes in its own source as the "timelock against vote-bombing." A winning option cannot settle instantly on the vote closing; it has to wait out that period first, so a proposal that only won because someone bought votes at the last moment does not get to act before that pressure unwinds.

Platform upgrades go further, using an explicit two-phase timelock: the passing $CAPER proposal first _proposes_ the new logic and starts the delay, and a second call only _activates_ it once the delay has elapsed — the same propose → timelock → activate shape this page describes, applied to the protocol's own code. See [Execution](/wiki/governance/execution) and [Proposals](/wiki/governance/proposals) for how the window fits into a Caper vote, and [What is a Caper](/wiki/foundations/what-is-a-caper) for the wider model.

## Holographic consensus

URL: https://caper.network/wiki/dao-governance/concepts/voting/holographic-consensus
Updated: 2026-07-25

|  |  |
| --- | --- |
| **Topic** | A governance layer that uses a parallel prediction market to decide _which_ proposals deserve the DAO's scarce attention |
| **Problem it names** | The "tyranny of the quorum" — as a DAO scales, no member can read every proposal, so either a high quorum stalls everything or a low quorum lets a small group pass anything |
| **Core mechanism** | Predictors stake a token ([GEN](https://medium.com/daostack/on-the-utility-of-the-gen-token-eb4f341d770e)) for or against each proposal passing; a proposal whose stake crosses a threshold is **boosted** and can pass on a relative majority instead of an absolute quorum |
| **Origin** | [Matan Field / DAOstack](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c), 2018 — implemented as the [Genesis Protocol](https://daostack.github.io/DAOstack-Hackers-Kit/stack/infra/genesisProtocol/) |
| **Status** | 🟠 Largely historical — DAOstack's Alchemy client and the GEN network wound down by 2021, but the design remains widely cited |
| **Related** | [Futarchy](/wiki/dao-governance/concepts/voting/futarchy) · [Conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) · [Optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance) · [Vote markets](/wiki/dao-governance/concepts/voting/vote-markets) |

**Holographic consensus** is a governance design that pairs an ordinary token or reputation vote with a [prediction market](https://en.wikipedia.org/wiki/Prediction_market) whose only job is to decide _what the DAO should look at_. Introduced by [Matan Field](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) for [DAOstack](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) in 2018, it was one of the first serious answers to a problem every large DAO eventually hits: there are far more proposals than any member can meaningfully evaluate, so collective attention — not capital — becomes the binding constraint. Where [futarchy](/wiki/dao-governance/concepts/voting/futarchy) bets on _outcomes_, holographic consensus bets on _votes_ — it forecasts which proposals the wider membership would ratify if it were paying attention, and surfaces those.

## The tyranny of the quorum

Every [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) DAO faces the same scaling dilemma. Set the [quorum](/wiki/dao-governance/concepts/voting/proposal-lifecycle) high and honest proposals die from apathy — most holders never vote, so nothing reaches the bar. Set it low and the DAO is captured: a small, coordinated group can pass anything while everyone else is looking away. Field called this the trade-off between **resilience** (the majority's will is respected) and **scalability** (decisions actually get made). Direct democracy is resilient but does not scale; delegation scales but concentrates power. The claim of holographic consensus is that a small, well-incentivised subset of the DAO can be made to _represent_ the whole — so the DAO passes proposals frequently and with confidence [without demanding high participation](https://medium.com/daostack/holographic-consensus-part-2-4fd461e8dcde). The name is the metaphor: like a hologram, each part carries an image of the whole.

## How the prediction market works

In DAOstack's [Genesis Protocol](https://daostack.github.io/DAOstack-Hackers-Kit/stack/infra/genesisProtocol/), every proposal opens with two ledgers running side by side:

- **The vote** — members spend non-transferable [reputation](/wiki/dao-governance/concepts/membership/soulbound-tokens) to vote for or against, exactly as in a normal DAO.
- **The prediction market** — anyone (member or not) stakes the transferable [GEN token](https://medium.com/daostack/joining-the-gen-predictors-network-f7be2d93754d) on whether the proposal will ultimately pass (an _upstake_) or fail (a _downstake_). Correct predictors are paid from the pool of the incorrect ones.

A proposal begins in a slow **regular** queue that requires an absolute majority of all reputation — deliberately hard to pass. But once its upstake crosses a threshold, the proposal is **boosted**: it moves to a faster track where it needs only a _relative_ majority (more reputation for than against) within a fixed window. Boosting is the whole trick — the prediction market, not a quorum, decides which proposals are worth the membership's limited attention, and staked money vouches that a boosted proposal genuinely reflects the DAO's will.

## Why anyone stakes: the DAOstake and GEN

The market only surfaces good proposals if predictors are paid to find them. Two design choices supplied the incentive. First, the DAO itself automatically [downstakes every proposal](https://medium.com/daostack/on-the-utility-of-the-gen-token-eb4f341d770e) — the "DAOstake" — betting a default sum that any given proposal will fail. That standing bounty is what outside predictors compete to win by upstaking proposals they judge will actually pass, so the network is paid to hunt for good proposals the DAO would otherwise miss. Second, [GEN](https://medium.com/daostack/on-the-utility-of-the-gen-token-eb4f341d770e) was a scarce, transferable token whose entire utility was this predicting role — a separate [token layer](/wiki/dao-governance/concepts/treasury/dao-tokenomics) from the reputation that actually cast votes. Splitting "attention" (tradable GEN) from "voice" (non-transferable reputation) is the structural signature of the design, and it distinguishes holographic consensus sharply from [vote markets](/wiki/dao-governance/concepts/voting/vote-markets), where the thing being bought _is_ the vote.

## What became of DAOstack

Holographic consensus shipped in production — the [Genesis DAO](https://daostack-1.gitbook.io/v1/introduction/holographic-consensus-overview/genesis-protocol) and the Alchemy interface ran real reputation-based DAOs, and the mechanism was later [studied academically](https://www.researchgate.net/publication/349156490_A_Scalable_Voting_System_Validation_of_Holographic_Consensus_in_DAOstack) as a scalable voting system. Its most prominent deployment was the [dxDAO](https://resources.cryptocompare.com/asset-management/964/1671705984746.pdf), which governed Gnosis-adjacent products. In practice, though, GEN's markets were thin, predicting was unintuitive to newcomers, and reputation-based membership never achieved wide adoption. DAOstack effectively wound the stack down around 2021, and later DAOs converged on simpler tools — [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) [Snapshot](https://snapshot.org) votes with [optimistic](/wiki/dao-governance/concepts/voting/optimistic-governance) execution — rather than a parallel prediction market. The protocol faded; the problem it named did not.

## The idea's afterlife

Holographic consensus is best read today as the concept that made "scaling collective attention" a first-class governance problem, and several live mechanisms are recognisable descendants. [Conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) replaces the discrete prediction market with a continuous signal — support that accrues weight over time — to surface what a community persistently wants without a formal quorum. [Optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance) flips the default the other way: proposals pass unless someone with skin in the game objects, so scarce attention is spent only on disputes. And [futarchy](/wiki/dao-governance/concepts/voting/futarchy) keeps the market but points it at outcomes rather than votes. Each trades away part of the original design, but all inherit its core bet — that a well-incentivised minority can stand in for a distracted whole. The unresolved question holographic consensus leaves behind is the one every [failed DAO](/wiki/dao-governance/concepts/analysis/how-daos-fail) rediscovers: an attention layer only works if the people steering it actually lose something when they steer wrong.

## How Caper approaches this

Caper doesn't run a separate prediction market to decide what's worth looking at — but it shares holographic consensus's premise that decision power should track engaged skin in the game, not passive size. In Caper, a member's [vote weight](/wiki/governance/voting-mechanisms) is the canonical product `w = (t · v) / (V · T)`: it multiplies how much you hold (`t`) by how much you have actually voted (`v`), normalised by the totals. A holder who never participates contributes `v = 0` and carries zero weight regardless of bag size — so a large position alone can't capture the outcome, and attention has to be spent to matter. Where DAOstack asked outsiders to _bet_ that a proposal reflects the group's will, Caper makes that alignment structural: the same holders who decide also bear the consequences, and the [exit right](/wiki/foundations/what-is-a-caper) is the backstop when surfacing fails — a member who thinks the active minority has steered wrong can redeem their share of the treasury and leave, rather than being bound by a decision they never had the attention to contest. Verified against Caper's contract source (`compute_vote_weight`), not marketing copy.

## Optimistic governance (veto-based approval)

URL: https://caper.network/wiki/dao-governance/concepts/voting/optimistic-governance
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | Governance in which proposals pass by default and can only be stopped by an explicit veto |
| **Core rule** | Silence counts as consent — a queued proposal executes automatically after a timelock unless enough tokens veto it inside the window |
| **Also called** | Veto-based governance, optimistic approval, negative-consent voting |
| **Solves** | Chronic voter fatigue and quorum failure in affirmative [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) |
| **Key risk** | A veto threshold set too high for real dissent to reach, or over-centralised proposer permission |
| **In production** | [Aragon Optimistic Token Voting plugin](https://github.com/aragon/optimistic-token-voting-plugin); [Zodiac Reality Module (SafeSnap)](https://github.com/gnosisguild/zodiac-module-reality); [Lido Dual Governance](https://blog.lido.fi/dual-governance-101-explainer/) (2025) |

**Optimistic governance** flips the default of a DAO vote. In ordinary [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) a proposal starts life rejected and must gather affirmative support to pass; in optimistic governance a proposal starts life _approved_ and executes on its own after a waiting period unless a threshold of token holders actively vetoes it first. The design borrows its name and its logic from optimistic rollups: assume the action is fine, and only require work from the people who think it is not. It is aimed squarely at the failure mode where a small, engaged proposer set is slowed to a halt by a large, disengaged electorate that will never reliably show up to click "yes".

## Why flip the default

Affirmative voting quietly assumes that a DAO can summon a quorum on demand. Most cannot. As token holders spread out and [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) thins, routine proposals — a grant, a parameter tweak, a contractor renewal — start failing not because anyone opposes them but because not enough wallets vote at all. Chronic low turnout and missed quorum are among the most common ways [DAOs stall](/wiki/dao-governance/concepts/analysis/how-daos-fail), and every unnecessary vote spends attention the DAO needs for the decisions that actually matter.

Optimistic governance treats participation as scarce and spends it only on disagreement. Uncontested business clears itself; the electorate is asked to act solely when it wants to stop something. In exchange for that efficiency the DAO accepts a real trade: an action nobody bothered to examine can still go live, so the safety of the whole scheme rests on the veto being genuinely reachable by anyone who would object.

## How a veto window works

An optimistic proposal moves through three stages. First, an address holding a specific proposer permission submits the action — that permission might sit with a council multisig, another governance plugin, or a plain wallet. Second, the proposal enters a timelock: a fixed window during which token holders can register a veto by locking or committing tokens against it. Third, if vetoes stay below the configured threshold when the window closes, the [execution](/wiki/governance/execution) becomes callable by anyone; if the threshold is crossed, the proposal is blocked.

Aragon's [Optimistic Token Voting](https://docs.aragon.org/token-voting/1.x) plugin is a clean reference implementation: only holders of `PROPOSER_PERMISSION_ID` may create proposals, and a proposal executes once its veto window has elapsed without a set fraction of the token supply objecting. The two dials that define the regime are the **veto ratio** (how much of the supply must object to kill a proposal) and the **minimum duration** (how long the window stays open) — set them wrong and the mechanism either rubber-stamps everything or never ships anything.

## Optimistic execution: the oracle route

A closely related pattern lets a DAO keep voting off-chain on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) while still executing trustlessly on-chain. The [Zodiac Reality Module](https://github.com/gnosisguild/zodiac-module-reality) (marketed to Snapshot users as [SafeSnap](https://docs.snapshot.box/v1-interface/plugins/safesnap-reality)) posts the outcome of an [off-chain vote](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) as a question to the [Reality.eth](https://reality.eth.limo/) escalation oracle. Anyone can assert that the linked proposal passed, backing the claim with a bond; the assertion is assumed correct unless it is challenged and escalated within the answer window.

Once the answer is final, a further **24-hour cooldown** elapses before the transaction batch becomes executable by anyone against the [Safe](/wiki/dao-governance/tooling/treasury/safe) treasury — a deliberate pause so that a wrong answer which slipped through can still be caught before it moves funds. It is optimistic in exactly the same sense: no on-chain vote tally is trusted directly, only a bonded claim that survived a challenge period. The same escrow-and-challenge shape underpins the [attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) to watch — the security of the outcome is only as good as the incentive to dispute a lie.

The other implementation of this route no longer exists. UMA's **oSnap** – the Optimistic Governor module paired with a Snapshot front end, and the bridge most DAO documentation still points at – was retired on **15 December 2025**. UMA's notice is unambiguous: after that date ["oSnap will not be able to execute transactions from your DAO's Safe treasury"](https://docs.uma.xyz/resources/osnap), and integrators were told to disable the module on every treasury still carrying it. The kill switch sits one layer below the module, in the oracle: the `ASSERT_TRUTH` identifier every oSnap assertion resolved against was [deprecated in the same week](https://docs.uma.xyz/developers/optimistic-oracle-v3/assert_truth-deprecation) in favour of `ASSERT_TRUTH2` — identical specifications, UMA says, the change existing only "to break support for deprecated projects". The Reality.eth route described above is unaffected and [Snapshot still documents it](https://docs.snapshot.box/v1-interface/plugins/safesnap-reality). A DAO whose constitution names oSnap as its execution path has, since that date, been back to trusting its signers.

## Two questions that separate optimistic systems

Every optimistic design has the same silhouette – default pass, bonded objection, challenge window – and two differences decide how much protection the window actually buys. Neither is the veto threshold, which is where comparisons usually start and stop.

**Where the validity check lives.** oSnap kept a space's rules as a plain text string in the Safe module's settings. A disputer was shown ["the oSnap rules that the request should be reviewed against (including minimum quorum and voting period for the Snapshot proposal)"](https://docs.uma.xyz/resources/osnap/osnap-proposal-verification) and had to judge, by reading, whether the proposal met them: quorum counted FOR + AGAINST + ABSTAIN against the space's floor, and passage required a FOR share above half of that same total. No contract knew any of it, so the check was re-made from scratch on every request by whoever happened to be watching. Aragon's plugin pins the equivalent parameters on-chain instead — [`OptimisticGovernanceSettings`](https://github.com/aragon/optimistic-token-voting-plugin/blob/main/src/OptimisticTokenVotingPlugin.sol) holds `minVetoRatio`, `minDuration` and `minProposerVotingPower`, and `canExecute` resolves the routine case by calling `isMinVetoRatioReached`. A rules string is far more expressive; it can encode conditions no contract could check. That expressiveness is exactly what has to be re-litigated, unpaid, every single time.

**What the dispute layer is allowed to say.** The narrow version of a challenge is "the tally is wrong". Wider outcome sets are a materially different power. [Reality.eth](https://reality.eth.limo/app/docs/html/contracts.html) reserves two answers outside the ordinary answer space — `0xff…ff` for _invalid_ and `0xff…fe` for _answered too soon_ — so a bonded challenger can argue not that the answer is wrong but that the question should never settle at all, or not yet. oSnap pushed the same idea to its limit in the other direction: a disputed request ["can not be executed no matter how UMA resolves the dispute"](https://docs.uma.xyz/resources/osnap/osnap-proposal-verification). The challenge was terminal, and a DAO that won its dispute still had to propose again from the start. That gap matters more than the threshold in front of it: a low bar guarding a layer that can only correct arithmetic is weaker protection than a high bar guarding one that can void the question.

## Milestone escrow: optimistic settlement for proposals that have deliveries

A veto window fits a decision that happens once. Much of what a treasury funds does not. A grant is approved as a lump and then paid against work arriving over months, and the DAO has no natural place to object to the third tranche short of re-running governance. UMA's [Insurance](https://docs.uma.xyz/developers/optimistic-oracle-v3/in-depth-tutorial-insurance) reference contract, written as an Optimistic Oracle V3 tutorial rather than a governance tool, is the shape that fits. Funds are locked at issuance against a described event and a named beneficiary. Anyone may request payout at any time; the request posts a bonded assertion that the event has occurred, and if that assertion survives its window [the contract pays the beneficiary automatically](https://github.com/UMAprotocol/dev-quickstart-oov3/blob/master/src/Insurance.sol). A rejected request does not close the policy: it stays live, there is no cap on attempts, and only the first truthfully resolved request settles the money.

Substitute "milestone delivered" for "insured event" and that is tranche release. The DAO votes once on the grant, the funds sit in escrow, and each release becomes its own assertable, disputable claim — so members are asked to act only when they believe a milestone was not met. It is the same economy of attention the veto window is reaching for, applied to the part of a treasury's work that has deliveries rather than a single moment of consent. The non-optimistic version of the same problem is [standing authorizations and delegated mandates](/wiki/dao-governance/concepts/treasury/standing-authorizations); where escrowed grants sit in the wider picture is [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management). One trap for anyone building from that tutorial: its constructor reads `oo.defaultIdentifier()`, which still returns the deprecated `ASSERT_TRUTH`, and `assertTruthWithDefaults` now always reverts.

## In production

Beyond Aragon's plugin, the most consequential live example is [Lido](/wiki/daos/staking/lido-dao)'s [Dual Governance](https://blog.lido.fi/dual-governance-101-explainer/), enabled in 2025. It inserts a dynamic timelock between the LDO-holder DAO's decisions and their execution, and hands stETH holders a veto they exercise by locking stETH into an escrow. Once locked stake crosses a **first seal at 1% of Lido-on-Ethereum TVL**, the timelock starts to grow — from five extra days at 1% up to a maximum of 45 days at 10% — buying time for the DAO to reconsider. Crossing a **second seal at 10% of TVL** triggers _rage quit_: execution is fully blocked until every objecting holder has withdrawn.

Lido is worth studying because it fuses the two escape valves DAOs usually treat separately — a graduated veto _and_ a [rage-quit exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Dissenters do not merely delay a decision; if they are numerous enough they can leave rather than be bound by it. That pairing — object, and if objection is not enough, exit — is the sharpest version of what optimistic governance is reaching for.

Lido runs a second, quieter optimistic mechanism in the opposite direction. Where Dual Governance gives holders a veto over the DAO, [Easy Track](https://docs.lido.fi/guides/easy-track-guide/) gives named committees a right to act _without_ the DAO: a motion enacts after 72 hours unless holders of 0.5% of LDO object, and `enactMotion` carries no role gate, so anyone may execute a passed motion. The veto window is the same shape; what is being waved through is a class of recurring spending rather than one decision. See [standing authorizations and delegated mandates](/wiki/dao-governance/concepts/treasury/standing-authorizations).

## Trade-offs and criticisms

The central objection is that **silence is not consent**. Optimistic governance reads a non-response as approval, but a non-response can equally mean a holder never saw the proposal, could not decode its calldata, or lacked the tokens to matter. If the veto threshold is set higher than a diffuse, part-time electorate can realistically coordinate to reach, the safety valve is decorative and the proposer set governs unchecked. Set it too low and a small, motivated minority can grief the DAO by vetoing routine business — a mirror of the [capture and gridlock](/wiki/dao-governance/concepts/analysis/how-daos-fail) the design was meant to escape.

The other tension is **who holds proposer permission**. Optimistic schemes trade broad affirmative participation for a trusted party that drafts and queues actions, so the honesty of that party — a council, a core team, a multisig — becomes load-bearing. That is a reasonable bargain for an established protocol with a credible team and an engaged token base able to veto, and a poor one for a young, thinly-distributed DAO where the "veto" nobody can reach is just a rubber stamp with extra steps.

A third tension only shows up once a DAO has a [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures). A wrapper's controls are _ex ante_ — signer sets, thresholds, a duty to refuse unlawful execution — while an optimistic default treats a proposal as authorised because nobody objected in time. Both DAO-LLC statutes rank the smart contract above the paperwork it conflicts with, so the two layers can reach different answers about whether a treasury outflow was ever authorised at all; the drafting responses are set out under [when the wrapper and the code disagree](/wiki/dao-governance/concepts/membership/dao-legal-structures).

## How Caper approaches this

Optimistic governance answers "a decision I object to is about to pass" with a collective veto window, and Lido shows the strongest form of it pairs that veto with an exit. A [caper](/wiki/foundations/what-is-a-caper) leans entirely on the exit side and makes it individual rather than collective. Instead of asking dissenters to coordinate enough tokens to clear a veto threshold in time, every caper gives any holder a priced way out at any moment: calling `exit` redeems a share of the treasury equal to that member's canonical vote weight — their token holdings multiplied by the share of votes they actually cast, _(t·v)/(V·T)_ — while burning the soulbound proof-of-vote tokens the share is computed from.

So where optimistic governance says "you are bound unless enough of you together veto in time," a caper says "if a decision goes against you, leave with your proportional slice of what the treasury holds." There is no coordination threshold to reach and no window to miss; the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is always open, and its price is set by the [bonding curve](/wiki/markets/bonding-curve) the caper was funded on. It is a different bet than a veto — that a credible, always-available exit disciplines a treasury more reliably than a veto most holders can never quite muster. The argument in full is in [The Exit Right](/blog/the-exit-right).

## Private and shielded voting

URL: https://caper.network/wiki/dao-governance/concepts/voting/private-and-shielded-voting
Updated: 2026-07-30

| Concept | Private and shielded voting |
| --- | --- |
| Also called | Secret ballots, shielded voting, private voting, anti-collusion voting |
| Category | Voting mechanisms & ballot design |
| Core idea | Hide some part of a vote – the running tally, the individual choice, or the voter’s identity – so that later voters, bribers and coercers cannot act on information the ballot would otherwise leak |
| Three distinct properties | Running-tally privacy · receipt-freeness · voter anonymity. Most deployed systems provide only the first. |
| Production implementation | [Snapshot shielded voting](https://docs.snapshot.box/user-guides/spaces/settings), threshold encryption by [Shutter Network](https://docs.shutter.network/docs/protocol/overview) |
| Research implementations | [MACI](https://maci.pse.dev/docs/introduction) (zk-SNARK, receipt-free) · [Cicada](https://github.com/a16z/cicada) (homomorphic time-lock puzzles, no coordinator) |
| Measured adoption | Shielded in 81 of 1,597 recent proposals across 19 flagship [Snapshot](https://docs.snapshot.box/tools/api) spaces – and concentrated almost entirely in **elections** |
| Central tension | Ballot secrecy versus the delegate accountability and live auditability that on-chain governance was built for |

Every vote cast in a typical DAO is public the moment it lands: the address, the choice, the weight, and the running tally are all readable by anyone, live, for the whole voting period. That is the opposite of how almost every political democracy runs an election, and it is not an oversight – it is what makes [on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) auditable. **Private voting** is the family of mechanisms that give some of that transparency back in exchange for a property a public ledger cannot otherwise offer: a voter who cannot be watched, followed, or paid.

The term covers three different guarantees that are routinely collapsed into one, and the difference decides which problem a given system actually solves.

## Three properties, usually confused

- **Running-tally privacy.** Nobody – including the voters – can see the intermediate result while voting is open. Everything is revealed at close. This defeats the bandwagon effect, discouragement of the trailing side, and last-minute strategic voting by large delegates. It does _not_ hide who voted for what afterwards.
- **Receipt-freeness.** A voter cannot prove to a third party how they voted, even if they want to. This is the property that defeats bribery and coercion, because a briber cannot verify what they bought. It is strictly harder than running-tally privacy and requires the voter to be able to lie convincingly about their own ballot.
- **Voter anonymity.** The link between a voter and their ballot is never revealed, at any point. This is the classic secret ballot, and it is the hardest of the three on a public ledger where eligibility itself must be proven from a token balance or a membership record.

The point of separating them: the only widely-deployed system in DAO governance today provides the first and neither of the others. When Shutter’s own team was asked directly in Aave’s forum whether shielded voting stopped bribery, the answer was blunt – [it “doesn’t prevent bribery or enhance individual voters privacy”](https://governance.aave.com/t/arfc-private-voting-for-aave-governance-2-month-trial/12730/17). Treating running-tally privacy as a defence against [vote markets](/wiki/dao-governance/concepts/voting/vote-markets) is a category error.

## Shielded voting: threshold encryption in production

[Snapshot](/wiki/dao-governance/tooling/voting/snapshot) ships one privacy option, and it is a space setting rather than a protocol change. Snapshot’s own documentation describes it plainly: shielded voting is [“powered by Shutter, it uses threshold encryption so that voters’ choices are private during the voting period and revealed when the proposal closes”](https://docs.snapshot.box/user-guides/spaces/settings). A space admin selects `Shutter` from a Privacy dropdown on the Voting tab; individual proposals inherit or override it.

The cryptography sits with [Shutter Network](https://www.shutter.network/), a threshold-encryption protocol better known for encrypted mempools and MEV protection. A set of nodes called **Keypers** run a distributed key generation ceremony; ballots are encrypted to the resulting public key, and the ciphertext can only be opened once a threshold of Keypers releases their shares – which, for governance, happens when the proposal closes ([Shutter protocol overview](https://docs.shutter.network/docs/protocol/overview)). No single party can open a ballot early, but the Keyper set collectively can, so the guarantee is a threshold-honest-majority assumption rather than a cryptographic impossibility.

What a DAO gives up is smaller than it sounds and larger than it looks. Ballots are decrypted and published in full at close, so voting records stay auditable and delegates remain accountable for how they voted. But Snapshot [does not allow a written reason on a shielded vote](https://docs.snapshot.box/faq), which removes the single most useful artefact of the [deliberation stage](/wiki/dao-governance/concepts/voting/proposal-lifecycle): the delegate rationale posted alongside the ballot.

## What the adoption record actually shows

Claims about private voting in DAOs are usually made in the abstract. They are cheap to check: Snapshot’s [public GraphQL hub](https://docs.snapshot.box/tools/api) (`hub.snapshot.org/graphql`) exposes a `privacy` field on every proposal and on every space’s voting settings. Sampling the most recent 100 proposals (or all of them, where a space has fewer) across 19 flagship spaces – 1,597 proposals in total – shielded voting appears in exactly three places:

| Space | Shielded / sampled | Space default |
| --- | --- | --- |
| Shutter DAO 0x36 | 65 / 65 | `shutter` |
| [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao) | 14 / 100 | `any` |
| [ENS](/wiki/daos/infrastructure/ens-dao) | 2 / 98 | `any` |
| [Uniswap](/wiki/daos/dexs/uniswap-dao), [Aave](/wiki/daos/lending/aave-dao), Lido, [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), SafeDAO, Balancer, Curve, Optimism, ApeCoin, Starknet, Stargate, PancakeSwap, The Sandbox, Aura, Decentraland, Nouns | 0 / 1,334 | unset |

One of the three builds the technology. Of the other two, the pattern is unmistakable once the titles are read: Arbitrum’s shielded proposals are overwhelmingly **elections** – the ARDC V2 Security, Risk, Research and Supervisory Council seats (Dec 2024), all four Season 3 D.A.O. category elections (Jan 2025), the OpCo Oversight and Transparency Committee elections (Mar 2025 and Jul 2026), the Audit Committee technical-expert election (Jun 2025) and the AGV 2026 council elections. ENS’s two are its Term 7 Meta-Governance Working Group election and the [election of its new DAO Security Council](https://snapshot.box/#/s:ens.eth) (Jul 2026), both run under ENS’s Copeland ranked method.

Arbitrum reached that position by voting on it. In August 2024 Entropy Advisors put a temperature check to the DAO asking whether it should default to shielded voting; [3,603 voters returned no majority for anything](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x24188af307bee6ce66d10394d03d501746b343a686d64806ee71954e317ed382): **Against** led on 69.2M votes (42.6%), **For Elections Only** took 59.6M (36.7%), **For all Snapshot Votes** 32.6M (20.0%), abstain 1.2M. Two years later the DAO’s revealed practice matches the runner-up option almost exactly.

## The turnout evidence cuts the other way

The standard case for shielded voting is that it reduces [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) – if a minority-opinion holder cannot see they are losing, they still vote. Aave ran the only two-month controlled trial anyone has published, and the numbers went the wrong way. LBS Blockchain Society, Michigan Blockchain and Flipside Crypto proposed it in April 2023, the DAO passed it, and Marc Zeller [enabled the privacy option on 5 May 2023](https://governance.aave.com/t/arfc-private-voting-for-aave-governance-2-month-trial/12730/24). The [retrospective posted on 18 July 2023](https://governance.aave.com/t/arfc-private-voting-for-aave-governance-2-month-trial/12730/31) compared like for like:

| Period | Total votes | Unique voters | Proposals | YAE:NAE |
| --- | --- | --- | --- | --- |
| Mar – May 2023 (public) | 879.9k | 32.6k | 65 | 73% |
| May – Jul 2023 (shielded) | 119k | 14.2k | 59 | 85.4% |

The author’s reading was that “these numbers suggest there is more general participation without private voting,” with the caveat that much of the raw volume was airdrop-farming dust rather than considered voting. The qualitative notes were mixed in a more interesting way: shielding “forces you to form and define a clear opinion, not just defer to the largest / most passionate voter,” but it made outcomes impossible to anticipate, so the operational work that normally begins before a vote closes had to wait – and the space needed active admin management to keep features like the quorum display coherent. Aave never made it permanent. Its Snapshot space carries no privacy setting today, and none of its last 100 proposals were shielded.

Arbitrum’s own proposal was unusually honest about the second-order effect: hiding the tally does not remove information asymmetry, it privatises it. “Politically savvy parties who have the ability or connections to coordinate now have an even bigger advantage,” and delegates who publicly announce their position gain leverage over a silent opposition. Shielded voting moves the tally from a public dashboard into a backchannel, and only the well-connected have the backchannel.

## Receipt-freeness: MACI

**MACI** (Minimal Anti-Collusion Infrastructure) is the serious attempt at the harder property. Originally an [Ethereum research proposal](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) and now maintained by [Privacy & Scaling Explorations](https://github.com/privacy-ethereum/maci), it uses encryption plus zk-SNARKs to hide individual ballots while proving the published tally is correct. Its stated purpose is not privacy for its own sake but [collusion resistance](https://maci.pse.dev/docs/introduction): because a voter cannot prove which option they chose, a briber cannot verify delivery, and the bribe loses its enforcement.

The mechanism that buys receipt-freeness is a **key-change message**. A voter identified by a MACI keypair can submit a message re-keying their identity, and the coordinator processes all messages [in reverse order](https://maci.pse.dev/docs/core-concepts/key-change). That ordering is deliberate: if a briber has a voter re-key to a briber-controlled key and then votes with it, reverse processing means the voter’s own later message is counted and the briber’s is not. The briber can never be sure which of a voter’s messages survived.

The cost is a trusted party. MACI’s docs say so directly: once voting closes [“the coordinator has the sole ability to decrypt all user votes”](https://maci.pse.dev/docs/core-concepts/workflow). A corrupt coordinator can decrypt ballots (to publish them, or to bribe individual voters) and can halt a round by never producing the proofs; what they cannot do is publish a wrong result, because the tally is proved in zero knowledge. The circuits are Groth16 in circom and the [trusted setup is optional](https://maci.pse.dev/docs/security/trusted-setup) – teams may skip a ceremony, since “MACI’s security model presumes a trusted coordinator” regardless. The v3.0 ceremony artefacts also show the scale ceiling honestly: the small-batch set supports 16,384 users and 125 vote options per poll.

MACI is alive as software – [v3.0.0 shipped in June 2026](https://github.com/privacy-ethereum/maci/releases), with commits through July 2026 – but its deployment record is not DAO governance. Its [case studies](https://maci.pse.dev/docs/case-studies) are [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) rounds at conferences (ETH Mexico, Devcon SEA, ETH Argentina, ETHCon Korea and similar), ending in 2024. [clr.fund](https://github.com/clrfund/monorepo), the flagship MACI application, has had no commits since August 2024. No major treasury DAO runs its binding votes through MACI.

## Removing the trusted party: time-lock puzzles

The obvious objection to both approaches is that they replace a public tally with a trusted set – Keypers in one case, a coordinator in the other. [Cicada](https://github.com/a16z/cicada), a16z crypto’s research implementation, is the attempt to delete that party entirely using [homomorphic time-lock puzzles](https://eprint.iacr.org/2019/635).

A time-lock puzzle hides a secret behind a fixed number of _non-parallelisable_ sequential computations, so it can only be opened after real elapsed work, by anyone. Cicada’s README states the property this buys: time-lock puzzles “achieve running-tally privacy without relying on tallying authorities, threshold encryption or any other trusted parties.” Because the puzzles are linearly homomorphic, individual encrypted ballots can be summed into a single puzzle encoding the final tally, so one solve reveals the result rather than one solve per voter. The implementation swaps the source paper’s Paillier encryption for exponential ElGamal to keep on-chain ballot verification affordable, at the price of a tally that must be small enough to brute-force a discrete log – practically under 232.

Cicada gets running-tally privacy with no trusted party and no anonymity: it is unaudited research, last touched in January 2025, and no DAO governs with it. It is worth knowing because it marks the frontier – the property production systems ship is achievable without a Keyper set, and the properties DAOs actually want are not.

## What ballot privacy costs a DAO

- **Live auditability.** A public tally lets anyone spot a whale swinging a vote while there is still time to respond. Shielded voting defers that to after the close, which as one Aave delegate put it means collusion surfaces “only when it’s too late.”
- **Delegate accountability.** A delegate is an elected representative whose voting record is the whole basis of re-delegation (see [voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation)). Shielded voting survives this test only because it reveals at close; a genuinely anonymous DAO ballot would not.
- **Execution is still public.** All of this applies to off-chain signalling. The binding on-chain vote that follows – a Governor call, a timelocked upgrade – is executed in the clear, so privacy covers only the first half of the [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle).
- **Operational drag.** Quorum displays, vote reasons and outcome-anticipation all break or degrade, and the space needs more active administration.
- **It does not touch the money.** Bribe markets settle on a proof the ballot was cast a particular way. Shielded voting leaves that proof intact after the reveal; only receipt-freeness removes it, and no DAO runs receipt-free voting at scale.

The place the tradeoff clearly favours privacy is exactly where the evidence says DAOs use it: **elections**. Choosing between named human candidates is where coercion, reputational retaliation and bandwagon dynamics are strongest, where the tally is inherently zero-sum between people who have to keep working together afterwards, and where the accountability argument for a public record is weakest – nobody needs to audit which delegate preferred which candidate for a [security council](/wiki/dao-governance/concepts/fundamentals/security-councils) seat. For parameter votes and treasury spending, the same DAOs keep the ballots public.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) sits on the transparent side of this tradeoff deliberately, and it is worth stating plainly rather than implying otherwise. Voting is a single on-chain call: the ballot is a full ranking of every option, encoded and appended to the proposal’s ballot store together with the account that cast it, and the state tier exposes reading those ballots as a public method. There is no encryption stage, no reveal stage, and no coordinator. The choice, the caster and the running count are all readable while voting is open, and casting a vote mints the voter a vote token, so participation itself is visible on-ledger too.

What a caper does instead is attack the underlying incentive rather than the information. The bandwagon and apathy problems that shielded voting targets are downstream of votes being costless and weightless – a holder with a large bag and no participation still carries the day. In a caper, a member’s weight is the product of the governance tokens they hold and the vote tokens they have accumulated, each normalised by its own total ([voting mechanisms](/wiki/governance/voting-mechanisms)), so a bag alone cannot capture a decision without a record of showing up. The same quantity sets what a member can withdraw when they [exit](/blog/the-exit-right), which makes voting a claim on the treasury rather than unpaid homework.

That is a different answer to the same problem, not a privacy feature, and it comes with the honest cost: a caper offers no ballot secrecy at all. A DAO whose primary risk is voter coercion – a contested election among people who must keep collaborating – is describing a problem a caper does not solve.

## References

- Snapshot, [Space settings – shielded voting](https://docs.snapshot.box/user-guides/spaces/settings) and [FAQ](https://docs.snapshot.box/faq) (no vote reason on shielded proposals).
- Snapshot, [Hub GraphQL API](https://docs.snapshot.box/tools/api) – the `privacy` field on `Proposal` and `SpaceVoting`, source of the adoption figures above (sampled 30 July 2026).
- Shutter Network, [Protocol overview](https://docs.shutter.network/docs/protocol/overview) (Keypers, distributed key generation, threshold decryption).
- Arbitrum DAO, [Should the DAO Default to using Shielded Voting for Snapshot Votes?](https://snapshot.box/#/s:arbitrumfoundation.eth/proposal/0x24188af307bee6ce66d10394d03d501746b343a686d64806ee71954e317ed382) (Aug 2024 temperature check, full result and rationale).
- Aave governance, [[ARFC] Private Voting for Aave Governance [2-month Trial]](https://governance.aave.com/t/arfc-private-voting-for-aave-governance-2-month-trial/12730) – proposal, Shutter’s own caveats (post 17), and the [results retrospective](https://governance.aave.com/t/arfc-private-voting-for-aave-governance-2-month-trial/12730/31) (post 31).
- Privacy & Scaling Explorations, [MACI documentation](https://maci.pse.dev/docs/introduction) – [workflow and coordinator trust assumptions](https://maci.pse.dev/docs/core-concepts/workflow), [key change](https://maci.pse.dev/docs/core-concepts/key-change), [trusted setup](https://maci.pse.dev/docs/security/trusted-setup), [case studies](https://maci.pse.dev/docs/case-studies).
- a16z crypto, [Cicada](https://github.com/a16z/cicada) and [Building Cicada: private on-chain voting using time-lock puzzles](https://a16zcrypto.com/posts/article/building-cicada-private-on-chain-voting-using-time-lock-puzzles/).
- Malavolta and Thyagarajan, [Homomorphic Time-Lock Puzzles and Applications](https://eprint.iacr.org/2019/635) (2019).
- Rivest, Shamir and Wagner, [Time-lock puzzles and timed-release crypto](https://people.csail.mit.edu/rivest/pubs/RSW96.pdf) (1996).

## Proposal throttles and governance rate limits

URL: https://caper.network/wiki/dao-governance/concepts/voting/proposal-throttles-and-rate-limits
Updated: 2026-08-12

| Concept | Proposal throttles — the rules that bound _how many_ proposals can reach a vote, _who_ may open one, and _what it costs_ |
| --- | --- |
| Problem addressed | Governance spam, voter fatigue, and griefing a treasury through the cost of processing proposals |
| Common mechanisms | Sponsor thresholds · proposal deposits and offerings · concurrency caps · action and payload caps · expirations · retroactive cancellation |
| Reference implementations | [Compound Governor Bravo](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) · [Moloch v2](https://github.com/MolochVentures/moloch/blob/master/contracts/Moloch.sol) · [Baal](https://github.com/HausDAO/Baal/blob/main/contracts/Baal.sol) (DAOhaus v3) |
| Key trade-off | Every throttle that stops spam also raises the floor on who can govern |

## 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](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design), [token weighting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [quadratic schemes](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding). 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](/wiki/dao-governance/concepts/voting/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](/wiki/dao-governance/concepts/voting/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](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) — 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](/wiki/dao-governance/concepts/voting/voting-power-activation) for how that floor interacts with delegation.

The Moloch lineage draws the line at membership rather than magnitude. In [Moloch v2](https://github.com/MolochVentures/moloch/blob/master/contracts/Moloch.sol) 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](https://github.com/HausDAO/Baal/blob/main/contracts/Baal.sol), 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](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x7cefbd56122cb21bc08a8aba952d35c31bc800a9e2f0e31c55d0ffc42e0d483e), 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](https://github.com/HausDAO/moloch-skills/blob/main/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](/wiki/dao-governance/concepts/voting/typed-vs-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](/wiki/dao-governance/concepts/voting/governance-timelocks) address from the other end.

## 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](/wiki/foundations/what-is-a-caper) carries four throttles, and the interesting one is a fee that is explicitly not an anti-spam price.

Opening a [proposal](/wiki/governance/proposals) requires an exact XRD payment equal to the caper's `proposal_fee`, 500 XRD by default — _exact_, so an over-payment aborts rather than tipping the treasury — and there is no refund path: the payment is banked by the caper it was proposed to. The fee has a floor written into the fee-setting function itself, `proposal_fee >= SETTLEMENT_GAS_BUDGET`, with the reason stated in the source: so that "the permissionless settle path can never draw more treasury than the proposal itself banked." That is Moloch's `require(_proposalDeposit >= _processingReward)` invariant reached independently — a proposal must pre-fund the work of concluding it — and it means the fee's size is derived from settlement cost rather than chosen to deter.

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.

## Quadratic voting and funding

URL: https://caper.network/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | Concave voting & matched public-goods funding that weights breadth over wealth |
| **Quadratic voting (QV)** | Cost of votes = (votes)² — so influence grows with the _square root_ of money spent |
| **Quadratic funding (QF)** | A project's match ∝ (Σ√contributions)² — the number of backers matters more than their size |
| **Proposed by** | Lalley & Weyl (QV, 2018); Buterin, Hitzig & Weyl (QF, 2018) |
| **Hard dependency** | [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) — an identity layer |
| **Flagship deployment** | [Gitcoin Grants](/wiki/daos/public-goods/gitcoin-dao) (QF); Colorado State Legislature (QV) |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Gitcoin (DeSci)](/wiki/desci/ecosystem/gitcoin-desci) |

**Quadratic voting** (QV) and **quadratic funding** (QF) are a pair of [mechanism-design](/wiki/economics/mechanism-design) constructions built to fix the central defect of [one-token-one-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting): that it collapses into _one-dollar-one-vote_, letting a handful of large holders decide everything. Both work by making influence **concave** in money — each additional unit of voting power costs quadratically more than the last, so a voter's effective say grows only with the _square root_ of what they spend. The intent is a middle path between plain majority rule, which ignores how strongly anyone cares, and [plutocratic](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) weighted voting, which lets the richest participant simply buy the outcome.

The catch — and the reason QV/QF remains niche in on-chain [DAO governance](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) despite its elegance — is that it only works if you can stop one person from posing as many. That makes it entirely dependent on an [identity layer](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos), the hardest unsolved problem in permissionless governance.

## The core idea: a quadratic price for influence

Under quadratic voting, a participant is given a budget of _voice credits_ and may buy as many votes on an issue as they like — but the cost is the **square** of the number of votes. One vote costs 1 credit, two votes cost 4, three cost 9, ten cost 100. The formalization is due to Steven Lalley and Glen Weyl in ["Quadratic Voting: How Mechanism Design Can Radicalize Democracy"](https://www.aeaweb.org/articles?id=10.1257/pandp.20181002) (2018), building on the argument in Eric Posner and Glen Weyl's book _Radical Markets_.

Why square the cost? Because it makes the _marginal_ cost of each additional vote grow linearly, and under standard assumptions that aligns each voter's spending with the true intensity of their preference: someone who cares twice as much will rationally buy twice as many votes, not four times as many. The result is a rule that captures **how much** people care, not just **which side** they are on — while still charging steeply enough that no single deep-pocketed actor can dominate. A voter with 100× the credits of another ends up with only 10× the votes.

## Quadratic funding: QV applied to public goods

**Quadratic funding** generalizes the same square-root logic to allocating a shared matching pool across many projects. Introduced by Vitalik Buterin, Zoë Hitzig and Glen Weyl in ["A Flexible Design for Funding Public Goods"](https://arxiv.org/abs/1809.06421) (2018, published in _Management Science_), the mechanism sets each project's total funding proportional to the **square of the sum of the square roots** of its individual contributions:

_match ∝ ( Σ √ci )²_

The consequence is that **the number of contributors matters far more than the size of any one contribution**. A project funded by 100 people giving $1 each receives a much larger match than one funded by a single $100 donor, because 100 × √1 = 100, whereas √100 = 10. QF therefore surfaces what a _community_ broadly wants rather than what its wealthiest member wants — the theoretically optimal way to fund public goods when contributions are voluntary. [RadicalxChange](https://www.radicalxchange.org/wiki/plural-funding/) calls the family of designs "plural funding."

## The Achilles' heel: identity and collusion

Concave voting only rewards breadth if each "person" really is one person. The moment an actor can split a large holding across many wallets, the defense inverts: a whale who divides $100 into a hundred $1 identities is treated as a hundred small, independent backers and reaps the full breadth bonus. This is the classic [Sybil attack](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos), and it is fatal to a naïve implementation.

QF is also acutely vulnerable to **collusion**: two colluding donors (or two fake accounts owned by one person) can each contribute their full balance to the same grants and extract an outsized match. Buterin's own [review of Gitcoin's early rounds](https://vitalik.eth.limo/general/2019/10/24/gitcoin.html) introduced the standard patch — **pairwise-bounded QF**, which caps the matching any single _pair_ of contributors can trigger and discounts groups that donate to the same cluster of grants, penalizing coordinated behaviour while preserving the breadth signal from genuinely independent backers. Even so, every real deployment leans on some identity or proof-of-personhood layer, and none of them is watertight.

## Where it is used

**[Gitcoin Grants](/wiki/daos/public-goods/gitcoin-dao)** is the flagship QF deployment — it has channeled well over $60M into open-source and public-goods projects across dozens of matching rounds, and remains the reference implementation of pairwise-bounded QF at scale (see [Gitcoin's own explainer](https://gitcoin.co/mechanisms/quadratic-funding) and its [DeSci rounds](/wiki/desci/ecosystem/gitcoin-desci)). Beyond crypto, the **Colorado State Legislature** ran the highest-profile QV pilot: in 2019 the Democratic caucus used quadratic voting to prioritize dozens of competing appropriations bills, producing a clearer signal of intensity than a show of hands could ([Colorado Sun](https://coloradosun.com/2019/05/28/quadratic-voting-colorado-house-budget/); [RadicalxChange case study](https://www.radicalxchange.org/wiki/colorado-qv/)) — though a 2024 court ruling that the anonymous ballots violated the state's open-meetings law halted the practice, a reminder that the mechanism's secrecy assumptions can collide with governance transparency.

QF is _prospective_: donors back what they hope will work, and the match amplifies breadth of support. Its mirror image is **[retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding)** (RetroPGF), which waits until the work is done and pays for what demonstrably worked — on the argument that "it's easier to agree on what _was_ useful than what _will be_ useful." The two are complements rather than rivals, and the same tooling has served both: Gitcoin's WEST team built a frontend for Optimism's RetroPGF Round 3 and open-sourced it as [EasyRetroPGF](https://github.com/gitcoinco/easy-retro-pgf). Optimism's Round 1 used a quadratic ballot before later rounds moved to mean, median and metrics-based rules — and in January 2026 Optimism [paused Retro Funding entirely](https://www.optimism.io/blog/season-9-from-experiment-to-organization), leaving QF the more durable of the two designs in practice.

## The limits — and a 2026 impossibility result

The deepest critique is not that QV/QF is hard to Sybil-proof in practice, but that _no_ concave weighting can be Sybil-proof in principle. A May 2026 analysis, ["Concave is the New Linear: The Impossibility of Anti-Plutocratic DAO Governance"](https://arxiv.org/abs/2605.18990) (Bennett, Vander Vos, Le & Belenkiy), proves that whenever a wallet of any size yields nonzero voting power, an attacker who splits tokens across enough wallets recovers voting power that grows **at least linearly** in their holdings — i.e. a concave rule degrades back to plain [token-weighting](/wiki/dao-governance/concepts/voting/token-weighted-voting) under attack. Testing the five largest DAOs (ENS, Compound, Uniswap, Arbitrum, ZKsync), the authors measured amplification factors above **1,100×** under quadratic voting, with attack costs far below the value at stake in real governance votes.

The lesson for DAO designers is stark: without a hard, unforgeable identity layer, an "anti-plutocratic" curve buys little — it adds complexity and a false sense of fairness while a determined whale simply pays the (small) cost of splitting. This is why token-weighting, for all its plutocratic flaws, remains the on-chain default, and why the frontier of the debate is now identity and [measurable concentration](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) rather than the shape of the voting curve itself.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does **not** use a quadratic or otherwise concave vote curve — and that is a deliberate choice, not an omission. Its canonical weight is _linear_ in a member's token balance, multiplied by the non-transferable "vote tokens" they have earned by participating: one factor is stake, the other is demonstrated engagement. Because the 2026 impossibility result shows a concave curve collapses to linear under Sybil-splitting anyway, chasing anti-plutocratic fairness through the curve would add complexity for a defense that does not hold.

Instead, a caper bounds the power of concentrated wealth two other ways. First, **influence and exit are the same formula**: the share of the treasury a member can claim by burning their stake is computed identically to their voting weight, so a large holder who steers the DAO against its members cannot also extract more than their pro-rata share on the way out — and the [exit door is always open](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Second, weight rewards **sustained participation** through soulbound vote tokens rather than one-shot buying power, so idle capital and freshly-acquired tokens count for less than committed, engaged members. It is an honest trade: a caper accepts that on-chain votes are wealth-weighted, and makes that weight _accountable_ rather than pretending a curve can erase it.

## References

- Steven P. Lalley & E. Glen Weyl, [Quadratic Voting: How Mechanism Design Can Radicalize Democracy](https://www.aeaweb.org/articles?id=10.1257/pandp.20181002), AEA Papers & Proceedings 108 (2018).
- Vitalik Buterin, Zoë Hitzig & E. Glen Weyl, [A Flexible Design for Funding Public Goods](https://arxiv.org/abs/1809.06421), Management Science 65(11) (2019).
- Vitalik Buterin, [Review of Gitcoin Grants CLR Round 3](https://vitalik.eth.limo/general/2019/10/24/gitcoin.html) (2019) — origin of pairwise-bounded QF.
- Bennett, Vander Vos, Le & Belenkiy, [Concave is the New Linear: The Impossibility of Anti-Plutocratic DAO Governance](https://arxiv.org/abs/2605.18990) (2026).
- RadicalxChange, [Plural Funding](https://www.radicalxchange.org/wiki/plural-funding/) and [Quadratic Voting in Colorado](https://www.radicalxchange.org/wiki/colorado-qv/).
- Gitcoin, [Quadratic Funding](https://gitcoin.co/mechanisms/quadratic-funding).

## Quorum and threshold design

URL: https://caper.network/wiki/dao-governance/concepts/voting/quorum-and-threshold-design
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | The participation floor a DAO proposal must clear, and the gate a proposer must clear to put one up |
| **Two gates** | **Quorum** – minimum weight that must participate for a result to count. **Proposal threshold** – minimum weight required to submit at all |
| **Denominators in production** | Absolute token constant (Compound) · fraction of past total supply (OpenZeppelin) · delegated votable tokens under a floor/ceiling clamp (Arbitrum) · a function of opposition (Nouns) · share of weight actually cast (Caper) |
| **Where an “against” vote lands** | Three frameworks, three answers: ignored (Compound Bravo), ignored while abstentions count (OpenZeppelin default), or actively raises the bar (Nouns) |
| **Failure modes** | Set too high → nothing passes and the DAO stalls. Set too low → the electorate has a purchase price |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [The DAO proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle), [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy), [Mechanism design](/wiki/economics/mechanism-design) |

A **quorum** is the minimum amount of voting weight that must participate before a DAO proposal's result is allowed to count. A **proposal threshold** is the minimum weight an address must control before it may submit a proposal at all. Together they are the two numeric gates on every token-governed DAO, and in most deployments they are the only two parameters standing between a well-funded outsider and the treasury.

They are usually discussed as a single dial – a percentage, tuned once at launch and rarely revisited. That framing hides the three decisions actually being made: _what goes in the denominator_, _which vote types count toward the numerator_, and _whether the bar is fixed or moves_. The major governance frameworks answer all three differently, in ways their own source code states plainly and their own governance forums almost never discuss.

## The denominator is the design

Every quorum is a ratio, and the interesting choice is what sits underneath it. Four denominators are in live production, and they price very different things.

**An absolute token constant.** Compound's Governor Bravo hard-codes it: [`uint public constant quorumVotes = 400000e18; // 400,000 = 4% of Comp`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol). The comment records what the number meant when it was written; the number itself does not track it. Because the value is a `constant` in the implementation contract rather than a storage variable, the DAO cannot change its own quorum by voting – it has to deploy and adopt a new implementation. The bar is denominated in tokens while everything it protects is denominated in dollars, so the real cost of clearing it moves every time the token price does, without anyone proposing anything.

**A fraction of past total supply.** OpenZeppelin's `GovernorVotesQuorumFraction` computes [`quorum(timepoint) = getPastTotalSupply(timepoint) × numerator / denominator`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol), with the denominator defaulting to 100 so the numerator reads as a percent. This re-prices automatically as supply changes, and the numerator is adjustable through `updateQuorumNumerator` under an `onlyGovernance` modifier – the DAO can raise its own bar without a redeployment. The catch is in the word _total_: tokens sitting on exchanges, locked in bridges, held by the DAO's own treasury and never claimed from an [airdrop](/wiki/economics/airdrops-and-token-distribution) all sit in the denominator and never vote. A nominal 4% quorum is therefore a much steeper bar on the addresses that actually turn up than the headline percentage suggests.

**Delegated votable tokens, clamped.** Arbitrum's constitution narrows the denominator twice over – not total supply but _Delegated_ Votable Tokens – and then puts a floor and a ceiling on the result. For a Constitutional AIP it specifies that if the proportional value [“is less than 150,000,000, then 150,000,000 applies”](https://docs.arbitrum.foundation/dao-constitution), the proportional value applies between 150,000,000 and 450,000,000, and above that the 450,000,000 ceiling applies; non-Constitutional AIPs run the same three-branch clamp between 100,000,000 and 300,000,000. The clamp is the design: a purely proportional quorum inherits every swing in the supply figure beneath it, and the floor and ceiling bound how far the bar can drift from what the DAO originally agreed to.

**A share of weight actually cast.** The fourth option removes the participation floor entirely and asks only about agreement among those who voted. It cannot be bought, because there is no absolute number to hit – but it also guarantees nothing about turnout. Caper takes this route; see below.

## What an “against” vote does to quorum

This is the part that surprises people, including delegates who vote weekly. Whether opposition counts toward the participation floor is a separate switch from the floor itself, and the frameworks disagree.

OpenZeppelin's `IGovernor` interface makes the two options explicit in its own specification of the `COUNTING_MODE` string: [“`quorum=bravo` means that only For votes are counted towards quorum” and “`quorum=for,abstain` means that both For and Abstain votes are counted towards quorum”](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/IGovernor.sol).

- **Compound Governor Bravo** is `quorum=bravo`. Its `state()` function defeats a proposal when `proposal.forVotes < quorumVotes` – against-votes and abstentions are simply absent from the test. Voting against does nothing to help a proposal reach quorum, and nothing to stop it either.
- **OpenZeppelin's default counting module** is `quorum=for,abstain`. `GovernorCountingSimple.COUNTING_MODE()` returns the literal string `"support=bravo&quorum=for,abstain"`, and `_quorumReached` tests `quorum(proposalSnapshot(proposalId)) <= proposalVote.forVotes + proposalVote.abstainVotes`. Abstaining materially advances a proposal toward passage; voting against does not.
- **Arbitrum** follows the same shape at the constitutional level: its Threshold 2 counts tokens that [“have cast votes either ‘in favor’ or ‘abstain’”](https://docs.arbitrum.foundation/dao-constitution).

The consequence is worth stating plainly, because it inverts how most voting guidance is written. Under the two most widely deployed configurations, **a delegate who wants to block a proposal by denying it quorum must not vote at all**. Voting against is strictly weaker than abstaining from the record entirely, and abstaining on-chain is not neutral – under `quorum=for,abstain` it is a contribution to the proposal clearing its floor. “Abstain” is presented in every governance UI as the neutral middle button. In the contract it is not.

This also explains a pattern that [turnout data](/wiki/dao-governance/concepts/analysis/voter-apathy) makes look like apathy and is partly strategy: on a contested proposal under a For-only or For-plus-Abstain quorum, organised opposition is rationally silent. The absence of votes against is not always the absence of objection.

## Dynamic quorum: pricing contentiousness

Nouns DAO takes the opposite position and makes opposition the input. Its [`NounsDAODynamicQuorum` library](https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-contracts/contracts/governance/NounsDAODynamicQuorum.sol) computes the bar per proposal rather than per DAO, and its own header comment states the rule: “Quorum votes required for a specific proposal to succeed … Differs from `GovernerBravo` which uses fixed amount”, and “The more against-votes there are for a proposal, the higher the required quorum is.”

The arithmetic is a clamped linear function. Against-votes are expressed in basis points of total supply at proposal creation, multiplied by a `quorumCoefficient` (a fixed-point integer with six decimals), added to a `minQuorumVotesBPS` floor, and the result is capped at `maxQuorumVotesBPS`:

```
againstVotesBPS   = 10000 × againstVotes / totalSupply
adjustedQuorumBPS = minQuorumVotesBPS + (quorumCoefficient × againstVotesBPS) / 1e6
quorumBPS         = min(maxQuorumVotesBPS, adjustedQuorumBPS)
```

The parameters are checkpointed by block, so a proposal is judged against the configuration in force when it was created rather than whatever the DAO has since adopted. The design target is agility without defencelessness: an uncontested proposal clears a low floor and passes quickly, while a proposal that draws real opposition has to assemble a proportionally larger coalition to carry. It is the only widely-deployed quorum that treats a vote against as information about how much agreement the proposal ought to need, rather than as a number to be out-counted.

The cost is a new attack surface. Because against-votes raise the bar, a minority holding enough weight can push the quorum requirement to its ceiling and defeat a proposal that has clear majority support but modest turnout – a veto obtained by opposing loudly rather than by winning. Nouns bounds this with `maxQuorumVotesBPS`; the bound is the whole defence, and choosing it is choosing how much minority veto power the DAO is willing to sell.

## Proposal thresholds: the gate on the way in

Quorum governs the exit from deliberation. The **proposal threshold** governs the entrance, and it is the parameter that decides who is a participant and who is an audience. OpenZeppelin defines `proposalThreshold()` as [“the number of votes required in order for a voter to become a proposer”](https://docs.openzeppelin.com/contracts/5.x/api/governance).

The two gates trade against each other in a way that is easy to miss. A high proposal threshold reduces spam and keeps the ballot short, which raises the chance that any given proposal clears quorum – at the price that the set of people who can start a conversation is the set of people who already hold a large position. A low threshold widens participation and lengthens the ballot, which spreads the same finite attention across more proposals and makes quorum failures more common. Neither setting is neutral about who governs; they simply move the exclusion to different ends of the process.

Compound's Governor Bravo treats the two gates asymmetrically, and the asymmetry is instructive. Quorum is a `constant` the DAO cannot change by voting, while the proposal threshold is a storage variable set at initialisation and bounded by two further constants – `MIN_PROPOSAL_THRESHOLD = 1000e18` and `MAX_PROPOSAL_THRESHOLD = 100000e18`, per the [Bravo source](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol). The entrance is adjustable within a hard-coded corridor; the exit is frozen. Whichever way round a DAO wants that, it is a decision worth making on purpose rather than inheriting from a template.

A threshold denominated in tokens has the same drift problem as an absolute quorum: the dollar cost of the right to propose moves with the token price, with no governance decision behind the move, and a corridor written in tokens does not bound it in any currency anyone spends. Some DAOs route around this with delegation minimums, sponsorship (a small holder drafts, a large delegate submits), or an off-chain [temperature check](/wiki/dao-governance/concepts/voting/proposal-lifecycle) that filters before the on-chain gate is reached at all.

## Two failure modes, one dial

Both ends of the range fail, and they fail in ways that look nothing alike.

**Set too high, the DAO stalls.** Proposals expire unresolved, the treasury cannot be deployed, and the practical effect is a status-quo bias that nobody voted for. Because a failed-quorum proposal produces no outcome at all – not a rejection, just an absence – a DAO can go months without deciding anything while its forum remains busy. The reasonable response is usually to fix turnout rather than lower the bar, but lowering the bar is the change that requires only one vote.

**Set too low, the electorate has a price.** This is the [BonkDAO](/wiki/daos/social/bonkdao) case of July 2026, and it is the clearest recent demonstration of what a supply-denominated quorum actually publishes. The quorum was 1% of BONK supply – roughly 880 billion BONK – set when the treasury held very little. The treasury subsequently grew into eight figures; the quorum was never re-priced. By July 2026 the whole electorate cost about $4.4m to assemble and the treasury behind it was worth roughly $20m, so the attack was profitable at a ratio of about 22 cents spent per dollar taken. An attacker paid it, and BIP #76 passed and executed on 6 July 2026. No contract was broken and no rule was bent – the vote was valid. The full sequence is documented on [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

The general statement is uncomfortable: **a quorum denominated in tokens, guarding a treasury denominated in dollars, is a published purchase price for control**, and the exchange rate between the two moves continuously without any vote. Every DAO with a fixed supply-percentage quorum is quoting that price right now. Most have never checked what it currently reads.

## Re-pricing a parameter nobody revisits

Quorum is the most consequential parameter in a DAO's constitution and among the least often amended, because amending it requires clearing the very bar under review. Raising a quorum is hard precisely when turnout is low, which is exactly when it most needs raising; lowering one is easy precisely when the DAO is frustrated, which is exactly when the decision is worst-informed.

A few practices reduce the drift without adding mechanism:

- **Denominate the review, not the parameter.** The number stays in tokens, because that is what the contract can read – but the DAO periodically checks what that number costs to acquire at current market prices, against the current [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) value. The ratio, not the percentage, is the health metric.
- **Exclude what cannot vote.** Treasury holdings, unclaimed distributions and bridge-locked supply inflate a total-supply denominator and quietly raise the effective bar on real voters. Arbitrum's “Delegated Votable Tokens” is the strict version of this correction. The arithmetic underneath – which tokens are eligible to count at all, and why a stock total-supply denominator measures a pool the votes cannot come from – is set out in [voting power activation and delegation thresholds](/wiki/dao-governance/concepts/voting/voting-power-activation).
- **Pair the floor with a delay.** A [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) does not stop a bought quorum, but it converts an instant drain into a window in which the theft is visible and members can exit. Several of the attacks that made a low quorum catastrophic were catastrophic because there was no delay behind it.
- **Read the counting mode before writing the guidance.** A DAO publishing voter guidance that calls “abstain” neutral, while running `quorum=for,abstain`, is misinforming its own delegates about what their button does.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no supply-denominated quorum at all. When a proposal settles, the contract computes the leading option's share of the weight _actually cast_ – `top_weight / total_weight` – and passes the proposal when that share reaches `1.5 / option_count` and the leading option is not a “no” option. At two options that is 75% of cast weight, at three 50%, at four 37.5%, at five 30%. There is no absolute participation number anywhere in the settlement path, so there is no figure an attacker can price and buy. A proposal that nobody votes on has zero total weight, so its share is zero and it fails.

That removes the BonkDAO failure mode and accepts a different one honestly: **Caper has no participation floor**. A proposal decided by a handful of members passes if they agree strongly enough. The defence is moved off the quorum and onto the weight itself. Voting weight is `(t·v)/(V·T)` – token balance `t` times the voter's vote tokens `v`, over vote-token supply `V` times circulating supply `T` – and vote tokens are earned one per ballot cast, with each ballot snapshotting `v` before minting the token it earns. A wallet voting for the first time contributes exactly zero weight to the proposal it is voting on. The tally also credits `min(held_at_vote, live_balance)`, and anyone may permissionlessly re-clamp that figure downward during a challenge window after voting closes, so weight that arrives for one vote and leaves afterwards does not keep its credit.

The proposal threshold is deliberately flat rather than proportional: a proposer must hold at least one governance token of the caper and pay a 500 XRD fee, which goes to that caper's own treasury rather than being burned. Voting costs 100 XRD per ballot on the same terms. The gate is a fixed cost, not a percentage of supply, so it does not concentrate the right to propose in the largest holders as the token appreciates – though, like every fixed fee, its real weight moves with the XRD price. Mechanics in [Proposals](/wiki/governance/proposals) and [Voting](/wiki/governance/voting).

## References

- OpenZeppelin Contracts, [`IGovernor.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/IGovernor.sol) – the `COUNTING_MODE` specification defining `quorum=bravo` and `quorum=for,abstain`.
- OpenZeppelin Contracts, [`GovernorCountingSimple.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingSimple.sol) – `_quorumReached` over `forVotes + abstainVotes`.
- OpenZeppelin Contracts, [`GovernorVotesQuorumFraction.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol) – quorum as `getPastTotalSupply(timepoint) × numerator / denominator`.
- OpenZeppelin, [Governance API reference](https://docs.openzeppelin.com/contracts/5.x/api/governance) – `quorum(uint256 timepoint)` and `proposalThreshold()`.
- Compound, [`GovernorBravoDelegate.sol`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) – the 400,000 COMP constant and the `forVotes < quorumVotes` defeat condition.
- Nouns DAO, [`NounsDAODynamicQuorum.sol`](https://github.com/nounsDAO/nouns-monorepo/blob/master/packages/nouns-contracts/contracts/governance/NounsDAODynamicQuorum.sol) – the dynamic quorum formula and its stated rationale.
- Arbitrum Foundation, [The Constitution of the Arbitrum DAO](https://docs.arbitrum.foundation/dao-constitution) – Threshold 1 and Threshold 2, Delegated Votable Tokens, and the clamped quorum formulas.

## Ranked and alternative ballot methods

URL: https://caper.network/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | How a DAO turns a pile of ballots into a decision, and why the counting rule changes the answer |
| **Single-winner families** | Plurality (single choice) · approval · weighted · ranked (Borda, Condorcet/Copeland, instant-runoff) · [quadratic](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) |
| **Governing results** | Arrow: no ranked rule satisfies all the fairness criteria at once. Gibbard–Satterthwaite: over three or more options, every non-dictatorial rule is manipulable |
| **On Snapshot** | Six types – single choice, weighted, approval, quadratic, ranked choice (instant runoff), basic |
| **Multi-winner** | Committee and grant selection is a different problem – STV, sequential Phragmén, or a budget-constrained knapsack, not a single-winner rule run repeatedly |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Mechanism design](/wiki/economics/mechanism-design), [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) |

Almost every DAO proposal is a yes/no question, and almost every DAO discussion about voting is about _who_ gets weight – [one token one vote](/wiki/dao-governance/concepts/voting/token-weighted-voting), [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation), [vote escrow](/wiki/dao-governance/concepts/voting/vote-escrow). The **ballot method** is the other half of the machine: given the weights, what shape of preference may a voter express, and what arithmetic turns those expressions into a winner. Once a proposal has three or more live options – three budget levels, four candidate service providers, five parameter values – the counting rule stops being an implementation detail and starts picking outcomes.

This page covers the ordinal and set-valued families that DAOs reach for once yes/no runs out: **approval**, **weighted**, and the ranked rules (**Borda**, **Condorcet**/**Copeland**, **instant-runoff**), plus the multi-winner methods used to fill committees and fund grant slates. [Quadratic voting and funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) has its own page; it is a cardinal rather than an ordinal method and carries an identity dependency the others do not.

## The counting rule is part of the mechanism

Two results from social choice theory bound what any ballot method can promise, and both are worth stating before comparing rules, because most governance-forum arguments about voting methods are really arguments about which of these two prices to pay.

**Arrow's impossibility theorem** establishes that no rule for aggregating individual rankings into a group ranking can simultaneously satisfy a short list of reasonable-looking conditions – unrestricted domain, unanimity, independence of irrelevant alternatives, and non-dictatorship – once there are at least three alternatives ([Stanford Encyclopedia of Philosophy](https://plato.stanford.edu/entries/arrows-theorem/)). Every ranked method in use is therefore a choice about which condition to give up, not a method that escaped the tradeoff.

**Gibbard–Satterthwaite** adds that over three or more options, any deterministic, non-dictatorial rule with a full range is _manipulable_: some voter, in some profile, does better by submitting a ranking that is not their honest one. A DAO cannot buy its way out of strategic voting by picking a cleverer tally – only relocate where the strategy shows up. See [mechanism design](/wiki/economics/mechanism-design) for the general framing and the incentive-compatibility criterion these results constrain.

## The single-winner families

**Plurality (single choice).** Each voter backs one option; the option with the most weight wins. Cheap and legible, and the default nearly everywhere. Its defect with three or more options is vote-splitting: two similar options divide the support that either alone would have beaten a third with, so the winner can be the option a majority actively opposes.

**Approval.** Each voter marks the subset of options they find acceptable – a threshold judgement, not a ranking. Approval sidesteps vote-splitting without asking for a full ordering, and it composes well with proposals whose options are not mutually exclusive. What it cannot express is intensity or order: as the [Stanford Encyclopedia](https://plato.stanford.edu/entries/voting-methods/) puts it, ranking a set of candidates and selecting the ones that are approved “are two different aspects of a voters overall opinion… They are related but cannot be derived from each other.”

**Weighted.** Each voter splits their voting power across options in whatever proportions they choose. This is the cardinal cousin of approval – it does capture intensity – and it is the natural fit for allocation questions (how to split a budget) rather than selection questions (which option wins).

**Borda count.** Voters submit a full ranking and each position pays fixed points: with _n_ options, “give n−1 points to the candidate ranked first, n−2 points to the candidate ranked second, … and 0 points to candidate ranked last.” Because every ballot contributes the same total, Borda measures average standing across the whole field rather than first-place popularity, which is why it tends to elect broadly acceptable compromise options.

**Condorcet methods, including Copeland.** A **Condorcet winner** is an option that beats every other option in a head-to-head comparison. When one exists it is a strong claim to legitimacy; the difficulty is that it need not exist, because majority preference can cycle (A beats B, B beats C, C beats A). **Copeland's rule** resolves this by scoring each option's win–loss record across all pairwise matchups and electing the option that maximises it.

**Instant-runoff (ranked choice, the Hare rule).** Count first preferences; if no option clears 50%, eliminate the option with the fewest first preferences and transfer those ballots to their next surviving preference; repeat. This is the “ranked choice” type on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), described in its [voting-types documentation](https://docs.snapshot.box/proposals/voting-types).

## Where each rule breaks

Every family has a signature failure mode, and knowing which one a DAO has adopted is more useful than arguing about which rule is best in the abstract.

- **Borda – burying.** Borda is unusually easy to manipulate by ranking a strong rival last rather than honestly. The Stanford entry works a case where a voter who prefers a losing option can flip the result purely by reordering the options below her favourite, making “it in the interest of the third voter to misrepresent her preferences.” Borda is also sensitive to _clones_: adding near-duplicate options changes the point spread even if nobody's real preferences changed.
- **Condorcet – cycles.** Majority preference has no guarantee of transitivity, so a Condorcet method needs a documented tiebreak (Copeland, Schulze, ranked pairs) that will decide a nontrivial share of real elections. A DAO that adopts “the Condorcet winner wins” without specifying the cycle rule has not finished specifying its governance.
- **Instant-runoff – monotonicity failure and the no-show paradox.** The Hare rule violates monotonicity: _gaining_ support can cost an option the win, because moving up in first preferences changes who is eliminated first. It also admits the no-show paradox, where voters would have preferred the outcome of an election in which they did not participate. Both are counterintuitive enough that a DAO discovering them after a contested vote will have a legitimacy problem, not just a maths problem.
- **Approval – the threshold is strategic.** Nothing in approval tells a voter where to set their acceptance bar, and the optimal bar depends on how everyone else sets theirs. Approving your second choice may elect it over your first; approving only your first may elect your last.
- **Plurality – splitting.** Covered above, and the reason most of the other rules exist.

## Token weight changes which pathologies bite

Classical social choice assumes one voter one ballot. DAO ballots carry stake, and three differences follow that the textbook analysis does not cover.

**The tally is computable in advance.** On-chain and Snapshot votes are public while voting is open, so a large holder can see the running result and compute the exact ranking that maximises their outcome before the deadline. Strategic manipulation in the Gibbard–Satterthwaite sense is a coordination problem for ordinary voters and a spreadsheet exercise for a whale. This is the strongest practical argument for [private and shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting), and it hits ranked rules harder than plurality because a ranked ballot has more degrees of freedom to exploit.

**Small-electorate pathologies are the normal case.** Monotonicity failures and Condorcet cycles are rare in large public elections and much less rare when a handful of delegates carry most of the weight. A DAO where five addresses decide the outcome is exactly the regime where these effects show up – see [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) for how concentrated real turnout is.

**Ballot design measurably moves weight.** Balietti, Saggese & Strohmaier's [Voting Biases in Decentralized Autonomous Organization (DAO) Governance](https://arxiv.org/abs/2607.09435) (July 2026) links voting-power distribution to three observable features of a proposal's choice list and finds all three carry a premium: choices selected by the proposal's own author (+58.8%), choices phrased as approval rather than rejection (+27.1%), and choices listed first (+7.7%). Their conclusion is the one that matters for anyone writing a governance framework – ordering, author signals and vote visibility “should be treated as institutional design choices, not neutral implementation details.”

## What DAO platforms actually implement

**Snapshot** ships six voting types and its [documentation](https://docs.snapshot.box/proposals/voting-types) is explicit that the type “calculates the outcome of the proposal” while the separate _strategy_ calculates individual voting power. Two implementation details are load-bearing and routinely missed. Its **approval** type gives each approved choice the voter's _full_ power – “if user selects two choices, each choice will receive the total voting power of the user” – so approval on Snapshot is not a budget the voter divides, and totals across choices exceed the electorate's weight. Its **ranked choice** type is instant-runoff, and Snapshot lists the limitation itself: it “will only determine one winner, doesn't work well to select 2 or more winning options.”

**ENS** built a custom pairwise tally for its Service Provider Program rather than use a stock type. Delegates drag providers above or below a `NONE BELOW` line – “projects above 'NONE BELOW' are approved; those below are disqualified” – then rank the approved ones by funding priority, with “the algorithm compares each project against the others to determine the final result” and providers able to submit a basic and an extended budget that can be ranked separately ([EP 6.10](https://docs.ens.domains/dao/proposals/6.10/)). That is a Copeland-family pairwise comparison with an explicit no-funding threshold and a budget cap bolted on. It selected eight providers for Season 2 against a budget raised from $3.6M to $4.5M a year ([SPP2 stream implementation thread](https://discuss.ens.domains/t/spp2-stream-implementation-preparing-the-executable-proposal/20890), June 2025). See [ENS DAO](/wiki/daos/infrastructure/ens-dao).

**Polkadot** uses the **sequential Phragmén** method, “a multi-winner election method introduced by Edvard Phragmén in the 1890s,” inside Nominated Proof-of-Stake “to elect validators based on their own self-stake and the stake that is voted to them from nominators” ([Polkadot wiki](https://wiki.polkadot.com/learn/learn-phragmen/)). It was also used for Council elections under Governance V1, now deprecated. See [Polkadot](/wiki/daos/networks/polkadot).

## Multi-winner selection is a different problem

Choosing a five-member security council, a grants slate, or a set of funded service providers is not the same question as choosing one option, and running a single-winner rule repeatedly gets it wrong in a specific way: it tends to hand every seat to the largest coherent bloc. A 51% majority that runs the table on five sequential single-winner elections takes all five seats.

The multi-winner family exists to prevent that. **Single transferable vote** transfers surplus above a quota as well as votes from eliminated candidates, so a bloc holding 40% of the weight elects roughly 40% of the seats rather than none. **Sequential Phragmén** attacks the same goal by spreading each voter's “load” as evenly as possible across the winners it elects; Janson's [Phragmén's and Thiele's election methods](https://arxiv.org/abs/1611.08826) is the standard modern treatment. Where the constraint is a budget rather than a seat count – the usual DAO case – the selection becomes a knapsack problem, which is what ENS's approve-then-rank-then-cap procedure is solving.

The practical rule for a DAO: if the proposal fills more than one slot, do not reach for the ranked-choice type. It was built to produce exactly one winner, and its own documentation says so.

## How Caper approaches this

Caper does not offer a menu of voting types. Every proposal is settled by one rule, fixed in the contract: a **Borda count over complete rankings, weighted by each voter's vote weight**. A ballot has to rank every option on the proposal – partial ballots are rejected, as are duplicate rankings – and position _i_ in a ballot of _n_ options contributes (n−1−i) times that voter's weight, the classical Borda scale, with the last-ranked option contributing nothing.

Two consequences fall out of that arithmetic. Because every ballot contributes the same total points regardless of how it ranks, an option's share of the total is a share of Borda points, and an option would average 1/n of them under random ballots. The pass threshold is 1.5/n – half again the neutral share – so with two options the leader needs 75% of participating weight, and with five it needs 30%. And any option may be flagged as a no-op by whoever wrote the proposal: if the Borda leader is a flagged option, the proposal does not execute, so “none of these” is a first-class outcome rather than a failure to reach quorum.

The tradeoff is the honest one from the sections above. Borda is compromise-seeking and manipulable by burying, and Caper's ballots are public while voting is open. What the design buys in exchange is that the winning option _is_ the transaction, with no committee standing between the tally and execution – see [voting mechanisms](/wiki/governance/voting-mechanisms) and [execution](/wiki/governance/execution).

## References

- Stanford Encyclopedia of Philosophy, [Voting Methods](https://plato.stanford.edu/entries/voting-methods/) – Borda, Condorcet, Copeland, monotonicity failure, the no-show paradox, approval.
- Stanford Encyclopedia of Philosophy, [Arrow's Theorem](https://plato.stanford.edu/entries/arrows-theorem/).
- Stefano Balietti, Pietro Saggese & Markus Strohmaier, [Voting Biases in Decentralized Autonomous Organization (DAO) Governance](https://arxiv.org/abs/2607.09435) (arXiv:2607.09435, 10 July 2026).
- Svante Janson, [Phragmén's and Thiele's election methods](https://arxiv.org/abs/1611.08826) (arXiv:1611.08826).
- Snapshot, [Voting types](https://docs.snapshot.box/proposals/voting-types).
- ENS DAO, [EP 6.10 – Service Provider Program Season 2 selection](https://docs.ens.domains/dao/proposals/6.10/) and the [SPP2 stream implementation thread](https://discuss.ens.domains/t/spp2-stream-implementation-preparing-the-executable-proposal/20890).
- Polkadot, [Sequential Phragmén method](https://wiki.polkadot.com/learn/learn-phragmen/).

## The DAO proposal lifecycle

URL: https://caper.network/wiki/dao-governance/concepts/voting/proposal-lifecycle
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | How an idea becomes a binding on-chain decision in a DAO |
| **Stages** | Discussion → Temperature check → Formal proposal → Voting period → Timelock → Execution |
| **Venues** | Forum (Discourse / [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth)) · [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (off-chain) · Governor contract (on-chain) |
| **Key gates** | Proposal threshold · Quorum · Approval threshold · Timelock delay |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

The **proposal lifecycle** is the sequence of stages a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) puts an idea through before it becomes a binding, executed decision. A mature DAO rarely jumps straight to an on-chain vote: an idea is discussed, informally polled, drafted into a formal proposal that must clear participation and approval thresholds, voted on for a fixed window, and — if it passes — held in a **[timelock](/wiki/dao-governance/concepts/voting/governance-timelocks)** before it executes. Each stage is a filter that trades a little speed for legitimacy and safety. This page walks the canonical flow used by large protocol DAOs such as [ENS](https://docs.ens.domains/dao/governance/process/), Uniswap, and [Compound](/wiki/daos/lending/compound-dao), which is built on the [OpenZeppelin Governor + Timelock](https://docs.openzeppelin.com/contracts/5.x/governance) contracts.

## 1. Discussion and temperature check

Most proposals begin as a forum post — typically on a [Discourse](https://www.discourse.org/) or [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth) forum — where the idea is debated, refined, and stress-tested by delegates and the wider community. Once a rough consensus forms, the author runs a **temperature check**: a low-stakes, gasless [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) poll that signals whether the idea has enough support to justify a formal vote. The temp check is non-binding, but it weeds out proposals that would fail and gives the author a mandate to invest in a formal draft. ENS formalizes this as an explicit stage before any executable proposal reaches its governor. ([a16z governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## 2. The formal proposal and its thresholds

A formal proposal is a concrete, executable specification — for on-chain proposals, the exact contract calls to run. Submitting one is gated by a **proposal threshold**: a minimum amount of voting power the author must hold or have delegated to them, which stops the ballot from being spammed — one of a family of [proposal throttles and rate limits](/wiki/dao-governance/concepts/voting/proposal-throttles-and-rate-limits) (sponsor thresholds, deposits, concurrency caps) that gate the entrance to a vote rather than its outcome. Passing then depends on two further gates:

- **Quorum** — a minimum amount of voting power that must participate for the vote to count at all. ENS, for example, requires roughly 1% of the supply to turn out. Quorum stops a tiny, unrepresentative minority from pushing through a decision on a quiet day.
- **Approval threshold** — the share of participating votes that must be in favour, whether a simple majority or a higher super-majority for sensitive actions.

These parameters are the DAO's [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) made concrete, and picking them is a balancing act: set quorum too high and nothing passes; too low and the DAO is easy to [capture](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

## 3. Voting period

Once active, the proposal is open for votes for a fixed window — commonly several days to a week (ENS runs a seven-day on-chain period). Votes may be cast off-chain on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), where signed messages are tallied for free, or on-chain through a Governor contract, where each vote is a transaction counted against a voter's balance _snapshotted at the block the proposal was created_ — a deliberate defence that neutralizes tokens borrowed or bought after voting opens. Voting power itself is set by the governance model: one-token-one-vote, quadratic, conviction, or a delegated variant. ([Tally: on-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/))

## 4. Timelock and execution

Passing the vote is not the same as executing. On-chain DAOs route a passed proposal through a **timelock** — a mandatory delay (ENS uses two days) between approval and execution. The delay is a safety valve: it gives members who disagree, or who spot a malicious payload, a window to react — to exit, to sound the alarm, or for a guardian to veto — before irreversible code runs. When the delay elapses, execution happens one of two ways:

- **Self-executing** — the Governor + Timelock contracts carry out the encoded calls trustlessly, with no discretion in the loop: nobody can alter or veto the payload at this point. Somebody must still send the transaction, though, and pay for it. `execute` is permissionless and caller-paid in both the OpenZeppelin and Compound designs, which makes the last step of the lifecycle a real cost assigned to nobody (see [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs)). The hosted interface most large DAOs used to drive it was [Tally](/wiki/dao-governance/tooling/voting/tally) (now Cactus).
- **Multisig execution** — an off-chain Snapshot vote authorizes a small group of signers to carry out the result from a [Safe](/wiki/dao-governance/tooling/treasury/safe). Cheaper and more flexible, but it reintroduces trusted humans between the vote and the action.

## Why the stages exist

Every filter in the lifecycle defends against a specific failure mode: the temp check saves gas and attention; the proposal threshold blocks spam; quorum blocks decisions by an unrepresentative few; the block-height snapshot blocks flash-loan and rented-vote attacks; and the timelock blocks silent, instant execution of a malicious payload. Skipping stages is exactly how [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) succeed — the Beanstalk exploit worked because a proposal could be flash-loaned into passing _and_ executed in a single transaction, with no snapshot and no timelock to break the chain.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) compresses the lifecycle into a single on-chain flow. A member creates a [proposal](/wiki/governance/proposals) with a title, a description, and at least two ranked options; an _executive_ proposal can carry real actions — a **PAYOUT** of treasury funds, an **INVEST** into another caper's curve, or a **VOTE** cast in another caper's proposal. Members then rank the options over a fixed [voting window](/wiki/governance/voting), after which a mandatory execution-delay window opens before anyone can [execute](/wiki/governance/execution) the winner — a timelock written into the contract rather than bolted on as a separate module. An option only becomes executable if it clears a built-in super-majority of the vote weight cast (a threshold of 1.5 divided by the number of options). There is no separate multisig hand-off: discussion can happen wherever the community likes, but the proposal, the vote, and the execution are one auditable object. The specifics live on the linked governance pages.

## References

- ENS Docs, [Governance Process](https://docs.ens.domains/dao/governance/process/) — a worked example of the full temp-check → draft → vote → timelock flow.
- OpenZeppelin, [Governance (Governor + Timelock)](https://docs.openzeppelin.com/contracts/5.x/governance) — the on-chain proposal-lifecycle contracts most DAOs use.
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/) — on thresholds, quorum, and why the stages exist.
- Tally, [On-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/).

## Token-weighted voting

URL: https://caper.network/wiki/dao-governance/concepts/voting/token-weighted-voting
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Topic** | One token, one vote: the default on-chain governance rule |
| **Rule** | Voting power is proportional to governance tokens held (or delegated) |
| **Why default** | Simple, legible, Sybil-resistant by construction |
| **Core weaknesses** | Plutocracy · voter apathy · vote-buying & token lending |
| **Standard stack** | ERC-20 votes token + OpenZeppelin Governor + Timelock |
| **Related** | [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [Voting mechanisms](/wiki/governance/voting-mechanisms) |

**Token-weighted voting** — often called _one-token-one-vote_ — is the rule that a voter's influence is proportional to how many governance tokens they hold. It is the on-chain default: the great majority of [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) count votes this way, and it is the baseline against which every other [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) is defined. Weighting is only half the machine: the rule that turns weighted ballots into a winner – plurality, approval, or one of the [ranked methods](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods) – is a separate design choice layered on top of it. Its appeal is that it is simple, fully mechanical, and **Sybil-resistant by construction** — because influence is tied to a scarce, market-priced asset, splitting your holdings across a thousand wallets changes nothing, and buying more influence means buying more of the token. This page covers how it works on-chain, why it won, and the well-documented ways it fails.

## How on-chain token voting works

The dominant implementation is the [OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/4.x/api/governance) pattern, standardized after Compound's 2020 Governor Bravo and now running under hundreds of DAOs. A governance token implements a **votes extension** (ERC-20 `ERC20Votes`) that records a _checkpointed_ balance history, so the contract can ask "how many tokens did this address control at block _N_?". Voting power must be **activated by delegation** — holders delegate to themselves or to a representative — which is why raw token balances and active voting power often differ sharply.

A proposal then moves through a fixed lifecycle: it is submitted (subject to a **proposal threshold**), enters a voting period during which each address's weight is read from a **snapshot block** fixed at proposal creation, and — if support clears the threshold and **quorum** is met — is queued in a **timelock** before it can execute. The snapshot is load-bearing: because weight is counted as of a past block, tokens acquired _after_ a proposal is filed carry no weight, which is the standard structural defense against [flash-loan vote seizure](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

Both numeric gates in that lifecycle – the proposal threshold on the way in and the quorum on the way out – are design choices rather than constants of the pattern. Which vote types count toward the quorum floor differs between Compound's Governor Bravo and OpenZeppelin's default counting module, and how the floor itself is denominated (an absolute token constant, a fraction of past total supply, delegated tokens under a clamp, or a function of the opposition) differs again across major deployments. [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) works through each and what it costs.

## Why it became the default

Token voting won for practical reasons, not because it is fair. It needs **no identity layer** — the hardest unsolved problem in on-chain governance — because it never has to know who anyone is, only how many tokens they moved. It is **legible**: anyone can compute the outcome from public balances. It is **composable**: a single ERC-20 doubles as the fundraising instrument, the liquidity-mining reward, and the ballot, and it drops straight into off-the-shelf tools like [Tally](https://docs.tally.xyz/) and [Snapshot](https://snapshot.box/). For a protocol that has to ship, "issue a token and wire it to a Governor" is the path of least resistance — and so it became the path almost everyone took. ([Chainlink: governance tokens and DAO voting](https://chain.link/article/governance-tokens-dao-voting))

## The plutocracy critique

The defining objection is that one-token-one-vote is **one-dollar-one-vote**: whoever holds the most tokens decides, so a protocol that calls itself decentralized can be steered by a handful of founders, funds, and exchanges. The concentration is measurable — analysts track a DAO's [Nakamoto coefficient](https://arxiv.org/pdf/2304.08160) (how few addresses it takes to reach a majority) — one of the core [DAO health metrics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) — and for many large DAOs that number is uncomfortably small. Compounding it is **voter apathy**: because a small holder's vote almost never changes an outcome, turnout in token-weighted DAOs routinely runs in the single digits, which concentrates _effective_ power even further into the few large holders who do show up. Forbes summarized a decade of findings under a blunt 2026 headline: [DAOs keep centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/).

## Vote-buying and token lending

The subtler failure is that token voting **decouples influence from stake**. A voter who _borrows_ tokens to vote and returns them afterward has, as [Vitalik Buterin argues](https://vitalik.eth.limo/general/2021/08/16/voting3.html), "zero net exposure" to the consequences of the decision — they capture any upside of a self-serving vote while bearing none of the downside to the token. This is not hypothetical: lending markets, liquid-staking wrappers, and outright **bribe markets** (the Curve Wars' vote-incentive platforms) all let voting power be rented. The result is a **bundling vulnerability** — voting rights that were supposed to be tied to long-term ownership become just another yield to be farmed, and a well-capitalized outsider can assemble a temporary majority without any lasting alignment. It is the mechanism behind several [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

## Mitigations

Rather than abandon token voting, most DAOs bolt defenses onto it. **Past-block snapshots** neutralize flash-loaned weight. **Timelocks and [guardian vetoes](/wiki/dao-governance/concepts/voting/optimistic-governance)** buy time to react to a captured vote. **[Vote-escrow (ve) locks](/wiki/dao-governance/concepts/treasury/dao-tokenomics)** — as in Curve's veCRV — time-weight tokens so transient capital counts for less than committed capital. **Staking gates** — as on the [dYdX Chain](/wiki/daos/dexs/dydx) and other Cosmos-SDK DAOs — count only tokens _actively staked_ to secure the chain, so idle balances carry no vote weight. **[Delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation)** lets apathetic holders hand their weight to engaged representatives, raising effective participation. And a growing number of designs **combine** stake with something money cannot cheaply buy — verified identity (for [quadratic voting](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding)), elapsed time, or demonstrated participation — accepting a little more complexity to escape pure plutocracy. ([a16z governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) deliberately departs from pure token weighting. Stake still matters — a member's holdings are one factor in their weight — but weight is the _product_ of that stake and the member's **earned participation**, recorded as non-transferable tokens minted one per vote. A large balance that has never voted therefore carries little weight, which blunts both the plutocracy problem (idle capital does not automatically rule) and the vote-buying problem (borrowed or freshly-acquired tokens bring no participation history, and that history cannot be rented). Combined with a ranked-choice super-majority, an execution delay, and a pro-rata [exit](/wiki/governance/execution) right that ties each member's voice to their claim on the treasury, the design keeps token voting's Sybil-resistance while shedding its one-dollar-one-vote default. The mechanics are on the linked [governance pages](/wiki/governance/voting).

## References

- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).
- Chainlink, [Governance Tokens and DAO Voting](https://chain.link/article/governance-tokens-dao-voting).
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).
- OpenZeppelin, [Governor & Votes contracts](https://docs.openzeppelin.com/contracts/4.x/api/governance).
- Forbes, [DAOs Keep Centralizing](https://www.forbes.com/sites/digital-assets/2026/04/04/daos-keep-centralizingdecades-of-governance-research-explain-why/) (2026).

## Typed vs arbitrary proposal execution

URL: https://caper.network/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Topic** | Whether a passed proposal may run _any_ call, or only one of a fixed set of actions |
| **The arbitrary end** | [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) · Compound Governor Bravo · [Baal](/wiki/dao-governance/tooling/frameworks/daohaus) multi-send — a proposal carries raw `calldata` |
| **The typed end** | Enumerated action kinds the contract itself understands; anything outside the enum is not expressible |
| **Core trade-off** | Generality (any future action, no upgrade needed) against **legibility** (a voter can tell what the proposal does) |
| **Mitigations in practice** | [Timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks) · [Zodiac Roles](/wiki/dao-governance/tooling/frameworks/zodiac) scoping · simulation before the vote |
| **Worked failure** | Tornado Cash, May 2023 — a proposal whose code changed _after_ it passed |
| **Related** | [The proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) · [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

Every DAO framework has to answer one question about its proposals: **what is a passed vote allowed to do?** There are two families of answer. In an _arbitrary-execution_ design, a proposal carries raw transaction data and the governance contract will execute whatever that data says. In a _typed_ design, a proposal selects from a fixed list of action kinds that the contract itself understands, and nothing outside that list can be expressed at all.

This axis is rarely stated explicitly, but it decides more about a DAO's real risk profile than quorum or threshold settings do. It determines whether a voter can know what they are voting for by reading the ballot, and it is the axis on which the [most expensive governance failures](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) turn.

## What arbitrary execution actually looks like

The dominant Ethereum pattern is arbitrary. [OpenZeppelin's Governor](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol) declares its entry point as `propose(address[] targets, uint256[] values, bytes[] calldatas, string description)`. The first three arrays are the proposal; the fourth argument, the human-readable description, is the only part a voter reads and the only part the contract does not enforce. Compound's [Governor Bravo](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) takes the same shape with an extra `signatures` array and caps a proposal at ten actions (`proposalMaxOperations = 10`).

Nothing in either contract relates the description to the calldata. A proposal titled “Fund the grants program for Q3” and a proposal that drains the treasury are, to the governance contract, the same kind of object: a list of addresses, values and byte strings. Verifying that the two agree is off-chain social work, and it is work almost nobody does — decoding calldata against an unverified target contract is a skill most delegates do not have and most voters do not attempt.

The upside is real and is why the pattern won. An arbitrary-execution DAO can do things its designers never anticipated: call a protocol that did not exist when the governance contract shipped, adopt a new standard, or wind itself down. A typed DAO can only ever do what its enumeration allows, and widening the enumeration means changing the contract.

## The failure mode: a proposal that changed after it passed

In May 2023 Tornado Cash lost governance control of itself to a proposal that looked like an earlier, legitimate one. Per [Halborn's analysis](https://www.halborn.com/blog/post/explained-the-tornado-cash-hack-may-2023), the attacker submitted a proposal that claimed to implement the same logic as a previously approved proposal, but whose deployed contract carried extra self-destruct logic. Voters, comparing it to the version they already trusted, passed it. The attacker then destroyed the proposal contract and redeployed different code at the same address. When the proposal executed — via `delegatecall`, so in governance's own storage context — it minted the attacker 1.2 million votes against roughly 70,000 legitimate ones, and about 483,000 TORN (~$2.17 million) was drained.

The instructive part is not the self-destruct trick. It is that **every governance rule worked correctly**. Quorum was met, the vote was honest, the timelock elapsed, and the contract executed exactly the bytes it was given. The failure was entirely in the gap between what the proposal _said_ and what its calldata _did_ — the gap that arbitrary execution creates by design and that no voting parameter can close.

## Narrowing the surface without giving up generality

Most of the tooling built around Governor over the past few years is, read charitably, an attempt to recover legibility that arbitrary execution gave away.

- **[Timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks)** do not make a proposal legible; they buy time for someone else to notice. They convert an execution problem into a monitoring problem, which is an improvement only if somebody is monitoring.
- **Scoped permissions.** [Zodiac's Roles Modifier](/wiki/dao-governance/tooling/frameworks/zodiac) sits between a module and a [Safe](/wiki/dao-governance/tooling/treasury/safe) and, in its [own description](https://github.com/gnosisguild/zodiac-modifier-roles), lets holders of a role “unilaterally make calls to any approved addresses, approved functions, and using approved parameters.” That is typing applied at the permission layer rather than the proposal layer: the calldata stays arbitrary, but the set of calls that will be accepted is enumerated in advance.
- **Simulation.** Front-ends increasingly simulate a proposal's calls against forked state and show the resulting balance changes. This is the closest thing to making calldata readable, and it is why proposal tooling and [governance data](/wiki/dao-governance/tooling/analytics/boardroom) services matter more than their unglamorous positioning suggests.
- **Procedural checks.** DAOhaus's [published vote-decision flow](https://github.com/HausDAO/moloch-skills/blob/main/VOTE_DECISION_FLOW.md) for autonomous agent members is the clearest written statement of the problem: it classifies every proposal into one of six buckets, of which the last is plainly **“arbitrary execution”**, and requires the agent to ask “does action data match proposal text?” before voting. When a procedure has to name that question explicitly, the design has already conceded that the answer is not obvious.

## Why typed designs are rarer than they should be

Typing a proposal system has an obvious cost: the enumeration is a ceiling. Adding a genuinely new action means changing the contract that holds the state, which is exactly the kind of change a DAO is slowest at making and most reluctant to authorise. Frameworks that expect to serve arbitrary future protocols therefore default to arbitrary calldata, and the burden of understanding a proposal shifts to the voter.

The counter-argument is that most DAOs do not need generality. A treasury that in practice only pays contributors, buys assets, sells assets and votes in other organizations has a small action vocabulary, and paying for unlimited expressiveness it never uses buys nothing but attack surface. The right question is not “which design is safer” but **how wide the DAO's action vocabulary genuinely is** — and, if it is narrow, whether the framework will let it say so on-chain. Most will not. This is one of the places where framework choice, made once and early, quietly sets a ceiling on how [minimal](/wiki/dao-governance/concepts/fundamentals/governance-minimization) a DAO's trust assumptions can ever become.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) sits at the typed end, and deliberately. An executive [proposal](/wiki/governance/proposals) option carries a `kind` discriminator, and the contract recognises exactly five: pay an address from the treasury, buy another caper's token, sell one back down its curve, cast a vote inside another caper, or — on the platform's own caper only — swap the shared logic every caper runs. There is no sixth slot and no calldata field. A proposal cannot encode a call the contract does not already know how to make.

The consequences run both ways, and both are worth stating. A voter can read what an option does from its kind and its typed fields, so the Tornado failure mode — a description that does not match the payload — has no room to occur. But the enumeration really is a ceiling: adding a new kind requires the state-holding contract's cooperation, not merely a passed vote. Caper's answer to that is the fifth kind, an upgrade of the shared logic tier, which is itself a proposal subject to the same voting rules. The action vocabulary is fixed, but the process for widening it is inside governance rather than outside it. See [execution](/wiki/governance/execution) for how a winning option is settled.

## Vote markets and governance bribery

URL: https://caper.network/wiki/dao-governance/concepts/voting/vote-markets
Updated: 2026-08-11

| Concept | Vote markets (governance "bribery") |
| --- | --- |
| Also called | Vote incentives, vote bribery, governance bribes, vote renting |
| Category | Voting & incentive design |
| Core idea | A secondary market where protocols pay token-holders to vote a particular way, turning voting power into a rentable, cash-flow-bearing asset |
| Depends on | [Vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) and gauge-directed emissions |
| Major venues | [Votium](https://votium.app/), [Hidden Hand](https://hiddenhand.finance/) (Redacted), [Paladin / Warden Quest](https://paladin.vote/) |
| Central tension | Separates economic ownership (cash-flow rights) from control (voting rights) |

A **vote market** is a marketplace where anyone can pay the holders of a governance token to vote a particular way. The payments are universally — and only half-jokingly — called **bribes**. The mechanism is not an attack or an exploit: it is an openly-run, smart-contract-mediated auction for voting power, and for several protocols it has become the single largest recurring flow of value in their governance. Vote markets are the clearest working example of a broader phenomenon — once a vote carries a predictable cash reward, that vote becomes an asset that can be priced, rented, and traded independently of the tokens underneath it.

## Why vote markets exist

Vote markets are a downstream consequence of [vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow). In the ve-model pioneered by [Curve](/wiki/daos/dexs/curve-dao), locked tokens (veCRV) do more than signal preference — they direct _gauge weights_, the on-chain vote that decides how newly-minted token emissions are split across liquidity pools ([Convex: voting and gauge weights](https://docs.convexfinance.com/convexfinance/general-information/why-convex/voting-and-gauge-weights)). Because a gauge vote literally routes real money, a project that wants deep liquidity has two options: buy and lock the governance token itself, or _pay existing lockers_ to point their votes at its pool. The second is almost always cheaper, and the market that formed to price it became known as the **Curve wars** ([Votium: why Votium](https://docs.votium.app/general-information/why-votium)).

The same logic reappears anywhere emissions are vote-directed: [Balancer](/wiki/daos/dexs/balancer-dao) and its Aura wrapper, [Aerodrome](/wiki/daos/dexs/aerodrome-finance) on Base, Frax, and any protocol that copies the ve(3,3) gauge design inherits a vote market whether or not it intends to.

## How a vote market works

Every vote market has three roles:

- **The venue** — the marketplace contract (Votium, Hidden Hand, Warden Quest) that escrows incentives and distributes them after a vote.
- **The briber / incentive-poster** — a protocol (or DAO treasury) that deposits a reward and names the gauge or proposal it wants votes for. On Votium, bribers post to a [biweekly round](https://docs.votium.app/explainers/briber-manual) that runs while the Convex gauge proposal is live.
- **The voter** — a token-holder who either votes manually for the incentivised option or, far more commonly, _delegates_ to the venue, which allocates their vote to whichever option pays the most and airdrops them the proceeds ([Votium vlCVX FAQ](https://docs.votium.app/faq/vlcvx-faq)).

The delegation step is what turns a scattered electorate into a liquid, auction-clearing bloc: the venue aggregates thousands of small holders and sells their combined weight to the highest bidder each round. Voters do no work and simply collect a yield on tokens they were already locking.

## The major venues

- **[Votium](https://votium.app/)** — the canonical Curve-wars marketplace, built around [Convex](/wiki/daos/lending/convex-finance)'s vlCVX. Rounds run on the Convex gauge cadence — biweekly, Thursday to Tuesday — and delegators are auto-allocated to the best-paying gauges ([voter manual](https://docs.votium.app/explainers/voter-manual)).
- **[Hidden Hand](https://hiddenhand.finance/)** — a multi-protocol "governance incentives marketplace" built by [Redacted](https://mirror.xyz/0xE90c74145245B498fef924fAdC7bb34253c7cF90/Lf-yrb7Q1bHt0tk1OI2VXlevhnZA5Xq2Z215WOLmIx0) that runs bribe markets for Aura, Balancer, Frax and others from one interface, positioning bribery as a routine emissions-marketing channel rather than a fringe tactic.
- **[Paladin](https://paladin.vote/)** — whose [Quest](https://web.archive.org/web/20260607055132/https://docs.paladin.vote/quest-v2/creating-a-quest/fixed-quests) (formerly Warden Quest) offers _fixed-price_ incentives: a buyer sets an exact reward-per-vote and a vote target, so both sides know the rate in advance instead of bidding into an open auction ([Paladin docs](https://web.archive.org/web/20260607041413/https://docs.paladin.vote/), archived June 2026). Paladin also runs governance _lending_ pools, letting a proposer borrow raw voting power for a single vote — the most literal form of renting control.

## The economics: renting votes

Vote markets are efficient precisely because they are cheap for the buyer. Through much of the Curve wars, a protocol could direct _more than a dollar_ of emissions to its pool for _less than a dollar_ of incentives — a positive "bribe efficiency" that made renting votes strictly cheaper than earning them by buying and locking the token outright ([Votium](https://docs.votium.app/general-information/why-votium)). For the voter, the incentive frequently exceeded the value of the emissions their own tokens would have earned passively, so delegating to a vote market became the default yield strategy for ve-lockers.

The result is a clean separation of two things that token-voting is supposed to bundle together: **economic exposure** (holding the token and its cash-flows) and **control** (deciding where the protocol's money goes). In a healthy vote market these can be leased apart by the week.

## Criticisms and risks

The same separation that makes vote markets efficient is what makes them contentious:

- **Cash-flow rights decouple from control.** A buyer can steer emissions without holding a meaningful long-term stake, and a locker can sell control while keeping upside — the classic "empty voting" problem that governance scholars flag as a core weakness of tokenised voting rights ([Vote Delegation in DeFi Governance](https://arxiv.org/pdf/2503.11940)).
- **Rent extraction and plutocracy.** Concentrated holders and aggregators capture most of the bribe flow, reinforcing the whale-dominance already documented in [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) ([Who controls DAOs?](https://www.sciencedirect.com/science/article/pii/S2096720924000216)).
- **Short-termism.** Because rounds clear weekly, capital chases the highest immediate bribe rather than the protocol's long-run health — a recurring thread in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).
- **Governance capture.** A well-funded actor can rent a majority for a single decisive vote — a treasury raid, a fee switch, a parameter change — without ever committing to the protocol it is voting on. Vote markets make the price of temporary capture explicit and low.

Defenders counter that a transparent, on-chain bribe is strictly better than the alternative it replaces: an opaque one. Formalising the vote market at least puts the price of influence on a public ledger where everyone can see it.

The intuitive counter – hide the ballots – does not work either. The shielded voting DAOs actually deploy decrypts and publishes every vote the moment the proposal closes, which leaves the proof of delivery a briber needs perfectly intact; only receipt-freeness removes it, and no DAO runs receipt-free voting at scale ([private and shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting)).

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does not try to outlaw vote-buying — a public chain cannot — but it changes what a rented majority can actually take. Two design choices do the work:

- **Voting weight is not just a bag.** A member's weight is the product of the governance tokens they hold _and_ the vote tokens they have earned, normalised by the totals of each ([voting mechanisms](/wiki/governance/voting-mechanisms)). Buying tokens alone does not hand you control; a big bag by itself cannot capture a decision, which raises the cost of renting an outcome.
- **The minority can exit with its share.** If a coalition does win a vote, every outvoted member can leave and withdraw their canonical share of the treasury on the way out ([the exit right](/blog/the-exit-right)). Renting a majority to loot a treasury is self-defeating: the value you voted to capture walks out the door with the members you outvoted.

The point is not that a caper prevents vote markets from forming — it is that the prize at the end of a captured vote is smaller and more fragile than in a standard emissions DAO, so the market has less to bid for.

## Vote-escrow tokenomics (veTokenomics)

URL: https://caper.network/wiki/dao-governance/concepts/voting/vote-escrow
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Concept** | Vote-escrow tokenomics (veTokenomics) |
| **Introduced by** | Curve Finance ([veCRV](https://curve.readthedocs.io/dao-vecrv.html), 2020) |
| **Core idea** | Governance power from _locking_ a token over time, not merely holding it |
| **Signature conflict** | The "Curve wars" — protocols competing to accumulate locked votes |
| **Also seen as** | veBAL, veFXS, vlCVX, ve(3,3) |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics), [Curve DAO](/wiki/daos/dexs/curve-dao), [Convex Finance](/wiki/daos/lending/convex-finance) |

**Vote-escrow tokenomics** — often shortened to **veTokenomics** — is a governance design in which a member's influence is derived from _locking_ a protocol token for a fixed period rather than simply holding it. The longer the lock, the more voting weight the token confers, and that weight decays as the lock runs down. Pioneered by [Curve Finance](/wiki/daos/dexs/curve-dao) with its vote-escrowed CRV ([veCRV](https://curve.readthedocs.io/dao-vecrv.html)) in 2020, the model became one of the most widely copied and most contested patterns in decentralized governance, spawning the multi-year "Curve wars" and an entire secondary economy of vote-buying.

## What "vote-escrow" means

In a plain [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) DAO, one liquid token equals one vote, and a holder can sell the instant a vote closes. Vote-escrow breaks that by asking members to **commit**: they lock the token into a contract for a chosen duration and receive a non-transferable balance (veCRV, veBAL, and so on) that represents their voting power. Because the lock is time-bound, the design rewards long-horizon alignment over mercenary capital — a holder who locks for the maximum term signals they intend to live with the consequences of their votes.

The trade-off is **illiquidity**: locked tokens cannot be sold or moved for the duration, and the ve-balance itself is soulbound to the locking account. This is the central tension of the model — it manufactures commitment at the cost of composability, and much of what followed was the market's attempt to route around that illiquidity.

## The core mechanics

Using Curve's veCRV as the canonical implementation ([Curve Resources](https://curve.readthedocs.io/dao-vecrv.html)):

- **Locking and decay.** CRV can be locked for a minimum of one week and a maximum of four years. One CRV locked for the full four years yields one veCRV; the veCRV balance then _decays linearly_ toward zero as the unlock date approaches, so members must re-lock to maintain weight.
- **Gauge weight votes.** veCRV holders vote weekly on "gauge weights" that decide how the protocol's CRV emissions are split across liquidity pools. This is the prize: whoever controls veCRV controls where fresh incentives flow. Updated weights are applied every Thursday at 00:00 UTC.
- **Reward boost.** Locking also boosts a member's own liquidity-provision rewards by up to 2.5×, giving large liquidity providers a direct economic reason to lock.

The result is a flywheel: emissions are valuable, veCRV directs emissions, so acquiring veCRV becomes the highest-leverage move in the ecosystem.

## The Curve wars and the liquidity-layer stack

Because directing emissions was so valuable – and because [the size of the emission itself was on no ballot](/wiki/dao-governance/concepts/treasury/emissions-without-a-vote) – protocols began racing to accumulate veCRV — the competition that became known as the **Curve wars**. The decisive escalation was [Convex Finance](/wiki/daos/lending/convex-finance), which let users deposit CRV and capture veCRV's benefits _without_ personally committing to a four-year lock. Convex rapidly became the single largest veCRV holder, at times controlling roughly half of all veCRV.

Convex then handed the gauge-voting decision to holders of its own token who locked it as **vote-locked CVX** ([vlCVX](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx/vote-locking)) for a minimum of 16 weeks. The war moved up a layer: rather than buying CRV directly, protocols competed to control vlCVX, since each unit of vlCVX steered several veCRV worth of gauge votes. A ve model designed to lock in commitment had, in practice, grown a liquid market _on top of itself_ for renting that commitment.

## Vote markets and bribes

Once gauge votes had a clear cash value, third parties built dedicated [vote markets](/wiki/dao-governance/concepts/voting/vote-markets) to price them openly. On platforms like [Votium](https://votium.app/), a protocol that wants emissions routed to its pool posts an incentive ("bribe"), and vlCVX or veCRV holders who vote as directed collect it each round. At peak cycles these vote-incentive budgets reached eight-figure sums per week.

Bribe markets are the model's most debated outcome. Defenders argue they are simply an efficient, transparent price for governance influence — emissions go to whoever values them most, and lockers are compensated. Critics counter that they complete the model's drift from "aligned long-term stewardship" to "governance as a rentable commodity," a live example of the [governance-capture failure modes](/wiki/dao-governance/concepts/analysis/how-daos-fail) that recur across DAOs.

## Adoption beyond Curve

The ve model was copied widely, each variant tuning the lock terms:

- **[Balancer](/wiki/daos/dexs/balancer-dao) — veBAL (abandoned 2026).** Balancer ran the shorter-lock variant — an 80/20 BAL/WETH pool token locked for up to one year ([Balancer docs](https://docs.balancer.fi/concepts/governance/veBAL/)) — but [abolished veBAL in 2026](/wiki/daos/dexs/balancer-dao), replacing locked weight with plain BAL voting after meta-governance wrappers came to dominate the gauge, a textbook instance of the capture critique below.
- **[PancakeSwap](/wiki/daos/dexs/pancakeswap) — veCAKE (retired 2025).** BNB Chain's flagship DEX launched veCAKE and gauge voting in late 2023, then reversed course under [CAKE Tokenomics 3.0](https://forum.pancakeswap.finance/t/cake-tokenomics-proposal-3-0-true-ownership-simplified-governance-and-sustainable-growth/1237) in April 2025 — scrapping the lock, gauges, and revenue-sharing to return to plain CAKE voting and a deflationary buy-back model, another large DEX judging the ve machinery not worth its complexity.
- **[Frax](/wiki/daos/stablecoins/frax-finance) — veFXS.** Frax adopted a veFXS lock (up to four years) to govern gauge emissions across its stablecoin and AMO system.
- **ve(3,3).** Andre Cronje's Solidly fused Curve's vote-escrow with OlympusDAO's (3,3) staking so that lockers earn the fees of the pools they vote for — the design later carried into [Aerodrome](/wiki/daos/dexs/aerodrome-finance) **[Helium](/wiki/daos/networks/helium) — veHNT on a DePIN.** The People's Network applies vote-escrow outside DeFi entirely: HNT lockers hold non-transferable veHNT positions (six months for 1× up to four years for 100×) and delegate them to the IOT or MOBILE subnetworks, tying governance weight to physical-network build-out rather than a liquidity gauge.

## Trade-offs and critiques

- **Alignment vs. plutocracy.** Locking rewards conviction, but weight still scales with capital — a whale who locks simply becomes a locked whale. veTokenomics tempers, rather than removes, the [one-token-one-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) concentration problem.
- **Illiquidity gets arbitraged away.** The commitment the lock is meant to enforce is exactly what liquid wrappers (Convex, Aura, StakeDAO) and vote markets exist to undo.
- **Bribes can outweigh conviction.** When voting to the highest bidder pays more than voting for protocol health, gauge outcomes can diverge from what long-term holders would choose — the concern that motivates alternatives like [conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting).

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) shares vote-escrow's goal — reward participation, not passive size — but reaches it without a lock or a tradeable weight. A caper mints a **soulbound vote token** each time you actually cast a ballot, and your influence is the [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)`: your governance-token stake `t` multiplied by your earned vote tokens `v`, over the totals. Because the `v` factor is earned by voting and cannot be transferred between holders, there is nothing for a Convex-style wrapper to accumulate and no vote to sell on a bribe market — the thing that made ve weight rentable simply does not exist.

The same number that sets your voting power also sets your [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) redemption from the treasury, so influence and skin-in-the-game are one quantity rather than two markets. A large token bag alone still can't capture a caper: without the earned, unbuyable vote record, its weight stays low. See [voting](/wiki/governance/voting) and [what is a caper](/wiki/foundations/what-is-a-caper).

## Voting and delegation in DAOs

URL: https://caper.network/wiki/dao-governance/concepts/voting/voting-and-delegation
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | Handing your voting power to a representative |
| **Solves** | Voter apathy — most token holders never vote |
| **Forms** | Direct delegation · self-delegation · liquid (transitive) democracy |
| **Chief risk** | Delegate cartels — power re-concentrating in a few addresses |
| **Related** | [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) |

**Delegation** is the mechanism that lets a token holder assign their voting power to another address — a _delegate_ — who then votes on their behalf. What that delegate owes in return, and what happens when they stop voting without returning the weight, is covered in [delegate accountability and dormant delegates](/wiki/dao-governance/concepts/voting/delegate-accountability). It is the single most common answer to the defining problem of [token-weighted governance](/wiki/dao-governance/concepts/voting/token-weighted-voting): most holders never vote, so without delegation a handful of active whales decide everything and quorums fail. By concentrating dispersed, apathetic weight onto engaged representatives, delegation is what lets large [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) reach quorum at all.

## Why delegation exists

Voter turnout in major DAOs is chronically low — most governance tokens sit in wallets that never cast a vote, whether from apathy, gas costs, or the sheer effort of evaluating every proposal. Delegation lets those holders stay passive without their weight going to waste: they hand it to someone who _will_ read the forum, follow the technical debate, and show up for every vote. Some frameworks make this mandatory — under [Compound's Governor](https://docs.compound.finance/governance/), COMP confers no voting power until it is delegated, so even holders who want to vote themselves must first **self-delegate** (see [voting power activation and delegation thresholds](/wiki/dao-governance/concepts/voting/voting-power-activation) for what that step does to the size of the electorate). ([a16z crypto: DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## How delegation works

A holder picks a delegate and signs a delegation; from then on their weight counts toward whatever that delegate votes, at the balance they hold when each proposal snapshots. Crucially, delegation is **non-custodial and revocable** — the delegate never touches the tokens, and the holder can re-delegate to someone else or take their weight back at any time, overriding the delegate on a specific vote if they disagree.

Around this primitive an entire layer has grown up: delegates publish **delegate statements** — platforms and voting histories — and holders browse and compare them on tools like [Tally](https://www.tally.xyz/) and [Boardroom](https://boardroom.io/). [ENS](https://docs.ens.domains/dao/) built its DAO delegation-first, encouraging every token holder to pick a delegate at claim time.

Cosmos SDK chains invert the default entirely. On the [Cosmos Hub](/wiki/daos/networks/cosmos-hub) and every chain running its `x/gov` module, a delegator who does not vote **automatically inherits their validator's vote**; voting yourself simply overrides it. Delegation there is not something a holder opts into for governance, it is a side effect of staking for yield, and it means an inactive balance is counted as a vote rather than as an abstention. That single default is why Cosmos turnout figures are not comparable to the ones quoted for opt-in delegation DAOs.

[SafeDAO](/wiki/daos/infrastructure/safe-dao) runs a comparable delegate system and pushes further on the incentive side: its ongoing [Outcomes-Based Resource Allocation (OBRA)](https://forum.safe.global/t/sep-32-obra-continuation-of-governance-accessibility-and-participation-enhancement-at-safedao-stablelab/5381) track pays active delegates and working groups against measurable results — an explicit attempt to keep representatives engaged rather than absentee, since an unpaid delegate is as prone to apathy as the holders who delegated to them.

## Liquid democracy and its cartels

When delegates can themselves re-delegate, delegation becomes **transitive** — a chain of trust that ends at whoever is actually voting. This is _liquid democracy_: a fluid middle ground between direct democracy (everyone votes) and representative democracy (fixed officials), where any holder can be a passive voter, an active voter, or a delegate, and can switch roles at will.

The flexibility has a cost. Delegation re-concentrates power: in practice a handful of large delegates end up controlling a majority of the active vote, so a low-turnout DAO can be captured by a **delegate cartel** coordinating across proposals — the pattern behind on-market governance raids like [the Compound 'Golden Boys' incident](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks). Delegation fixes apathy but does not, by itself, fix [plutocracy](/wiki/dao-governance/concepts/voting/token-weighted-voting); it can sharpen it. ([Fritsch et al., 'Analyzing Voting Power in Decentralized Governance'](https://arxiv.org/abs/2505.04136))

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has **no member-to-delegate system**: every member [votes their own ranked ballot directly](/wiki/governance/voting), and voting weight is the product of a member's stake _and_ their earned participation, not a balance that can be assigned away. That deliberately trades the expertise and higher turnout delegation buys for immunity to delegate cartels — there is no aggregated voting bloc to capture, because there are no delegates. The one delegation-like primitive is the [VOTE proposal](/wiki/governance/proposals): a caper first decides _as a body_ how to vote, then casts that pre-committed ballot inside another caper — organization-to-organization delegation, resolved by its own members rather than handed to an individual.

## References

- a16z crypto, [Lightspeed Democracy: what web3 organizations can learn from the history of governance](https://a16zcrypto.com/posts/article/governance-faq/).
- Compound, [Governance documentation](https://docs.compound.finance/governance/) (delegation-to-vote requirement).
- ENS, [ENS DAO documentation](https://docs.ens.domains/dao/).
- Tally, [delegate directory and voting platform](https://www.tally.xyz/).
- Fritsch, Müller & Wattenhofer, [Analyzing Voting Power in Decentralized Governance](https://arxiv.org/abs/2505.04136) (arXiv, 2025).

## Voting power activation and delegation thresholds

URL: https://caper.network/wiki/dao-governance/concepts/voting/voting-power-activation
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | Which tokens are eligible to count as votes at all |
| **Activation step** | Delegation – including self-delegation – under ERC-5805 / `ERC20Votes` |
| **The three denominators** | Total supply · delegated supply · votes cast |
| **Thresholds it gates** | Proposal submission · quorum · delegate eligibility |
| **Chief failure** | A quorum priced against supply that structurally cannot vote |
| **Related** | [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation), [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design), [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) |

**Voting power activation** is the step between owning a governance token and being able to vote with it. In the dominant on-chain governance stack, the two are not the same thing: a balance sitting in a wallet confers no voting power until its owner performs an explicit on-chain action – a delegation, usually to themselves. Until then the tokens are inert. They appear in every supply chart, every "% of supply held by the community" statistic and every market cap, and they cannot move a single proposal.

This page covers the supply-side arithmetic that follows from that: how activation works mechanically, why it turns a DAO's electorate into a number distinct from its supply, and how the **delegation thresholds** built on top – the minimum voting power to submit a proposal, to reach quorum, or to be listed as a delegate – are all measured against that smaller number. [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) covers the social half: who to delegate to, how delegate markets form, and how they re-concentrate. This is the half underneath it.

## Holding is not voting

The pattern originates in Compound's [`Comp` token](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol), was generalised by OpenZeppelin's [`Votes`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/Votes.sol) module, and is now standardised as [ERC-5805](https://eips.ethereum.org/EIPS/eip-5805), the interface OpenZeppelin's implementation declares. Its own source comment states the rule without hedging: voting units _must_ be delegated in order to count as actual votes, and an account has to delegate to itself if it wants to participate and has no representative it trusts.

The mechanism is a bookkeeping decision. A token contract that tracked voting power on every balance would have to write a checkpoint on every transfer, for every holder, forever. Instead these contracts keep two separate ledgers: balances, and a per-delegate checkpoint history. Transfers move balances always, and move _votes_ only between the delegates the two parties have nominated. In Compound's token, `_moveDelegates` skips the source leg when the sender has no delegate and skips the destination leg when the receiver has none – so tokens moving between two never-delegated wallets change no vote count anywhere. [OpenZeppelin's `ERC20Votes`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol) says the same in its header: by default token balance does not account for voting power, which makes transfers cheaper, at the cost of requiring holders to self-delegate to activate checkpoints.

The consequence is that a DAO's real electorate is not its holder set. It is the subset of holders who have signed one extra transaction – and since that transaction costs gas, produces nothing visible, and is easy to mistake for "giving someone else your tokens", a large share of any airdropped or exchange-held supply never takes it. Exchange-custodied balances in particular are almost never delegated on the beneficial owner's behalf.

## Activation is a deadline, not a switch

Because voting power is stored as a timestamped checkpoint history, every proposal reads it at a fixed past point – the snapshot. Delegating _after_ that point does not retroactively create weight for that proposal. A holder who notices a contentious vote and self-delegates in response has activated for the next proposal, not the one they were reacting to.

This is deliberate. Checkpointing at a past block is the standard defence against flash-loan governance attacks and against double-voting by transferring tokens between wallets mid-vote – OpenZeppelin's module documents exactly that motivation. But it converts activation from a thing you can do when it matters into a thing you had to have done already, which is a much weaker prompt. It is one reason turnout responds so poorly to controversy: by the time a proposal is controversial, the electorate for it is closed. See [the DAO proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) for where the snapshot sits in the sequence.

## Three denominators, three different electorates

Once activation exists, a DAO has at least three defensible answers to "how big is the electorate", and governance frameworks pick different ones – usually by inheritance rather than by decision.

- **Total supply.** OpenZeppelin's [`GovernorVotesQuorumFraction`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol) computes quorum as `getPastTotalSupply(timepoint) × numerator / 100`. That total is checkpointed in `Votes` only on mint and burn – delegation never touches it. So the stock configuration measures quorum against the whole supply while the votes that can satisfy it come only from the delegated part.
- **A fixed constant.** Compound's [Governor Bravo](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) hard-codes `quorumVotes = 400000e18`, annotated in the source as 4% of COMP. It does not move with supply or with delegation at all, which makes it predictable and makes it drift out of calibration as either changes.
- **Delegated supply.** The [Arbitrum DAO Constitution](https://docs.arbitrum.foundation/dao-constitution) defines two terms rather than one: _Votable Tokens_ are all ARB in existence excluding Foundation-held tokens and unclaimed airdrops, and _Delegated Votable Tokens_ are the Votable Tokens that have actually been delegated. Quorum is a fraction of the second – 50% of Delegated Votable Tokens for a Constitutional AIP, 40% for a non-Constitutional one.

The first option has an arithmetic problem that is easy to state and rarely stated. If 40% of a token's supply has never been delegated, a nominal 4% quorum is really asking for 4/60 – about 6.7% – of the tokens that are capable of voting. The bar is harder than the number printed on it, by a factor nobody voted for, that changes whenever holders delegate or undelegate.

The third option has the mirror problem, which is why Arbitrum's constitution does not use the percentage alone. A quorum denominated in delegated supply _falls_ when delegation falls, so an exodus of delegates would quietly make proposals easier to pass. The constitution caps and floors the result: the Constitutional quorum is pinned at 150,000,000 tokens if half of delegated supply comes out below that, and capped at 450,000,000 above it, with a 100,000,000 / 300,000,000 pair for non-Constitutional AIPs. Those bounds exist precisely because the denominator is the kind of number that can collapse. This is the same design question [quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) treats from the quorum side.

## Delegation thresholds: the bar to speak

Activation also gates the right to _propose_, and proposal thresholds are measured in delegated votes rather than in tokens held. Compound's Governor Bravo checks `comp.getPriorVotes(msg.sender, block.number - 1) > proposalThreshold` before accepting a proposal – a lookup into the delegate checkpoint history, not the balance mapping. Its configurable range is bounded in the source at `MIN_PROPOSAL_THRESHOLD = 1000e18` and `MAX_PROPOSAL_THRESHOLD = 100000e18`, so the governor can never be set to accept proposals from an address with no delegated weight at all, and can never demand more than 100,000 COMP.

Arbitrum sets the same kind of bar at both ends of its process: an on-chain AIP requires a proposer address **delegated at least 1,000,000 Votable Tokens**, and even the optional off-chain temperature check requires an address that can vote at least 0.01% of Votable Tokens. A holder of a million ARB who has never delegated to themselves cannot open a proposal – not because they lack tokens, but because the contract cannot see them.

The practical effect is that proposal rights concentrate faster than token ownership does. A threshold set at some fraction of supply is met by a much smaller number of addresses once you count only delegated weight, and it is met almost exclusively by professional delegates who have accumulated others' power. That is the supply-side reason DAO agendas are set by a short list of names; it is not only that most holders do not care, it is that most holders are not eligible to put anything on the agenda.

## The same DAO can have two electorates at once

Most DAOs run an off-chain signalling vote before an on-chain execution vote, and the two venues often do not count the same thing. [Snapshot's voting strategies](https://docs.snapshot.box/user-guides/voting-strategies) are configured per space, and the default is `erc20-balance-of`, which reads a raw ERC-20 balance. A separate `erc20-votes` strategy exists specifically to read _delegated_ balances instead, and a `delegation` strategy layers delegation on top of any other.

A DAO that leaves the default in place and then executes through an on-chain Governor is therefore polling one electorate and binding a different, smaller one. Never-delegated tokens carry full weight in the temperature check and zero weight in the vote that actually moves funds. Snapshot also runs [its own native delegation](https://docs.snapshot.box/user-guides/delegation), separate again from the token contract's, so a holder can be delegated in one venue and not the other. None of this is hidden – it is all in the space settings – but it is rarely reconciled, and it is a standing source of the gap between a signal vote that passed comfortably and an on-chain vote that failed quorum.

## Failure modes

- **Inert supply read as decentralisation.** Distribution statistics count holders; governance counts delegates. A DAO can report broad token ownership and still have an electorate of a few hundred addresses. Any comparison of DAOs on "% of supply held by the community" is measuring something that governance does not use.
- **A quorum nobody re-priced.** A percentage-of-supply quorum inherited from a template, applied to a token where a large fraction has never activated, is a stricter bar than its number suggests – and it tightens further with every new holder who does not delegate. See [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) for the participation half of the same failure.
- **Reactive activation arrives too late.** The snapshot means the response to a contentious proposal cannot affect it. Campaigns that successfully mobilise holders routinely mobilise them into the following vote.
- **Delegated power without a live delegate.** Delegation does not expire. Weight assigned to a delegate who has stopped voting is worse than undelegated weight: it is counted in the delegated-supply denominator, so it raises a delegated-supply quorum, while never voting. A dormant delegate is a quorum tax; see [delegate accountability and dormant delegates](/wiki/dao-governance/concepts/voting/delegate-accountability) for the mechanisms DAOs have deployed against it.
- **Threshold capture.** When proposal rights require delegated weight that only a handful of addresses hold, the set of people who can put a question to the DAO is decided by the delegation market rather than by the token distribution. See [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting).

## How Caper approaches this

Caper has no delegation primitive, so there is nothing to activate by signing – but the eligibility question does not disappear, and its answer is unusual enough to be worth stating plainly.

Casting a ballot requires a proof of at least one of that caper's tokens; holding is the entry ticket. Weight is then the product of two factors read at vote time: the ballot records the voter's token balance and their balance of that caper's **soulbound vote token**, and weight is computed as those two multiplied and divided by the vote-token supply and the token's circulating supply. Voting mints exactly one vote token to the voter, and that mint is the only way vote tokens are ever created.

Two consequences follow directly. First, the vote-token balance is read _before_ the ballot's own mint, and weight is zero when that balance is zero – so a member's first ballot is recorded and counts for nothing; it buys the token that gives their second one weight. Activation exists, and you activate by participating rather than by delegating. Second, holdings are a multiplicative factor rather than the whole story: a large balance with no participation history multiplies by zero, and a long participation history with no holdings does too. Neither leg carries a vote alone.

What this does not do is solve the denominator problem described above – it relocates it. Caper's denominator is the token's circulating supply, which is knowable on-ledger rather than dependent on how many holders remembered to sign something. See [Voting](/wiki/governance/voting) for the mechanics and [what is a caper](/wiki/foundations/what-is-a-caper) for the surrounding model.

## References

- [OpenZeppelin Contracts – `governance/utils/Votes.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/Votes.sol) (the delegation requirement and the total-supply checkpoint)
- [OpenZeppelin Contracts – `ERC20Votes.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol) (self-delegation to activate checkpoints)
- [OpenZeppelin Contracts – `GovernorVotesQuorumFraction.sol`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotesQuorumFraction.sol) (quorum as a fraction of past total supply)
- [Compound – `Comp.sol`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) (`_moveDelegates` and the zero-address skip)
- [Compound – `GovernorBravoDelegate.sol`](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) (quorum constant and proposal-threshold bounds)
- [The Arbitrum DAO Constitution](https://docs.arbitrum.foundation/dao-constitution) (Votable Tokens, Delegated Votable Tokens, quorum floors and caps)
- [Snapshot docs – Voting strategies](https://docs.snapshot.box/user-guides/voting-strategies) and [Delegation](https://docs.snapshot.box/user-guides/delegation)
- [ERC-5805: Voting with delegation](https://eips.ethereum.org/EIPS/eip-5805)

## The DAO tooling stack

URL: https://caper.network/wiki/dao-governance/tooling/dao-tooling-overview
Updated: 2026-08-05

|  |  |
| --- | --- |
| **What this is** | A map of the DAO operating stack — the software categories a DAO wires together to run |
| **Core layers** | Voting · frameworks · treasury custody · funding · contributor comp · analytics · legal wrappers |
| **Design reality** | No single app runs a DAO; most assemble best-of-breed tools around a [Safe](/wiki/dao-governance/tooling/treasury/safe) treasury and a [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) |

Running a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) is not one product but a **stack**: a set of specialised tools, mostly independent of each other, that a community assembles to make decisions, hold money, pay people, control who takes part and stay legible. There is no “DAO operating system” that does all of it — instead a typical DAO layers a voting venue over a treasury wallet, bolts on funding and payroll modules, and points analytics and legal wrappers at the result. This page maps that stack by function and links to the deep page for each tool, so you can see how the pieces fit before diving into any one of them.

## Voting & signaling

Before any of it, there is the **deliberation layer**: the forum where a proposal is drafted, argued and often killed. Most DAOs run a self-hosted [Discourse](https://www.discourse.org/); [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth) is the crypto-native alternative, adding wallet login, token-gated topics and a two-way [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) integration — though it has since turned toward token launches, and the deliberation layer remains the least standardised part of the stack.

The layer that turns members into decisions. **[Snapshot](/wiki/dao-governance/tooling/voting/snapshot)** is the near-universal _off-chain_ venue — gasless, wallet-signed votes stored on IPFS — used for temperature checks and non-binding signaling. **[Tally (now Cactus)](/wiki/dao-governance/tooling/voting/tally)** covers the _on-chain_ side, providing the interface for [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) contracts where a passed vote executes a transaction directly. [Agora](/wiki/dao-governance/tooling/voting/agora) is the other major on-chain interface, running binding votes for Optimism, Uniswap and ENS. Most large DAOs run both layers: cheap Snapshot signaling first, binding on-chain execution second. A related layer resolves _subjective_ disputes a vote cannot settle — did the work ship, is this listing genuine — through decentralized arbitration such as [Kleros](/wiki/dao-governance/tooling/voting/kleros), whose crowdsourced jurors return a binding ruling that a contract can act on. ([Snapshot docs](https://docs.snapshot.box/), [Tally docs](https://docs.tally.xyz/))

## Access & identity

Deciding _who is in the room_ before any vote is cast. **[Guild](/wiki/dao-governance/tooling/membership/guild-xyz)** is the widely-used authorization layer: it turns an on-chain fact — hold this token or NFT, complete this action — into an off-chain permission, automatically granting and revoking [Discord roles, Telegram access, and GitHub or Google permissions](https://docs.guild.xyz/guild/how-guild-works) as wallets meet or fall out of a role's requirements. It is the plumbing behind most token-gated communities, including social DAOs like [Friends With Benefits](/wiki/daos/social/friends-with-benefits), and pairs with [proof-of-personhood](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) signals such as [Human Passport](/wiki/dao-governance/tooling/membership/human-passport) to keep one person from entering as many. This layer governs access, not vote weight — it decides who may participate, while the voting and framework layers decide what that participation does.

## Frameworks

The scaffolding that defines what a DAO _is_ on-chain — its permissions, membership and upgrade rules. **[Aragon OSx](/wiki/dao-governance/tooling/frameworks/aragon)** models a DAO as a lean permission manager with swappable governance plugins. The **Moloch** framework — minimal, audited contracts whose defining feature is [rage-quit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — underpins a generation of grants DAOs and lives on today through [DAOhaus](/wiki/dao-governance/tooling/frameworks/daohaus). [Colony](/wiki/dao-governance/tooling/frameworks/colony) adds reputation-weighted, task-based structure — influence is earned reputation that decays, not tokens held. Frameworks trade flexibility for safety: you inherit battle-tested contracts instead of writing your own. [Hats Protocol](https://docs.hatsprotocol.xyz/) narrows this layer to roles and permissions alone: revocable, non-transferable ERC-1155 "hats" arranged in an admin tree, read by tools like [Safe](/wiki/dao-governance/tooling/treasury/safe) and [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) to gate who may act ([Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol)). ([Aragon docs](https://docs.aragon.org/), [Moloch contracts](https://github.com/MolochVentures/moloch))

## Treasury & custody

Where the money actually sits. **[Safe](/wiki/dao-governance/tooling/treasury/safe)** (formerly Gnosis Safe) is the default: an _m_-of-_n_ multisig smart-contract wallet that holds the treasury for most of the DAO world, extended by modules and guards — most commonly the [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) standard — so a passed [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote can execute against it without a trusted signer. Because Safe stayed deliberately minimal, a separate operations layer grew above it: [Den](/wiki/dao-governance/tooling/treasury/den) adds no contracts at all and instead attacks the coordination bottleneck — reminder bots that tag signers who have not yet signed, decoded and simulated transactions, and gas reimbursed from the Safe. Custody is the highest-stakes layer — a treasury is a DAO’s most valuable and most attacked asset — which is why the ecosystem standardised hard on one well-audited account model. ([Safe docs](https://docs.safe.global/))

## Funding & contributor comp

Getting money _in_ and back _out_ to the people doing the work. **[Juicebox](/wiki/dao-governance/tooling/treasury/juicebox)** is the programmable treasury/fundraising layer that powered ConstitutionDAO and thousands of crowdfunds. [Gitcoin](https://www.gitcoin.co/) runs [quadratic-funding](/wiki/daos/public-goods/gitcoin-dao) rounds for public goods. **[Coordinape](/wiki/dao-governance/tooling/treasury/coordinape)** pioneered peer-allocated compensation — contributors reward each other’s work directly — though its app wound down in 2025. **[Sablier](/wiki/dao-governance/tooling/treasury/sablier)** streams vesting grants, salaries and unlocking airdrops second-by-second, so a payment is earned over time instead of handed over up front. Once the work is done, the invoice and the books are their own layer: **[Request Finance](/wiki/dao-governance/tooling/treasury/request-finance)** turns contributor and vendor claims into approved bills a multisig pays in a batch, then exports the result to ordinary accounting software. This layer is where governance meets payroll, and it is historically the least standardised part of the stack.

## Analytics & discovery

The instruments that make a DAO legible to its members and to outsiders. The single cross-DAO index has fragmented: **[DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao)** was the canonical directory — treasury sizes, membership and voter turnout across thousands of DAOs — but its public site has been unreachable since mid-2026, and its role is now split across narrower tools. **[Boardroom](/wiki/dao-governance/tooling/analytics/boardroom)**, acquired by [Agora](/wiki/dao-governance/tooling/voting/agora) in 2025, and [Messari Governor](https://messari.io/governor) track live proposals across ecosystems; **[Karma](/wiki/dao-governance/tooling/analytics/karma)** scores delegate participation; **[Token Terminal](/wiki/dao-governance/tooling/analytics/token-terminal)** carries the financial half, standardizing fees, revenue and expenses so protocols can be compared on the same basis; and **[DAOstar](/wiki/dao-governance/tooling/analytics/daostar)** works the layer beneath, standardizing how a DAO publishes its own data. Between them they answer “how healthy is this DAO?” — the metrics covered on [DAO metrics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) and [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## Legal wrappers

The off-chain shell that gives an on-chain organisation legal personhood and limited liability. [MIDAO](/wiki/dao-governance/tooling/analytics/midao) forms Marshall Islands DAO LLCs; Wyoming’s [DAO LLC statute](https://sos.wyo.gov/business/) offers a US equivalent. Without a wrapper, members of an unincorporated DAO can face unlimited personal liability — a risk the [legal-structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) page covers in depth. This layer is optional but increasingly standard for any DAO holding real assets or signing contracts.

## Choosing a stack

The right stack follows the DAO’s _type_ and _size_. A small grants collective may need only a Safe plus Snapshot and a Moloch-style rage-quit. A large protocol DAO governing a live contract needs on-chain Governor execution (Tally/Cactus), a formal legal wrapper, and analytics for accountability. The rule of thumb: start minimal — a treasury and a way to vote — and add layers only when a concrete failure (a captured multisig, an unclear payout, a liability scare) demands one. Over-tooling an early DAO adds coordination cost without adding safety.

Choosing also means choosing what to depend on. Several tools once considered obvious picks in this stack no longer exist, and what a shutdown costs depends on whether the tool held a view of on-chain state or the only copy of the record: see [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity).

## How Caper approaches this

Caper collapses most of this stack into a single protocol. Custody, voting, execution and exit are not separate tools bolted together but one contract-governed flow: a [proposal](/wiki/governance/proposals) is [voted](/wiki/governance/voting) and [executed](/wiki/governance/execution) on-chain in one binding step, the treasury is a protocol-controlled vault rather than a separate [Safe](/wiki/dao-governance/tooling/treasury/safe), and members can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) for a share of it set by their canonical [vote weight](/wiki/governance/voting) `(t·v)/(V·T)` rather than by balance alone, consuming both their governance tokens and the soulbound vote tokens they earned by voting. The trade-off is deliberate: a caper gives up the pick-your-own-tools flexibility of the assembled stack in exchange for having no seams — no multisig to capture, no off-chain vote to later ratify, no gap between deciding and doing. For teams that want the modular approach, the tools above remain the reference.

## References

- Aragon, [OSx documentation](https://docs.aragon.org/).
- Snapshot, [Documentation](https://docs.snapshot.box/); Tally, [Documentation](https://docs.tally.xyz/).
- Safe, [Documentation](https://docs.safe.global/).
- DeepDAO, [DAO analytics directory](https://web.archive.org/web/20260520182310/https://deepdao.io/organizations) (Internet Archive, 20 May 2026).
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/) (Andrew Hall, 2023).

## Boardroom (governance data API)

URL: https://caper.network/wiki/dao-governance/tooling/analytics/boardroom
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Category** | Governance data · API & SDK · [analytics](/wiki/dao-governance/tooling/analytics/deepdao) aggregation |
| **Launched** | 2020 — governance dashboard; [$2.2M seed led by Standard Crypto](https://www.coindesk.com/business/2020/10/13/boardroom-raises-22m-for-blockchain-governance-toolset) (Oct 2020) |
| **Founder** | Kevin Nielsen (now an advisor at [Agora](/wiki/dao-governance/tooling/voting/agora)) |
| **What it does** | Aggregates on-chain and [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) governance across protocols into one API/SDK — a “Bloomberg for crypto governance data” |
| **Coverage** | 2M+ [delegates](/wiki/dao-governance/concepts/voting/voting-and-delegation) across 300+ protocols ([Agora, 2025](https://www.agora.xyz/blogs/6-boardroom-acquisition)) |
| **Owner** | Acquired by [Agora](/wiki/dao-governance/tooling/voting/agora), 23 January 2025 ([CoinDesk](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom)) |
| **Site** | [boardroom.io](https://boardroom.io/) · [API docs](https://docs.boardroom.io/) |
| **Related** | [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) · [Karma](/wiki/dao-governance/tooling/analytics/karma) · [Agora](/wiki/dao-governance/tooling/voting/agora) · [tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Boardroom** is the read layer of DAO governance: not a place you cast a vote, but the API that other apps query to _show_ you the vote. Where an interface like [Agora](/wiki/dao-governance/tooling/voting/agora) or [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally) runs a single DAO's proposals, Boardroom reads across the whole field — on-chain Governor votes and off-chain [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) proposals from 300+ protocols — and serves the normalized result through one API and SDK. CoinDesk described what it became as [a “Bloomberg” for crypto governance data](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom). Launched as a governance dashboard in 2020 (a [$2.2M seed led by Standard Crypto](https://www.coindesk.com/business/2020/10/13/boardroom-raises-22m-for-blockchain-governance-toolset) followed that October), it was acquired by [Agora](/wiki/dao-governance/tooling/voting/agora) in January 2025.

## What Boardroom aggregates

Governance data is fragmented by construction. Every DAO runs its own contracts — a separate [OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/5.x/governance) deployment here, a [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) space there — each with its own address, schema and quirks. To answer a question as simple as “what proposals are open right now across the DAOs I hold” you would otherwise index dozens of contracts yourself. Boardroom does that indexing once and exposes it as a uniform feed: proposals and their states, vote tallies, [delegates](/wiki/dao-governance/concepts/voting/voting-and-delegation) and their voting history, and per-protocol metadata, all through a documented [API and SDK](https://docs.boardroom.io/). Its own figures put coverage at more than two million delegates across 300-plus protocols ([per Agora](https://www.agora.xyz/blogs/6-boardroom-acquisition)).

## From dashboard to data feed

Boardroom did not start as infrastructure. It launched as a user-facing governance dashboard — an [Agora](/wiki/dao-governance/tooling/voting/agora)-style place to browse and track proposals — and [gradually transitioned](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) into a data feed sitting _behind_ other products. That pivot is the whole story: rather than competing for the end-user's attention with every other governance UI, Boardroom became the plumbing those UIs run on, so wallets and governance apps could display proposals and delegate activity without each building its own multi-protocol indexer. It is the difference between selling the newspaper and selling the wire service.

## The Agora acquisition (2025)

On [23 January 2025](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) [Agora](/wiki/dao-governance/tooling/voting/agora) — the on-chain voting platform behind [Optimism](/wiki/daos/networks/optimism-collective), [Uniswap](/wiki/daos/dexs/uniswap-dao) and [ENS](/wiki/daos/infrastructure/ens-dao) — acquired Boardroom, folding a read-side data layer beneath its write-side voting stack. Terms were undisclosed; founder Kevin Nielsen stayed on as an advisor, and Agora's co-founder said [“there's no plan to deprecate”](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) Boardroom, keeping both platforms running while integrating them ([Agora's announcement](https://www.agora.xyz/blogs/6-boardroom-acquisition); [Boardroom's](https://governance.substack.com/p/boardroom-joins-the-agora-governance)). The deal was one marker of a wider 2025–26 consolidation of governance tooling — the same window in which [Tally wound its hosted product down](/wiki/dao-governance/tooling/voting/tally) into Cactus — as a once-crowded vendor field contracted toward a few full-stack providers.

## Where it sits in the stack

It helps to separate the layers. [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) and [Agora](/wiki/dao-governance/tooling/voting/agora)/[Tally](/wiki/dao-governance/tooling/voting/tally) are _write_ surfaces — where a vote is actually cast, off-chain or on. [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) is the discovery-and-treasury dataset (“CoinMarketCap for DAOs”), and [Karma](/wiki/dao-governance/tooling/analytics/karma) scores delegate accountability. Boardroom is the general-purpose _read API_ under all of it: the normalized governance feed a third-party app queries when it wants to render proposals and votes it did not itself index. A DAO doesn't “use Boardroom to govern” so much as the tools around it use Boardroom to stay informed. See the [tooling-stack map](/wiki/dao-governance/tooling/dao-tooling-overview) for how the read and write layers fit together.

## How Caper approaches this

An aggregator like Boardroom is necessary because governance data is scattered across hundreds of independent contracts with no common read surface — someone has to index them all and sell the unified feed. A [caper](/wiki/foundations/what-is-a-caper) narrows that problem at the source: a caper's [proposals](/wiki/governance/proposals), [votes](/wiki/governance/voting) and [execution](/wiki/governance/execution) are native state on the DAO's own on-chain component, so the canonical record of who proposed what and how it resolved is read directly from the ledger, not reconstructed by a third party. That doesn't abolish the case for aggregation — anyone comparing many capers at once would still want an index across them — but it moves the source of truth into the protocol itself, where no vendor's database sits between a member and the state that governs their stake. Read-layer plumbing is still useful; it just isn't where a caper's governance _lives_.

## References

- CoinDesk, [“DAO Governance Platform Agora Acquires Older Competitor, Boardroom”](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) (23 January 2025).
- CoinDesk, [“Boardroom Raises $2.2M for Blockchain Governance Toolset”](https://www.coindesk.com/business/2020/10/13/boardroom-raises-22m-for-blockchain-governance-toolset) (13 October 2020).
- Agora, [“Boardroom joins Agora”](https://www.agora.xyz/blogs/6-boardroom-acquisition); Boardroom, [“Boardroom Joins the Agora Governance Suite”](https://governance.substack.com/p/boardroom-joins-the-agora-governance).
- Boardroom, [Governance API documentation](https://docs.boardroom.io/) · [boardroom.io](https://boardroom.io/).

## DAOstar

URL: https://caper.network/wiki/dao-governance/tooling/analytics/daostar
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Type** | Standards body & public-goods organization for DAOs |
| **Founded** | 2021, as the DAOstar roundtable |
| **Steward** | DAOstar One, fiscally sponsored by [Metagov](https://metagov.org) |
| **Flagship standard** | [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) / DAOIP-2 – Common Interfaces for DAOs (`daoURI`), status **Review** since 2022 |
| **Standards** | DAOIP-1 … DAOIP-10 – interfaces, attestations, grants, security, legal, tax. One Living meta document, one in Review, **eight still Draft** |
| **Current focus** | **OpenGrants** (DAOIP-5 grant data) and **DAO ID** – the two standards the homepage names as of August 2026 |
| **Standards repo** | [metagov/daostar](https://github.com/metagov/daostar) – last commit **31 October 2025** |
| **Backers** | Ethereum Foundation, Optimism, Arbitrum DAO, and others |
| **Related** | [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Giveth](/wiki/daos/public-goods/giveth), [DAO security](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [DAO tooling](/wiki/dao-governance/tooling/dao-tooling-overview) |

**DAOstar** is the standards body for [decentralized autonomous organizations](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao). It writes the technical standards and publishes the research that let DAOs, and the tools built around them, speak a common language. Where [ERC-20](https://eips.ethereum.org/EIPS/eip-20) and [ERC-721](https://eips.ethereum.org/EIPS/eip-721) made _tokens_ interoperable – any wallet or exchange can read any compliant token without bespoke integration – DAOstar set out to do the same for the _organizations_ themselves, so that a DAO's members, proposals, treasury, and rules are legible to any tool without a one-off adapter for every framework.

The problem it addresses is fragmentation. A DAO built on Aragon, one built on a Governor contract, and one running as a Safe multisig each store their membership, proposals, and votes in different shapes. An analytics dashboard, a grants platform, a voting front-end, or a court that wants to read one of them has to reverse-engineer each framework separately. DAOstar's answer is a thin, shared metadata layer that every framework can expose and every tool can consume – the connective tissue of the DAO ecosystem rather than another platform competing inside it.

What that means in practice has shifted. The organization spent 2022–2024 building the general DAO interface, [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824); since 2025 its live engineering, its live infrastructure and its own homepage have been about one narrower thing – **grant data**. The sections below date that shift from the repositories, the deployed services and the standards catalogue rather than from any announcement, because there has not really been one.

## From roundtable to standards body

DAOstar began in 2021 as the **DAOstar roundtable**, a working series convened by [Metagov](https://metagov.org/projects/daostar) that brought the major players in the DAO ecosystem to the same table. The initial drafting of its flagship standard drew representatives from essentially every EVM DAO framework of the day – Aragon, Compound, DAOstack, Gnosis, Moloch, OpenZeppelin, and Tribute – alongside a wide selection of DAO tooling developers and several large DAOs. Getting competitors to agree on a shared interface, rather than each pushing its own, is the whole point of a standards body, and it is what gave the resulting specification its legitimacy.

The effort is stewarded by **DAOstar One** and remains fiscally sponsored by Metagov, the non-profit research collective for decentralized governance. The roundtable grew into a membership program of roughly ninety organizations, and DAOstar's work is backed by ecosystem funders including the Ethereum Foundation, the Optimism Foundation, and Arbitrum DAO. It is deliberately structured as a neutral public good: the standards are open, the process is public on [GitHub](https://github.com/metagov/daostar), and DAOstar sells nothing that would put it in competition with the tools that adopt its work. (The roundtable member-logo section was removed from the homepage in August 2025, so the current membership is no longer published; see below.)

## EIP-4824: a common interface for DAOs

DAOstar's flagship is **[EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824)** (also catalogued as **DAOIP-2**), _Common Interfaces for DAOs_, first drafted in February 2022 by Joshua Tan, Isaac Patka, Ido Gershtein, Eyal Eithcowich, Michael Zargham, and Sam Furter. Its central idea is a single function, `daoURI()`, that a DAO contract exposes – deliberately modelled on the `tokenURI` that NFTs already use. Calling it returns a link to a [JSON-LD](https://json-ld.org) document describing the organization in a standard shape, so any indexer can discover and read a DAO the same way regardless of which framework built it.

Beyond a top-level `name` and `description`, that document points to a handful of subsidiary URIs, each covering one facet of the organization:

- **membersURI** – the DAO's members, identified by [CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md) account addresses or DIDs.
- **proposalsURI** – on- and off-chain proposals, with their status, links to content, and the execution calldata a passed proposal would run.
- **activityLogURI** – a log of how members interact with proposals: votes cast, submissions, disputes.
- **governanceURI** – a human-readable (Markdown) description of the DAO's membership rights and how proposals actually work.
- **contractsURI** – the set of contracts that make up the DAO, potentially spread across several chains.

The payoff is fourfold: **discoverability** (DAOs can be found and listed automatically), **legibility** (their governance is machine-readable), **proposal simulation** (tools can read the calldata a proposal would execute before it passes), and **interoperability** (a voting UI, a treasury dashboard, or an analytics service written once works across every compliant DAO). Registration contracts and reference implementations let existing DAOs adopt `daoURI` without redeploying their core governance – and a companion standard, [DAOIP-6](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-6.md), lets a DAO publish the same metadata through an ENS text record instead of an on-chain registry.

The specification has been status **Review** since it was drafted, and its on-chain registries are the one part of the DAO metadata story that can be counted: thirty `DAOURIRegistered` events across four production chains, roughly eight distinct third-party organizations, and nothing new since February 2025. That census, with the caveats it needs – the index catches only one of three publication routes – lives on the dedicated [EIP-4824 page](/wiki/dao-governance/concepts/analysis/eip-4824).

## The DAOIP series, and the status column nobody reads

New standards move through a **DAO Improvement Proposal (DAOIP)** process – a design-document pipeline, defined in [DAOIP-1](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-1.md) and modelled on Ethereum's own EIP process, for proposing a feature, gathering technical input, and recording the decision in public. The catalogue has grown well beyond the original interface to cover the practical machinery a DAO needs to be legible to the outside world:

|  |  |  |  |  |
| --- | --- | --- | --- | --- |
| **DAOIP** | **Title** | **Status** | **Created** | **What it covers** |
| **DAOIP-1** | Purpose and Guidelines | Living | 2023-01-02 | How the DAOIP process itself works. |
| **DAOIP-2** | Common Interfaces for DAOs | Review | 2022-02-17 | The `daoURI` standard – identical to EIP-4824. |
| **DAOIP-3** | Attestations for DAOs | Draft | 2023-02-03 | An indexing layer over verifiable credentials for permissionless claims about membership and contributions. |
| **DAOIP-4** | Proposal Types | Draft | 2023-02-03 | Standard templates and an extensible taxonomy for classifying proposals. |
| **DAOIP-5** | Grants Management | Draft | 2023-11-14 | A common data model for grant programs – pools, applications, and payouts. The basis of OpenGrants. |
| **DAOIP-6** | daoURI via ENS | Draft | 2024-03-11 | Publishing DAO metadata through an ENS (or DNS) text record instead of a registry contract. |
| **DAOIP-7** | Attestation Schema Registry for EAS | Draft | 2024-04-25 | A registry of DAOIP-3-compliant schemas on the Ethereum Attestation Service. |
| **DAOIP-8** | Recommended Controls for DAOs | Draft | 2024-10-22 | A minimum-viable DAO [security](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) standard – controls across governance, operations, and risk. |
| **DAOIP-9** | Legal Communication | Draft | 2024-11-26 | A `legalURI` for passing legal information to and from communities that lack formal [legal recognition](/wiki/dao-governance/concepts/membership/dao-legal-structures). |
| **DAOIP-10** | Tax Reporting | Draft | 2024-11-29 | A data standard for DAOs to publish tax information for authorities and participants. |

Read together, the series traces the arc of what DAOs have had to grapple with: from simply being _readable_ (DAOIP-2), to proving _who did what_ (DAOIP-3, DAOIP-7), to funding work (DAOIP-5), staying _safe_ (DAOIP-8), and finally meeting the law and the tax office (DAOIP-9, DAOIP-10).

The status column is the part worth reading, and it is easy to miss because every DAOIP carries it in YAML front matter rather than on the rendered page. Read from the repository on **9 August 2026**: DAOIP-1 is _Living_ and is a meta document about the process; DAOIP-2 is _Review_; **DAOIP-3 through DAOIP-10 are all _Draft_**. DAOIP-1 defines no status ladder of its own – it says that "in the absence of additional direction, please follow the norms of the [EIP system](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md)", where the ladder runs Draft → Review → Last Call → Final. On those borrowed norms, nothing in the catalogue has ever passed Review, and the two newest entries have sat at Draft since November 2024.

Two smaller signs point the same way. DAOIP-1 still carries the sentence "As of February 26, 2023, the DAOIP system is currently being specified" – three and a half years unedited. And DAOIP-1 defines exactly two document types, Meta and Standard, but the `type:` field is **empty in the front matter of all ten standards-track documents**; only the meta document fills it in. This is the same shape the [EIP-4824 census](/wiki/dao-governance/concepts/analysis/eip-4824) found one level down, where the interface was adopted and the schema was not: the part of a standard that is mechanically checked gets followed, and the part that is merely written down drifts.

## What DAOstar is building now: grants data

The clearest statement of DAOstar's current priorities is not a blog post, it is the push history of its repositories. Read from the GitHub API on **9 August 2026**: [metagov/daostar](https://github.com/metagov/daostar), the standards repository, was last pushed to on **31 October 2025** – and both of that day's commits were edits to DAOIP-5, the grants schema. Meanwhile [metagov/Grants-Gateway-API](https://github.com/metagov/Grants-Gateway-API) and [metagov/opengrants-platform](https://github.com/metagov/opengrants-platform) were both pushed to on **5 August 2026**, four days before this reading. The standards catalogue has been still for nine months; the grants stack was touched this week.

The website says the same thing more quietly. Two commits on 12 August 2025 – [9c0d46e8, titled "archive daoip2"](https://github.com/metagov/daostar/commit/9c0d46e88d772c26201803c3cd4b4080187a6438), and a follow-up four minutes later – changed the old homepage headline from "The DAO standard" to "The DAO Metadata Specification", commented out the "The DAO Standard" explainer and the roundtable member logos, and renamed the top-nav "Standard" link to "Specification". The site has since been rebuilt again, and the [daostar.org](https://daostar.org) homepage now names exactly two things under _Standards_: [DAO ID](https://daostar.org/daoid), a richer organizational identity model built on top of `daoURI`, and [OpenGrants](https://daostar.org/opengrants), described as "an intelligence layer for Web3 grants". `daoURI` itself is no longer a call to action anywhere on the front page.

The narrowing is toward the more accurate claim, which is worth saying plainly rather than scoring points off: EIP-4824 always standardized the _data about_ DAOs rather than DAOs themselves, and a body that ships one working data standard is more useful than one that maintains eight drafts. But a wiki entry that still called DAOstar "the standards body of DAOs" and stopped there would leave a reader expecting a general interoperability layer that is not currently being built.

## What the live grants stack actually serves

OpenGrants is DAOIP-5 in production, and unlike the catalogue it can be measured directly, because the gateway exposes a public read API at [grants.daostar.org](https://grants.daostar.org) with no key. All figures below were read on **9 August 2026 at 17:11 UTC**.

- [`/api/health`](https://grants.daostar.org/api/health) reports **four adapters, all healthy** – Octant, [Giveth](/wiki/daos/public-goods/giveth), Questbook and SCF (the Stellar Community Fund) – with a healthy database behind them.
- [`/api/v1/grantSystems`](https://grants.daostar.org/api/v1/grantSystems), the DAOIP-5 index itself, returns **three** systems: Octant, Giveth and SCF. Questbook is a healthy adapter that the index does not list.
- Following each system's `grantPoolsURI`: **SCF publishes 48 grant pools**, **Giveth 10**, and **Octant 0** – a healthy adapter returning an empty set.

Fifty-eight pools across two funders is a small corpus, but it is a real one, served in a documented shape from a warehouse that anyone can query – which is more than the `daoURI` registry can say four years after that standard shipped. The pools carry funding sizes in a structured `totalGrantPoolSize` array, so cross-programme comparison is a query rather than a research project; that is precisely the capability the [retroactive public-goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) literature keeps asking for and rarely gets.

Two details reward a closer look. First, every response carries `"@context": "http://www.daostar.org/schemas"` – the same non-resolving context URL the [EIP-4824 registry documents](/wiki/dao-governance/concepts/analysis/eip-4824) use. There is no document at `daostar.org/schemas`; the path returns 404 over both HTTP and HTTPS. A JSON-LD processor that tries to dereference the context to interpret the terms gets nothing, so every consumer is in practice reading the fields by name against the specification text. Second, each system's record carries an `extensions` object keyed by reverse-DNS namespace – `app.octant.systemMetadata`, `io.giveth.systemMetadata`, `org.stellar.communityfund.systemMetadata`. That mechanism comes from [x-daoip-5.md](https://github.com/metagov/daostar/blob/main/DAOIPs/x-daoip-5.md), a specification update sitting outside the numbered series with no DAOIP number, no status and no front matter – the one piece of the catalogue that is unambiguously deployed is also the one piece that was never given a place in it.

## The layer that stopped being operated

EIP-4824's explicit trade was one on-chain function plus a URI, at the cost of trusting whatever service that URI points at to stay available. DAOstar ran several of those services itself, and their current state is the cost being paid. Checked on **9 August 2026** against 1.1.1.1:

- `services.daostar.org` – **no A record and no CNAME**. It is the `membersURI`, `proposalsURI` and `activityLogURI` host for every Ethereum-mainnet registrant in the EIP-4824 index.
- `api.daostar.org` – an A record still resolves, and connections to it time out on both ports.
- `proposalsuri.daostar.org` – returns **503**.
- `daostar.org`, `docs.daostar.org`, `opengrants.daostar.org` and `grants.daostar.org` – all **200**, the last two hosted on Render.

Nothing was hacked and no key was lost. The registry contracts still return exactly what they were written to return, and every on-chain conformance check still passes; the operated half of the design simply stopped being operated when attention moved to grants. A DAO metadata registry can report thirty conforming organizations and be unable to return a single current member list. That is the same decay pattern this wiki has documented in DeSci's reference layer and in [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao)'s disappearance, arriving from a third direction: the immutable part of a public good is cheap and the operated part is not, and it is the operated part that carries the data.

## Why standards matter for DAOs

Standardization is easy to underrate because its benefits are diffuse. But the legibility DAOstar creates is what makes a whole category of ecosystem infrastructure possible. Analytics platforms can rank and compare thousands of DAOs precisely because there is a common shape to read. Grants tooling, delegate marketplaces, and governance aggregators can be written once instead of once-per-framework. Auditors and insurers can reference a shared [security](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) baseline. And regulators, courts, and tax authorities get a defined interface to a kind of organization that otherwise presents as an opaque set of contracts – which, as DAOs take on real treasuries and real legal exposure, matters more every year. A shared standard is a coordination public good: no single DAO profits enough to build it alone, everyone benefits once it exists, and a neutral body is the natural place for it to live.

The DAOstar record is the argument for that case and the caution against over-reading it in one place. The standard that got written for everybody sits at Review with a dark registry behind it; the standard written for one concrete job – describe a grant round so two funders can be compared – runs in production with real programmes feeding it. The lesson is not that DAO standards do not work. It is that a data standard survives on whoever is obliged to keep publishing to it, and general-purpose organizational metadata has never had that constituency the way grants reporting does.

## DAOstar and Caper

A caper is a DAO in all but name – it has members, a shared treasury, proposals that carry real on-chain [actions](/wiki/governance/execution), and [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) – so the objects DAOstar sets out to make legible are exactly the objects a caper is built from. DAOstar's standards are EVM-native and Caper runs on [Radix](/wiki/desci/desci-and-radix), so a caper does not implement `daoURI` today.

What the record above suggests is worth carrying over regardless of chain. The metadata that stayed readable was the metadata that lived where the organization already lives, and the metadata that went dark was the metadata that lived on a service somebody had to keep paying for. A caper's membership, its [proposals](/wiki/governance/proposals), its votes and its treasury balance are components' own state on the ledger, so the answer to "who is a member and what did they vote for" does not depend on a hosted endpoint remaining funded. That is not a claim to have solved interoperability – there is no standard interface here to read that state through, and cross-chain legibility is exactly what DAOstar's work is for. It is the narrower point that legibility and availability are separate problems, and a registry entry can keep passing its checks long after the thing it points at has stopped answering.

## References

- DAOstar, [daostar.org](https://daostar.org), and its [OpenGrants](https://daostar.org/opengrants), [DAO ID](https://daostar.org/daoid) and [research](https://daostar.org/research) pages.
- Joshua Tan et al., [ERC-4824: Common Interfaces for DAOs](https://eips.ethereum.org/EIPS/eip-4824) – Ethereum Improvement Proposals (2022, status Review).
- [metagov/daostar](https://github.com/metagov/daostar) – standards, schemas, reference implementations, and the full [DAOIP catalogue](https://github.com/metagov/daostar/tree/main/DAOIPs) with each document's status in its front matter.
- [metagov/Grants-Gateway-API](https://github.com/metagov/Grants-Gateway-API) and [metagov/opengrants-platform](https://github.com/metagov/opengrants-platform) – the OpenGrants stack; live at [grants.daostar.org](https://grants.daostar.org/api/v1/grantSystems) and [opengrants.daostar.org](https://opengrants.daostar.org).
- DAOstar, [documentation](https://docs.daostar.org/) – adopting EIP-4824 and the DAOIP series.
- Metagov, [DAOstar project page](https://metagov.org/projects/daostar).
- DAOstar, [DAOIP-5: Grants Management](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-5.md) and [DAOIP-8: Recommended Controls for DAOs](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-8.md).

## DeepDAO

URL: https://caper.network/wiki/dao-governance/tooling/analytics/deepdao
Updated: 2026-07-31

|  |  |
| --- | --- |
| **Category** | Discovery · analytics · [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) data |
| **Launched** | 2020 |
| **What it does** | Aggregates DAO treasuries, proposals, voters and governance activity into a single searchable dataset — the “CoinMarketCap for DAOs” |
| **Coverage** | Thousands of DAOs indexed; deep analytics on the largest few hundred by [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and activity |
| **Status** | 🔴 Public site unreachable since mid-2026 (checked 31 July 2026); domain and API host still registered — see _Site outage_ below |
| **Site** | deepdao.io — no longer resolving · [organizations directory, archived 20 May 2026](https://web.archive.org/web/20260520182310/https://deepdao.io/organizations) |
| **Related** | [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) · [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) · [Karma](/wiki/dao-governance/tooling/analytics/karma) · [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) |

**DeepDAO** is the industry's reference dataset for who the DAOs actually are — the analytics and discovery layer often described as the [“CoinMarketCap for DAOs”](https://web.archive.org/web/20260507112427/https://deepdao.io/). Where a governance interface like [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally) or [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) runs one DAO's votes, DeepDAO reads across the whole field: it aggregates treasury balances, proposal counts, voter participation and member overlap into one searchable place, so a claim like “the largest DAO treasuries” has a source you can check rather than a number someone asserted.

## What it measures

For each organization DeepDAO indexes the numbers a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) is usually judged by: **treasury** size and composition, cumulative and active **proposal** counts, unique **voters** and governance-token holders, and derived participation rates. It also tracks **people** across DAOs — the same wallet's activity in multiple organizations — which surfaces the delegate class and the [voting-power concentration](/wiki/dao-governance/concepts/voting/token-weighted-voting) that a single DAO's dashboard hides. The result is one place to answer comparative questions: which DAOs are largest, which are actually active versus dormant, and how thin real [participation](/wiki/dao-governance/concepts/voting/voting-and-delegation) tends to be.

## Why it matters for the industry

DAO treasuries are on-chain and therefore public, but “public” and “legible” are not the same thing — raw addresses across a dozen chains are not an answer to “how big is this DAO and is it healthy?”. DeepDAO is the layer that turns that raw visibility into comparable figures, which is why its dashboards are routinely cited in governance research and by DAOs themselves. Its own tracker puts the largest treasuries — [Uniswap](/wiki/daos/dexs/uniswap-dao), [Sky (MakerDAO)](/wiki/daos/stablecoins/sky-dao), [Optimism](/wiki/daos/networks/optimism-collective), [Arbitrum](/wiki/daos/networks/arbitrum-dao) — each into the billions, with the aggregate across all tracked DAOs running to tens of billions of dollars. (Figures per [DeepDAO's tracker as archived on 20 May 2026](https://web.archive.org/web/20260520182310/https://deepdao.io/organizations), the last capture before the site went dark; treasury values move with token prices, so treat any point figure as a snapshot.)

## Limits of the data

The numbers are only as good as what's on-chain and labelled. Treasury figures are dominated by each DAO's _own_ governance token, so a large headline treasury can be mostly an illiquid position that couldn't be sold without crashing its own price — a distinction covered in [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management). Participation rates flatter or damn a DAO depending on whether you count token supply or holders. DeepDAO is the best available map, but a map of reported figures — reading it well means knowing what each number does and doesn't include.

## Site outage (2026)

DeepDAO's public site has been unreachable since mid-2026. The hostnames `deepdao.io`, `www.deepdao.io` and `app.deepdao.io` carry no address record at either the [Google](https://dns.google/query?name=deepdao.io&rr_type=A) or the Cloudflare public resolver (checked 31 July 2026), so a browser cannot reach the site at all — this is a DNS-level absence rather than a server error or a bot block. The most recent capture of the site in the Internet Archive is the [organizations directory of 20 May 2026](https://web.archive.org/web/20260520182310/https://deepdao.io/organizations); nothing at the domain has been archived since.

What remains points to a withdrawal rather than a lapse. The domain is [registered through 5 July 2027](https://lookup.icann.org/en/lookup?name=deepdao.io) and still publishes Google mail records, and the API host `api.deepdao.io` still resolves and answers — with the `403 Forbidden` its documented endpoints return to a request carrying no key. No shutdown has been announced: DeepDAO's [Substack](https://deepdao.substack.com/) has published nothing since April 2025, and its [last governance-forum activity](https://gov.uniswap.org/t/deepdao-pro-a-breakthrough-in-dao-analytics/25631) is older still.

The outage is a sourcing problem as much as a product one. Cross-DAO treasury and participation figures — in governance research, in press coverage, and on several pages of this wiki — trace back to DeepDAO as the one index that read across the whole field. The live substitutes each cover part of it: [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally) and [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) for one DAO's votes at a time, [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) for aggregated governance reads, [Dune](https://dune.com/) and [Token Terminal](https://tokenterminal.com/) for treasury and revenue queries. None of them reproduces the people-and-membership graph across organizations that made DeepDAO distinct. Treat DeepDAO-sourced figures — including the ones cited on this wiki — as dated to before May 2026 unless the site returns.

## How Caper approaches this

DeepDAO exists because most DAO activity is scattered across chains, forums and off-chain snapshots that need aggregating to be understood. [Caper](/wiki/foundations/what-is-a-caper) keeps the primary data in one place by construction: a caper's treasury, [proposals](/wiki/governance/proposals), [votes](/wiki/governance/voting) and [executions](/wiki/governance/execution) all live in the same on-chain contract, so the figures an analytics tool would reconstruct are the native, canonical state rather than an after-the-fact estimate. The transparency DeepDAO works to surface for the wider industry is the default a caper starts from.

## References

- DeepDAO, [deepdao.io](https://web.archive.org/web/20260507112427/https://deepdao.io/) and the [organizations directory](https://web.archive.org/web/20260520182310/https://deepdao.io/organizations) — Internet Archive captures of 7 and 20 May 2026, the site being unreachable since.
- DeepDAO, [“Is This a Healthy DAO Treasury?”](https://deepdao.substack.com/p/is-this-a-healthy-dao-treasury-deepdao) (methodology).
- Uniswap governance, [DeepDAO Pro discussion](https://gov.uniswap.org/t/deepdao-pro-a-breakthrough-in-dao-analytics/25631).

## Karma

URL: https://caper.network/wiki/dao-governance/tooling/analytics/karma
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Category** | Delegate reputation · governance analytics · accountability |
| **Launched** | 2022 (first Optimism delegate dashboard, June 2022) |
| **What it does** | Scores and surfaces [delegate](/wiki/dao-governance/concepts/voting/voting-and-delegation) activity — a per-DAO reputation dashboard aggregating on-chain votes, [Snapshot](https://snapshot.org/) votes and forum contributions into one comparable delegate feed |
| **Used by** | [Optimism](/wiki/daos/networks/optimism-collective), [Arbitrum](/wiki/daos/networks/arbitrum-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), Idle and 30+ programs |
| **Open source** | Score weights and calculation logic are published per DAO ([github.com/show-karma](https://github.com/show-karma)) |
| **Site** | [gov.karmahq.xyz](https://gov.karmahq.xyz/) · [how it works](https://www.karmahq.xyz/how-it-works) |
| **Related** | [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) · [Tally](/wiki/dao-governance/tooling/voting/tally) · [Delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) |

**Karma** is the accountability layer for [delegated](/wiki/dao-governance/concepts/voting/voting-and-delegation) governance. In a large token-weighted DAO most holders never vote directly; they delegate their voting power to a smaller set of active delegates, and the obvious question — _are those delegates actually showing up?_ — has no answer in the raw on-chain record. Karma builds per-DAO dashboards that answer it: it reads each delegate's on-chain voting, [Snapshot](https://snapshot.org/) (off-chain) voting and forum participation, folds them into a single reputation score, and publishes a public delegate feed so token holders can see who is engaged before handing over their votes.

## What it measures

For each delegate Karma tracks the metrics that reveal whether delegated power is being used: **on-chain voting participation** (share of executable proposals voted on), **off-chain voting participation** on [Snapshot](https://snapshot.org/), and **forum activity** on Discourse — proposals authored, comments, and the health of that participation. These roll up into a per-DAO **reputation score** and an auto-generated delegate profile that reads like a governance resume, spanning every DAO the same wallet is active in. The weightings are set with each DAO rather than fixed: in the [ENS](/wiki/daos/infrastructure/ens-dao) configuration, for example, authoring a forum proposal carries far more weight than casting an off-chain vote, and the [weights and scoring logic are open source](https://github.com/show-karma) so the number is auditable rather than a black box.

## Why delegate accountability matters

Delegation is what makes [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) workable at scale — but it also creates a principal-agent gap. A holder who delegates and stops paying attention has no cheap way to notice that their delegate went quiet, switched interests, or started rubber-stamping. Low, concentrated [participation](/wiki/dao-governance/concepts/voting/voting-and-delegation) is one of the most common ways a DAO decays (see [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail)), and it is invisible until someone measures it. Karma makes the measurement standing infrastructure: DAOs surface it to re-delegate away from absent delegates, and platforms consume it directly — [Tally](/wiki/dao-governance/tooling/voting/tally) integrates Karma's delegate score alongside a delegate's own voting percentages so the accountability signal sits next to the voting interface itself.

## Limits of a reputation score

A participation score measures activity, not judgement. A delegate can vote on everything and vote badly, or author many forum posts that add little; turning “showed up” into a headline number risks rewarding volume over quality, and any single weighting encodes a contestable view of what good governance looks like. Karma’s answer is transparency rather than a claim of objectivity — the weights are published and set per DAO — but the score is a prompt to look, not a verdict. It tells a holder which delegates to scrutinise; it cannot tell them which delegate is right. Karma has also extended the same accountability pattern beyond delegates into grant reporting via its [Grantee Accountability Protocol](https://www.karmahq.xyz/), tracking whether funded programs deliver against their milestones.

## How Caper approaches this

Karma exists because influence and participation are separated: voting power is delegated to agents, and a whole tooling layer is needed to check whether those agents stay active. A [caper](/wiki/foundations/what-is-a-caper) narrows that gap by construction. Voting weight is not a static balance you hand to a delegate — it is your holdings multiplied by the votes you have actually accumulated over the pool, so sustained participation is priced _into_ the weight rather than measured after the fact by an external scorecard. A holder who stops engaging simply carries less weight; there is no idle-delegate class to police. And a holder who is persistently outvoted is not stuck monitoring representatives to protect their stake — the [vote](/wiki/governance/voting) and the [exit right](/blog/the-exit-right) are the same right, so disengagement resolves by leaving with a fair share rather than by a reputation dashboard flagging a no-show. Karma is the right tool for the delegated model; a caper aims not to need one.

## References

- Karma, [How reputation scoring works](https://gov.karmahq.xyz/how-it-works) and [governance dashboards](https://gov.karmahq.xyz/).
- Optimism Collective governance forum, [“Karma — Dashboard showing delegate reputation”](https://gov.optimism.io/t/karma-dashboard-showing-delegate-reputation/2525) (June 2022, introducing the first Karma dashboard).
- Arbitrum DAO forum, [“Tally integrates Karma’s delegate score and contributor metrics”](https://forum.arbitrum.foundation/t/tally-integrates-karmas-delegate-score-and-contributor-metrics/24911).
- Karma, [Analytics Suite for Optimism](https://gov.karmahq.xyz/case-study/optimism) and [for ENS](https://www.karmahq.xyz/case-study/ens) (per-DAO weightings).

## MIDAO

URL: https://caper.network/wiki/dao-governance/tooling/analytics/midao
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Category** | DAO legal-wrapper service (formation & management) |
| **Founded** | 2022, following the Republic of the Marshall Islands (RMI) DAO legislation |
| **Entity formed** | [Marshall Islands DAO LLC](https://www.midao.org) — a limited-liability company purpose-built for on-chain organizations |
| **Government role** | Exclusive public–private partnership authorized by the RMI to process and manage DAO LLC registrations |
| **Notable clients** | Pyth Network, MetaDAO, DFINITY, Gnosis Guild (300+ clients as of August 2026) |
| **Indicative cost** | ~$9,500 formation + ~$2,000–$5,000/yr (optional 24-hour "TurboDAO" onboarding +$10,000) |
| **RMI tax** | 3% of _gross revenue_ for for-profit DAO LLCs, paid directly to the government; non-profits are tax-exempt |
| **Also marketed for** | AI agents — MIDAO now sells the same DAO LLC as a wrapper for autonomous agents, not only for DAOs |
| **Related** | [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) · [The DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**MIDAO** is a formation-and-management service that incorporates [Marshall Islands DAO LLCs](https://www.midao.org) — a limited-liability entity purpose-built to give a decentralized autonomous organization legal personhood without forcing it to abandon on-chain governance. It operates as an [exclusive public–private partnership](https://www.midao.org) with the Republic of the Marshall Islands (RMI) government, and is the channel most DAOs use to obtain a Marshall Islands wrapper. It sits in the [legal-wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) layer of the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) rather than the software layer.

## Why a legal wrapper

An unwrapped DAO is, in most jurisdictions, treated as a **general partnership** — meaning every token-holding member can be held jointly and severally liable for the organization's obligations. That exposure became concrete in [CFTC v. Ooki DAO (2023)](https://www.cftc.gov/PressRoom/PressReleases/8715-23), where a US court held an unincorporated DAO liable and served it through its help-chat box. A legal wrapper interposes a limited-liability entity between members and the outside world, giving the DAO a bank account, the ability to sign contracts, standing to sue and be sued, and a liability shield for its participants. MIDAO's product is the fastest-adopted of the offshore options; [our legal-structures pillar](/wiki/dao-governance/concepts/membership/dao-legal-structures) compares it against the Wyoming DAO LLC, the Wyoming DUNA, and the Cayman foundation.

## The Marshall Islands DAO Act

The RMI adopted its [DAO Act in 2022](https://rmiparliament.org/cms/images/LEGISLATION/PRINCIPAL/2022/2022-0050/2022-0050_2.pdf) (52 MIRC Ch. 7) — the first national law to recognize a DAO as a domestic LLC in its own right, rather than retrofitting a general-purpose company statute. The statute was [later amended](https://www.midao.org/blog-posts/marshall-islands-dao-llc-vs-cayman-foundation-full-comparison) and complemented by DAO Regulations, adding two features that matter for real treasuries. Both now sit in §703 of the Act itself rather than in commentary: a DAO LLC **may have series** under §79 of the Limited Liability Company Act, with “no additional reporting requirements for individual series… beyond the requirements for the DAO LLC itself” (§703(1)(c), amended by P.L. 2023-83) — sub-DAOs with ring-fenced assets under one parent; and “a governance token conferring no economic rights shall not be deemed a security as defined in the Securities and Investment Act” (§703(2)(d)). The carve-out is conditional on the token carrying no economic rights, which is a narrower door than it is usually reported to be. The law expressly recognizes on-chain governance, tokenized membership, and smart-contract voting as valid corporate machinery.

## How the DAO LLC is structured

- **On-chain membership & governance.** Membership and voting can run entirely through [ERC-20 tokens, other crypto tokens, or smart contracts](https://docs.midao.org); the smart contract itself can serve as the operating agreement.
- **No mandatory officers.** There is no requirement to appoint directors, officers, trustees, or managers — the DAO can remain member-governed.
- **Limited disclosure.** Members face limited identification and disclosure requirements, allowing pseudonymous participation (though formation still runs KYC on the organizers).
- **For-profit or non-profit.** A DAO LLC can be either; non-profits are approved as such at founding, can operate as ownerless entities, and are tax-exempt.

MIDAO markets fixed, lower costs than comparable jurisdictions and reports more than [300 clients](https://www.midao.org), including Pyth Network, MetaDAO, DFINITY, and Gnosis Guild. Adoption is widening at the base-layer level, too: through mid-2026 the [Radix community discussed](https://t.me/radix_dlt/993163) a Marshall Islands DAO LLC as the wrapper for the L1’s own decentralization, with the Radix Foundation expected to transfer the network treasury to the DAO LLC once the entity is established ([community timeline, June 2026](https://t.me/radix_dlt/992653)) — an established L1 reaching for the same offshore wrapper rather than standing up a bespoke foundation.

Through 2026 MIDAO has also widened what the wrapper is sold for. Its site now markets the DAO LLC for "Web3, DAOs, and AI Agents", and states outright that [you do not need to be a DAO to use a DAO LLC](https://www.midao.org/). [In August 2026 the company stated](https://x.com/MIDAODS/status/2087162466392219710) that most of its clients do not call themselves DAOs, naming protocol teams, investment collectives, NFT communities, and AI-agent companies; in its own words, “the name reflects what the law supports, not who can use it.” The fit is a structural one rather than marketing: the same features that suit an on-chain organization, no mandatory directors or officers, a smart contract able to serve as the operating agreement, and limited identification requirements for members, are the features an autonomous agent needs in order to hold assets and sign for itself without a human officer sitting behind it. Whether a court reaches the same conclusion is untested; the offering is currently ahead of any case law on it.

## What it costs, and what the RMI takes

MIDAO publishes a single [all-inclusive price](https://www.midao.org/pricing): **$9,500** to form, plus a **$2,000–$5,000** annual fee, with all MIDAO services and RMI government fees included and an optional **+$10,000** "TurboDAO" add-on for entity creation inside 24 hours. Against the alternatives it lists on the same page, Cayman foundations start at $18,500 plus $5,575 a year, and Swiss foundations at $23,500 plus roughly $56,000 in locked capital.

The line that matters more for a treasury is the tax treatment, and it is stated plainly: **for-profit DAO LLCs pay the RMI a 3% gross revenue tax**, paid directly to the government, while non-profits are tax-exempt. Gross revenue, not profit, is an unusual base for an on-chain organization. A protocol that routes fee income through the entity is taxed on the top line whatever its costs, so the wrapper decision and the [cost structure](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) of the organization interact rather than being independent choices. The non-profit path exists partly for that reason.

## How Caper approaches this

A legal wrapper and an economic design answer different questions, and a DAO can want both. MIDAO solves _liability and legal personhood_ — who can be sued, who signs the lease. A [caper](/wiki/foundations/what-is-a-caper) instead reshapes the _on-chain economics_: members buy in on a bonding curve, the treasury is spent only through explicit on-chain proposals, and every member holds an always-available right to redeem their pro-rata, participation-weighted share of the treasury and walk away. Those are orthogonal — a DAO could form a Marshall Islands DAO LLC for its off-chain footing _and_ run its treasury as a caper — but they are not substitutes: a liability shield does nothing about the [trapped-minority](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) problem, and an exit right does nothing about a court serving your help desk.

## Token Terminal (standardized onchain financials)

URL: https://caper.network/wiki/dao-governance/tooling/analytics/token-terminal
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Category** | Onchain financial data · standardized KPIs · [DAO analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics) |
| **Public since** | 2020 — [first archived capture, 30 August 2020](https://web.archive.org/web/20200830210212/https://www.tokenterminal.com/) |
| **What it does** | Ingests raw blockchain data and turns it into GAAP-style income statements — fees, revenue, expenses, earnings — on a basis that is comparable across protocols and chains ([about](https://tokenterminal.com/about)) |
| **Coverage** | 100+ chains, 1,200+ applications and 3,000+ tokenized assets; 11,000+ decoded smart contracts ([tokenterminal.com](https://tokenterminal.com/), [Data Room](https://tokenterminal.com/products/data-room), checked 1 August 2026) |
| **Access** | Free tier carries full historical data, CSV exports and MCP; Pro $350/month; REST API at 250,000 requests/day; warehouse sharing via BigQuery/Snowflake ([pricing](https://tokenterminal.com/pricing)) |
| **Status** | 🟢 Active — site, docs and API all live (checked 1 August 2026) |
| **Site** | [tokenterminal.com](https://tokenterminal.com/) · [docs](https://tokenterminal.com/docs) · [API reference](https://tokenterminal.com/docs/api-reference/introduction) |
| **Related** | [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) · [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) · [Karma](/wiki/dao-governance/tooling/analytics/karma) · [DAOstar](/wiki/dao-governance/tooling/analytics/daostar) · [tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Token Terminal** is the financial-reporting layer of the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview). It does not host a forum, hold a treasury or count a vote; it answers a narrower question that governance keeps running into — _what does this protocol actually earn, and how does that compare to the one next to it?_ The platform ingests raw blocks, logs and traces from its own nodes, decodes smart-contract activity, and maps each project's idiosyncratic business logic onto [a single set of standardized financial and usage metrics](https://tokenterminal.com/about). The output is an income statement a treasurer or a delegate can read without first learning the protocol's internal accounting.

That matters for [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) because the arguments that decide real money — [whether to turn on a fee switch](/wiki/economics/fee-switches-and-value-accrual), how long the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) lasts, whether [emissions](/wiki/economics/liquidity-mining) are buying growth or renting it — are arguments about numbers, and until those numbers are defined the same way for every protocol, a forum thread is a fight over methodology rather than over the decision.

## The protocol income statement

Token Terminal's core abstraction is an ordinary income statement applied to a network. Its own worked example on the [front page](https://tokenterminal.com/) runs an Ethereum statement in four lines: **fees** of $103.72m in October 2024, of which **supply-side fees** of $35.51m are paid out to the parties providing the service, leaving **revenue** of $68.22m to the protocol, against **expenses** of $197.39m — overwhelmingly token issuance.

The gap between the first line and the third is the one governance most often confuses. Total fees measure how much users paid; revenue measures how much the protocol itself kept. A [DEX](/wiki/daos/dexs/uniswap-dao) that routes every basis point to liquidity providers can carry enormous fees and zero protocol revenue — which is precisely the state a fee-switch proposal exists to change, and precisely why quoting fees as if they were revenue distorts the vote. The fourth line is the one delegates skip: a protocol can be revenue-positive and earnings-negative at the same time, because [token incentives](/wiki/dao-governance/concepts/treasury/dao-tokenomics) are booked as an expense rather than treated as free.

## Where the numbers come from

Most crypto data products are aggregators: they read other people's APIs. Token Terminal [runs the pipeline end to end](https://tokenterminal.com/about) — direct ingestion of raw blocks, logs, traces and events from RPC nodes, a full backfill from genesis, storage in a BigQuery warehouse, contract-level decoding, then standardization into comparable KPIs served over API. Its FAQ is more precise about the boundary than the marketing copy: the company [runs its own blockchain infrastructure for 14+ chains and relies on third-party APIs for some metrics](https://tokenterminal.com/docs/faq), with the source named on each dashboard.

The pipeline is deliberately **ELT** rather than ETL — raw data is stored first and transformed afterwards. Token Terminal's [own justification](https://tokenterminal.com/docs/data-approach) is that in this industry the definitions move: protocols ship upgrades that break schemas, deploy new contracts across new chains, and the accepted meaning of “fees” or “active users” itself evolves. Keeping the raw data means a methodology change can be re-applied to history in minutes instead of re-ingested over days. For a DAO the practical consequence is _traceability_: a disputed figure can be walked back to the block and transaction that produced it, which is the property a governance forum needs and a screenshot of a chart does not have.

## What DAOs use it for

- **Fee-switch and value-accrual debates.** The question of whether a protocol should divert fees from suppliers to the treasury or the token is a question about the size and stability of the fee line — see [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual).
- **Treasury reporting and runway.** Standardized revenue against standardized expenses is what turns a treasury balance into a runway estimate; the practice is covered on [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).
- **Comparables for valuation.** Price-to-fees and price-to-revenue multiples only mean anything if the denominator is computed the same way across the peer set — see [token valuation](/wiki/economics/token-valuation).
- **Index construction and outside capital.** [MarketVector Indexes, a VanEck subsidiary, uses Token Terminal data as benchmark data for index construction](https://tokenterminal.com/customers), and the investment firm Theia runs its underwriting engine on the API. A DAO's reported fundamentals are increasingly an input to whether its token is held by anyone other than its own community.
- **Agent and LLM access.** The platform ships [an MCP server](https://tokenterminal.com/products/mcp) for natural-language queries against the same metrics — the emerging way analysis actually gets done during a proposal cycle.

## Access and cost

Coverage matters less than whether a DAO's contributors can get at it. Per Token Terminal's [published pricing](https://tokenterminal.com/pricing) (1 August 2026), the free tier is unusually deep for this category: full historical data, three custom dashboards, the Google Sheets and Excel plugins, CSV exports and MCP access, at no cost. Pro removes the dashboard cap at $350 per month. The REST API is custom-priced with a 250,000 requests/day ceiling and startup discounts, and the Data Room tier delivers [raw block, transaction and event data plus 11,000+ decoded contracts](https://tokenterminal.com/products/data-room) into a customer's own BigQuery or Snowflake warehouse.

For a governance working group the free and Pro tiers are usually enough to source a proposal; the API tier is where a DAO would sit if it wanted a live treasury dashboard maintained by its own contributors rather than a vendor.

## Where it sits in the analytics layer

Until 2026 the closest thing to a single cross-DAO index was [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao), which put treasuries, membership and voter turnout for thousands of organizations behind one search box. Its public site has been unreachable since mid-2026, and no single successor covers the same ground. What replaced it is a split:

- **Financials** — Token Terminal: fees, revenue, expenses and earnings, standardized for comparison.
- **Governance activity** — [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) for proposals and delegates across protocols, [Karma](/wiki/dao-governance/tooling/analytics/karma) for delegate participation scores.
- **Self-published data** — [DAOstar](/wiki/dao-governance/tooling/analytics/daostar), whose [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) standard has DAOs publish their own machine-readable index rather than relying on a third party to scrape them.
- **Bespoke queries** — [Dune](https://dune.com/) and similar SQL platforms, where anything not covered by a standard metric ends up.

The distinction to hold on to is that Token Terminal answers _how the business is doing_ and the governance tools answer _who is deciding_. A DAO that reads only the first cannot tell that its revenue is being set by four delegates; a DAO that reads only the second cannot tell that its treasury has eighteen months left.

## Limitations

Three caveats belong on any figure sourced from a standardized platform, and Token Terminal states two of them itself.

- **Methodology is a choice, not a fact.** Token Terminal's [FAQ acknowledges](https://tokenterminal.com/docs/faq) that its numbers differ from other providers because it uses a different methodology and tracks different versions and chains. Two honest sources can report different revenue for the same protocol; a proposal should name which one it used.
- **Coverage is partly opt-in.** New projects are added weekly, but listing runs through [a submission form, with submissions carrying complete smart-contract descriptions prioritized](https://tokenterminal.com/docs/faq). Absence from the platform is evidence about a project's data hygiene, not about its size.
- **Protocol financials are not DAO financials.** Fees accruing to a protocol contract are not the same as assets a DAO can spend; the treasury may hold a different set of tokens under a different mandate. The two lines belong in separate columns — a distinction [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) takes further.

## How Caper approaches this

Token Terminal exists because a protocol's economics are scattered across contracts nobody outside the team can read, and someone has to reconstruct them. A [caper](/wiki/foundations/what-is-a-caper) starts from the other end: its token supply, its treasury and every buy and exit are component state on the Radix ledger, written by the same contract that enforces them, so the figures a reporting platform normally reassembles are the numbers the mechanism is already using. That does not remove the need for comparison across organizations — which is exactly what a standardized platform is for — but it does mean a holder can check the [current state](/wiki/markets/trading) at the source rather than trusting a pipeline to have decoded it correctly.

## References

- [Token Terminal — front page and worked Ethereum income statement](https://tokenterminal.com/)
- [Token Terminal — About: data infrastructure and standardization](https://tokenterminal.com/about)
- [Token Terminal docs — Our data approach (ELT, traceability, reproducibility)](https://tokenterminal.com/docs/data-approach)
- [Token Terminal docs — General FAQ (data sources, listing process, methodology differences)](https://tokenterminal.com/docs/faq)
- [Token Terminal — Pricing tiers and limits](https://tokenterminal.com/pricing)
- [Token Terminal — Data Room (raw and decoded datasets)](https://tokenterminal.com/products/data-room)
- [Token Terminal — MCP server](https://tokenterminal.com/products/mcp)
- [Token Terminal — Customer stories (MarketVector, Theia, Matter Labs)](https://tokenterminal.com/customers)
- [Internet Archive — tokenterminal.com, first capture 30 August 2020](https://web.archive.org/web/20200830210212/https://www.tokenterminal.com/)

## Aragon

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/aragon
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Category** | DAO framework |
| **Launched** | 2016 — one of the earliest DAO frameworks |
| **Current stack** | [Aragon OSx](https://docs.aragon.org/) (2023): modular permission manager + governance plugins |
| **Token** | ANT — Aragon Association dissolved 2024; ANT redemption closed 2 Nov 2024, unredeemed ANT burnt |
| **Historically powered** | On-chain governance for early DAOs including Curve and Lido |
| **Site** | [aragon.org](https://www.aragon.org/) · [docs](https://docs.aragon.org/) |
| **Related** | [Aragon DAO](/wiki/daos/infrastructure/aragon-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Safe](/wiki/dao-governance/tooling/treasury/safe), [Juicebox](/wiki/dao-governance/tooling/treasury/juicebox) |

**Aragon** is one of the oldest and most influential [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) frameworks — infrastructure for deploying an organization whose rules, membership and treasury live entirely on-chain. Launched in 2016, it let non-programmers spin up a DAO with token voting, a treasury and upgradeable permissions, and it underpinned the early on-chain governance of major protocols including [Curve](https://gov.curve.finance/) and [Lido](https://research.lido.fi/). Its more recent history is also a cautionary tale about token-governed foundations, summarised below and told in full on [Aragon DAO](/wiki/daos/infrastructure/aragon-dao). ([Aragon](https://www.aragon.org/))

## aragonOS and the Aragon client

The original stack — **aragonOS** plus the Aragon client — modelled a DAO as a set of on-chain _apps_ (voting, tokens, finance, permissions) wired together through a central access-control list. Its defining idea was **upgradeable, granular permissions**: every action a DAO could take was a permission that could be granted to an address, a token vote, or another app, so an organization's power structure was itself programmable. This made Aragon a natural home for protocol DAOs that needed to hand contract control to a token vote.

## Aragon OSx

In 2023 Aragon shipped a ground-up rewrite, [Aragon OSx](https://docs.aragon.org/), built around a lean permission-management core and a **plugin architecture**: governance mechanisms (token voting, multisig, optimistic, admin) are installed as swappable plugins rather than baked in, so a DAO can evolve its own rules over time. OSx is deployed on Ethereum, Polygon and other EVM chains and is the framework Aragon actively maintains today. ([Aragon: A New Chapter](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/))

## The 2024 pivot: Association dissolution and ANT redemption

In November 2023 the [Aragon Association announced](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/) it would dissolve, wind down token-based governance of its treasury, and refocus as a product-oriented team building OSx. Rather than transfer the treasury to a DAO, it returned it to token holders: an autonomous redemption contract, funded with 86,343 ETH, let ANT be redeemed at a fixed **0.0025376 ETH per ANT** through **2 November 2024**, after which unredeemed ANT was burnt and remaining ETH passed to the successor structure. That decision followed an **eighteen-month dispute** over a treasury transfer ANT holders had already voted for, which the association halted in May 2023 after activist buyers assembled a majority — the sequence, and both sides' accounts of it, are documented on [Aragon DAO](/wiki/daos/infrastructure/aragon-dao). Of the ANT in circulation, **87%** was ultimately redeemed across just **2,670 redemptions**, paying out **75,093.99 ETH** ([Aragon's final report](https://blog.aragon.org/ant-redemption-initiative-report/)). It is one of the most-cited examples of a major project concluding that a large token-governed foundation treasury was more liability than asset. ([A New Chapter for the Aragon Project](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/))

## What Aragon actually ships now (2025–2026)

Describing Aragon as the maintainer of a DAO framework understates where the product went after the wind-down. Its work since 2025 has concentrated on governance that sits inside other protocols' security models rather than on standalone DAO creation.

**Guardians.** Aragon Guardians is a veto layer built on OSx: a protective role that lets a community or a set of trusted actors block a malicious proposal, an exploit or a buggy upgrade before it lands. It is used by MetaMorpho curators and by DeFi protocols including Steakhouse Financial, Hyperithm, MEV Capital and Re7 Labs. In October 2025 the [Ethereum Foundation disclosed](https://blog.aragon.org/aragon-guardians-secure-defi-assets-morpho-ethereum-foundation/) that it holds 2,400 ETH and roughly $6M in stablecoins in Morpho yield-bearing vaults safeguarded by Aragon Guardians and the Aragon TokenVoting plugin.

**LockToVote and Guardians v2.** Released in September 2025 alongside Morpho Vaults v2, the LockToVote plugin lets any ERC-20 be used for governance without being a purpose-built governance token: holders lock tokens into a LockManager contract, the locked balance becomes voting power, locked tokens are non-transferable so the same balance cannot vote twice from two addresses, and unlocking resets voting power to zero. The design keeps tokens liquid for trading or collateral right up to the moment a decision is live, and gives vault depositors a real-time veto over curator actions. It is currently available to whitelisted projects only.

**Policy plugins.** In January 2026 Aragon set out a direction it summarises as "the art of not governing": a class of plugins that, unlike governance plugins, execute without requiring input, applying a rule configured once to a bounded and known action type. The argument is that proposal-based governance treats every action as an onchain referendum, and that recurring operations such as payroll, vendor top-ups and rebalancing do not need human intent re-encoded each time ([Beyond Proposals Pt. I](https://blog.aragon.org/beyond-proposals-pt-i-automation-and-the-art-of-not-governing/)). The cost side of that argument is on [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs).

**Private voting.** In June 2026 Aragon shipped an implementation of [CRISP with Interfold](https://blog.aragon.org/verifiable-secret-ballots-with-interfold-and-aragon/), producing verifiable secret ballots where votes stay private and the result can be verified publicly without trusting a single tallying authority.

## Legacy and current status

Aragon's lasting contribution is architectural: the notion that a DAO is a permission system with pluggable governance, and that those permissions should be upgradeable, runs through much of the tooling that followed. As a live product it is no longer the token-governed network it once was, a distinction the wiki keeps clear because older third-party descriptions still present the ANT-governed Aragon Network that no longer exists. What replaced it is narrower and more specific than "a DAO framework": OSx as a neutral execution environment, and a plugin catalogue sold into protocols that need a governance or veto layer around assets they already hold. Both [aragon.org](https://www.aragon.org/) and the [OSx app](https://app.aragon.org/) are live and the [blog](https://blog.aragon.org/) has published throughout 2026.

## How Caper approaches this

Aragon is a general framework you assemble a DAO from; Caper is a purpose-built protocol with the governance, treasury and [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) rules already fixed. The two sit at opposite ends of a real trade-off — Aragon's plugins maximize configurability, Caper's fixed rules minimize the surface a caper's members have to trust or re-litigate. Aragon's Association wind-down is also a pointed argument for Caper's stance that treasury claims should be an on-chain member right (redeemable at [exit](/wiki/markets/trading)) rather than something a foundation decides how to return.

## References

- Aragon, [A New Chapter for the Aragon Project](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/).
- Aragon, [Aragon OSx documentation](https://docs.aragon.org/).
- Aragon, [aragon.org](https://www.aragon.org/).

## Colony

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/colony
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Category** | DAO framework (reputation-weighted, task-based governance) |
| **What it is** | A framework for running organisations on _reputation_ earned by contribution, with governance by _lazy consensus_ — vote only when someone objects |
| **Builder** | [JoinColony](https://github.com/JoinColony) (Colony Network; whitepaper by Alex Rea & Jack du Rose) |
| **Native token** | [CLNY](https://docs.colony.io/learn/payments-and-tokens/the-metacolony-clny/) — the token of the Metacolony that maintains the network (distinct from any colony’s own token, and from reputation) |
| **Chains** | Historically [Gnosis Chain](https://blog.colony.io/chain-migration/); from April 2024 [multi-chain, starting with Arbitrum](https://blog.colony.io/colony-is-going-multi-chain/) |
| **Related** | [DAO tooling overview](/wiki/dao-governance/tooling/dao-tooling-overview), [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) |

**Colony** is a DAO framework built on a single idea most governance tools skip: influence should be _earned_, not bought. Where [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) and [token voting](/wiki/dao-governance/concepts/voting/voting-and-delegation) weight a member by the coins in their wallet, a colony weights members by **reputation** — a non-transferable, decaying score accrued by doing the work. Around that it wraps **lazy consensus**, a workflow designed so that a healthy organisation almost never has to vote at all. It is one of the longest-running frameworks in the space, developed by [JoinColony](https://github.com/JoinColony) from a [2018 whitepaper](https://joincolony.github.io/colonynetwork/whitepaper-tldr-colony/), and it sits in the [frameworks layer](/wiki/dao-governance/tooling/dao-tooling-overview) of the DAO stack alongside [Aragon OSx](/wiki/dao-governance/tooling/frameworks/aragon) and Moloch.

## Reputation: earned, scoped, and decaying

Reputation is the heart of Colony. A member gains it by [receiving payments, completing tasks, and evaluating others’ work](https://docs.colony.io/learn/governance/reputation/) inside the colony — never by buying it, because reputation is **non-transferable**. It is also **scoped**: reputation is tagged to the _domain_ (team) and _skill_ in which it was earned, so an expert in one area does not automatically wield authority over another.

Its defining property is that it **decays**. Per Colony’s [reputation specification](https://joincolony.github.io/colonynetwork/whitepaper-tldr-reputation/), every 600,000 blocks a member’s reputation in each domain and skill is halved — a reputation half-life of roughly **3.5 months**. Influence therefore tracks _recent_ contribution: stop showing up and your say fades, no matter how much you once did. Because computing every member’s reputation on-chain would be prohibitive, it is calculated off-chain by **reputation miners** who stake CLNY and submit updates with cryptographic proofs, secured by an “innocent until proven guilty” challenge game in which a single honest submission is enough.

## Lazy consensus: motions and disputes

Colony’s governance model, [lazy consensus](https://docs.colony.io/learn/governance/lazy-consensus/), treats _agreement as the default_. A member proposes an action — say, “pay Alice 100 xDAI” — and backs it by staking the colony’s native token. If nobody objects within the staking window, the action simply executes: no vote, no quorum, no turnout problem. A vote happens only when someone **disagrees** and stakes tokens to raise an **objection**, which escalates the decision to a **reputation-weighted vote**.

The staking makes objections costly and honest: the side that loses forfeits a portion of its stake to the side that wins, and members who vote can be rewarded from the staked pool. This inverts the usual DAO problem — instead of demanding that a busy, apathetic electorate turn out for every routine payment, Colony only pulls the electorate in when there is genuine conflict worth their attention.

## Domains, the Metacolony, and CLNY

A colony is organised into **domains** — nested teams that each hold their own budget and accrue their own reputation, so a large organisation can delegate spending authority downward without granting global control. Payments, funding pots and permissions all resolve against this domain tree.

The network itself is governed by the **[Metacolony](https://docs.colony.io/learn/payments-and-tokens/the-metacolony-clny/)**, the colony responsible for developing and maintaining Colony Network infrastructure; its token, **CLNY**, is what reputation miners stake and what the Metacolony uses for its own disputes. This is a deliberate three-way separation worth noting: a _colony’s_ token (optional, for staking motions), _reputation_ (earned influence, non-transferable), and _CLNY_ (network-level) are three different things — Colony never conflates “how many tokens you hold” with “how much say you have.” After years of running exclusively on [Gnosis Chain](https://blog.colony.io/chain-migration/), Colony [began a multi-chain rollout on Arbitrum in April 2024](https://blog.colony.io/colony-is-going-multi-chain/).

## How Caper approaches this

Colony and [Caper](/wiki/foundations/what-is-a-caper) start from the same conviction — that a wallet balance alone should not decide who controls an organisation — and reach it by different routes. In Colony, earned influence lives in a _separate_ quantity (reputation) that decays to track current engagement. In a caper, the earned signal is folded directly into the vote-weight formula. Each time a member votes, the contract mints them exactly one **soulbound** vote token — non-transferable by construction (its depositor role is the dao itself, so it can never move peer-to-peer) and indivisible ([DIVISIBILITY_NONE](https://github.com/)). A member’s weight is `w = (t · v) / (V · T)`, where `t` is the caper tokens they hold, `v` the vote tokens they have earned, `V` the total votes ever cast, and `T` the circulating supply.

Two consequences follow, both verifiable in `contracts/logic/src/lib.rs`. First, participation is a _multiplier_ on stake, not a replacement for it: a large bag with no voting history still resolves to little weight, but the earned record is the factor a newcomer cannot simply buy. Second, the very same formula sets a member’s payout when they [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — the `exit()` path reuses the identical `compute_vote_weight` helper for the treasury share — so the earned signal that governs your voice also governs the value you can walk away with. Unlike Colony’s reputation, a caper’s vote record does not decay: it is a permanent, on-chain history of having shown up.

## References

- Colony, [Reputation](https://docs.colony.io/learn/governance/reputation/) and [reputation specification (whitepaper TL;DR)](https://joincolony.github.io/colonynetwork/whitepaper-tldr-reputation/).
- Colony, [Lazy Consensus](https://docs.colony.io/learn/governance/lazy-consensus/).
- Colony, [The Metacolony and CLNY](https://docs.colony.io/learn/payments-and-tokens/the-metacolony-clny/).
- Colony blog, [chain migration](https://blog.colony.io/chain-migration/) and [going multi-chain (Arbitrum, April 2024)](https://blog.colony.io/colony-is-going-multi-chain/).
- JoinColony, [GitHub / Colony Network](https://github.com/JoinColony).

## DAOhaus & the Moloch framework

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/daohaus
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Category** | DAO framework · no-code summoner · [Safe](/wiki/dao-governance/tooling/treasury/safe) module |
| **Framework** | Moloch v1 (2019) → v2 → **Baal** (Moloch v3, [HausDAO/Baal](https://github.com/HausDAO/Baal)) |
| **Summoner app** | [DAOhaus](https://daohaus.club/) — no-code UI to deploy and run a Moloch DAO |
| **Governed by** | HausDAO (itself a Moloch DAO) |
| **Signature mechanic** | **Ragequit** — burn shares/loot to withdraw a proportional slice of the treasury |
| **Membership units** | **Shares** (vote + exit) · **Loot** (exit only) |
| **Networks** | Ethereum mainnet · Optimism · Arbitrum · Gnosis Chain · Polygon · Base (testnet: Sepolia) — [docs.daohaus.club](https://docs.daohaus.club/networks) |
| **Contract status** | Baal's last commit is **11 June 2024**; the contracts are effectively frozen (see below) |
| **Operating surface** | [Admin App](https://admin.daohaus.club/) · [user guide](https://guide.daohaus.club/) · [developer docs](https://docs.daohaus.club/) |
| **2026 direction** | Autonomous **agent members** — a CLI, a hosted read/pinning service, and a published vote-decision procedure |
| **License** | Open source (MIT / GPL); primary sources: [Moloch v1](https://github.com/MolochVentures/moloch), [Baal](https://github.com/HausDAO/Baal) |

**DAOhaus** is the no-code home of the **Moloch** DAO framework — the lineage that gave the whole industry the word _[ragequit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)_. Where a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig holds money and [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) holds opinions, a Moloch DAO fuses treasury, membership, proposals, and a guaranteed exit into one minimal on-chain contract. DAOhaus is the app that lets anyone deploy and operate one without writing Solidity, and the community (organised as HausDAO) that maintains the framework.

## The Moloch lineage

The original [Moloch v1](https://github.com/MolochVentures/moloch) contract shipped in 2019 to fund Ethereum public goods, and its GitHub description — a line from Ginsberg's _Howl_ — set the tone: a deliberately ruthless, minimal DAO. It introduced four primitives that recur everywhere in this wiki: **shares** (membership + voting power + a claim on the treasury), a **guild bank** (the pooled treasury), a simple **proposal and majority vote**, and — the innovation that mattered — **ragequit**: any member can burn their shares and walk away with a proportional slice of every asset in the guild bank.

Ragequit is a design answer to the [tyranny-of-the-majority problem](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): a voting bloc cannot expropriate the minority, because the minority can always exit at fair value before a contested proposal executes. [Moloch v2](https://github.com/MolochVentures/moloch) generalised the model — multiple treasury tokens, guild-kick proposals, and a second non-voting unit called **loot** that carries exit rights but no vote.

## Shares, loot, and the guild bank

A Moloch DAO tracks two internal units. **Shares** grant voting power, the right to submit and process proposals, and a redeemable claim on the treasury. **Loot** grants the same treasury claim but no vote — useful for paying contributors or investors economic upside without handing them governance control. Both are minted through proposals, and both can be ragequit.

Everything routes through proposals against the guild bank: request shares/loot in exchange for a tribute of tokens, spend treasury funds, add or kick members, or call an arbitrary external contract. Because exit is always available, Moloch DAOs can run on thin process — there is less need for elaborate [governance machinery](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) when the credible threat is "if you pass this, I leave with my share."

## Baal — Moloch v3

The current framework is **Baal**, described by [its repository](https://github.com/HausDAO/Baal) as "a minimal yet composable DAO template continuing work from the Moloch, Minion, Compound/OZ and Safe frameworks." Baal keeps shares and loot as transferable ERC-20s, retains ragequit, and adds two things that make it modern:

- **Safe-native execution.** A Baal DAO implements the [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) standard and runs as a module on a [Gnosis Safe](/wiki/dao-governance/tooling/treasury/safe), so the treasury is a battle-tested Safe while governance logic lives in a separate, upgradeable module.
- **Shamans.** Privileged roles (minting shares, managing membership, pausing transfers) are delegated to external _shaman_ contracts rather than trusted addresses — composable permissions that pair naturally with [roles](/wiki/dao-governance/tooling/membership/hats-protocol) tooling.

Baal deploys on Ethereum mainnet, Optimism, Arbitrum, Gnosis Chain, Polygon and Base, with Sepolia for testing, per the [supported-networks page](https://docs.daohaus.club/networks) of the developer docs.

## Where the code stands

A framework page that says only “the current framework is Baal” hides the more useful fact, which is that the _contracts_ and the _product_ are on very different clocks.

The contract layer has stopped moving. [HausDAO/Baal](https://github.com/HausDAO/Baal)'s default branch is not `main` but a feature branch, `feat/baalZodiac`, and its [last commit landed on 11 June 2024](https://github.com/HausDAO/Baal/commits/feat/baalZodiac) (a factory upgrade); `main` itself has been untouched since [28 March 2022](https://github.com/HausDAO/Baal/commits/main). The original [Moloch v1 repository](https://github.com/MolochVentures/moloch) last saw a push on 30 December 2022. For a framework this is not necessarily decay — Moloch's whole design claim is minimalism, and a small audited contract that has not changed in two years is doing what it promised. But it does mean that anything new in the DAOhaus world arrives _around_ the contracts rather than inside them, through Zodiac modules, shamans and off-chain tooling.

The product layer, by contrast, is actively maintained. The [Admin App](https://admin.daohaus.club/) is the current operating surface (its repository was last pushed on 1 August 2026), the [user guide](https://guide.daohaus.club/) is maintained by the PublicHAUS community, and the [developer docs](https://docs.daohaus.club/) carry the contract reference, subgraph endpoints and deployment addresses. Reading the two clocks together is the honest summary: **frozen primitives, moving surface**.

## Agents as DAO members

The clearest thing DAOhaus shipped in 2026 is not a contract change at all. It is a stack for running an **autonomous agent as a member of a Moloch DAO**, split across three repositories: [moloch-skills](https://github.com/HausDAO/moloch-skills) (agent skills for reading and acting on Moloch v3 DAOs), [moloch-agent](https://github.com/HausDAO/moloch-agent) (a local CLI runtime), and [moloch-service](https://github.com/HausDAO/moloch-service) (a hosted helper that proxies subgraph reads and pins artifacts to IPFS).

What makes it worth a wiki entry is that the trust boundary is written down rather than assumed. The service's own README states that it “must never receive private keys”, that it “does not sign transactions”, and that it “does not make governance decisions”; signing stays in the local agent runtime. That is a deliberate split between _reading the DAO_, which is centralised and convenient, and _acting on the DAO_, which is not.

The [published vote-decision flow](https://github.com/HausDAO/moloch-skills/blob/main/VOTE_DECISION_FLOW.md) is more interesting still, because it is an explicit answer to a question most [voting tools](/wiki/dao-governance/tooling/voting/snapshot) leave to the voter. It states that agents “should not vote only from proposal text”, and requires a proposal to be classified first — signal, membership, treasury, metadata, governance settings, or **arbitrary execution** — and then checked for whether “action data match[es] proposal text” before any vote is cast. The document is careful to be “opinionated about _how_ agents decide, not _what_ values they must hold,” leaving the mandate to the operator.

Two things follow for the rest of this wiki. First, that final classification bucket is the whole problem of [typed versus arbitrary execution](/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution): a proposal that can encode any call is one an agent (or a human) cannot judge from its title. Second, an agent holding shares is a [legal-personhood](/wiki/dao-governance/concepts/membership/dao-legal-structures) question as much as a technical one — the same question [MIDAO](/wiki/dao-governance/tooling/analytics/midao) started selling a wrapper for in the same year. The general case — what changes when software holds the shares rather than assisting whoever does — is covered at [autonomous agents as DAO members](/wiki/dao-governance/concepts/membership/autonomous-agent-members).

## Who runs on it

Baal's `sponsorThreshold`, `proposalOffering` and `minRetentionPercent`, and the agent runbook's "no new proposal while three are in voting" rule, are compared against Compound and Moloch's equivalents at [proposal throttles and rate limits](/wiki/dao-governance/concepts/voting/proposal-throttles-and-rate-limits).

The Moloch pattern anchors a whole class of [grant and investment DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos). [The LAO](/wiki/daos/investment/the-lao) and its MetaCartel-lineage cousins are Moloch-based venture DAOs; [MolochDAO](/wiki/daos/public-goods/molochdao) itself continues as a public-goods funder. DAOhaus lowered the barrier from "deploy a contract" to "fill in a form," which is why the framework shows up under so many small, purpose-built treasuries rather than the mega-DAOs that dominate [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) rankings.

See also the broader [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) for where a summoner sits relative to [Tally](/wiki/dao-governance/tooling/voting/tally), [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), and voting front-ends.

## How Caper approaches this

Caper treats ragequit as a first-class primitive rather than an emergency hatch. Every [caper](/wiki/foundations/what-is-a-caper) holder can call [exit](/wiki/governance/execution) on-chain, burning their tokens to redeem a proportional slice of the treasury — a direct descendant of Moloch's exit. The difference is what sizes the slice: a caper's exit share equals its _canonical vote weight_, the same metric that determines voting power, so the treasury claim scales with both what a member holds and the [vote weight](/wiki/governance/voting-mechanisms) they have earned, not a flat pro-rata of one token. The exit right that Moloch pioneered for minority protection becomes, in Caper, the everyday accountability lever on the founder and the treasury.

## Llama

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/llama
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Category** | Onchain governance and access-control framework (Solidity / Foundry) |
| **Built by** | Llama — a DAO service provider whose [GitHub organisation](https://github.com/llamaxyz) dates to 12 November 2020 |
| **Framework launched** | Repository created 10 January 2023; first instances deployed on-chain 19 August 2023 |
| **Status** | 🔴 Wound down — llama.xyz resolves to nothing, and all 52 of the organisation's public repositories are archived (last push anywhere, 16 August 2024) |
| **Still deployed on** | Ethereum, Optimism, Arbitrum, Base, Polygon, Blast, Zora — [one factory address](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) on every chain |
| **Measured adoption** | 21 instance creations across the three chains readable this run; ~14 distinct organisations |
| **Audits** | Three [Spearbit](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit.pdf) reviews and one [Code4rena](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Code4rena-Audit.md); the last is [v1.1.0, January 2024](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit-3.pdf) |
| **Licence** | MIT |
| **Related** | [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity), [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), [Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol), [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) |

**Llama** was an onchain governance and access-control framework for smart contracts, and — separately — the name of the firm that built it. The firm spent 2021–2022 as one of the better-known DAO service providers, writing and shepherding proposals for [Aave](/wiki/daos/lending/aave-dao) in particular; its repository list still reads as a record of that work, from [the Aave treasury dashboard's ETL](https://github.com/llamaxyz/aave-etl) through [an escrow between Friends With Benefits and Gamma Strategies](https://github.com/llamaxyz/fwb-liquidity-provisioning) to [the Gitcoin–Radicle Public Goods Alliance](https://github.com/llamaxyz/gtc-rad-public-goods-alliance). In January 2023 it turned the pattern it had been implementing by hand into a product: a framework for organisations that need to delegate narrow, revocable authority over a treasury rather than put every action to a token vote.

The firm is gone. This page is not about that — the shutdown, and the general problem it belongs to, are covered on [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity), where Llama is one of a measured cohort. What is documented here is what the framework did, who actually ran one, and what happened to those deployments after there was nobody left to maintain them.

## Roles, not token weight

Most onchain governance in this period was token-weighted: your influence is your balance, and every executable action passes through the same proposal queue. Llama started from the opposite premise. Membership of a Llama instance is a **non-transferable NFT** — a policy — and the policy encodes which roles the holder has. Permission is then a specific triple: a role, a target contract, and a function selector. A policyholder does not have "voting power"; they have the right to call _this function on that contract_, and nothing else.

Action execution rules are modular. Rather than one quorum for everything, an instance attaches a **strategy** per permission, and the framework ships five: relative-quantity quorum, relative-holder quorum, relative-unique-holder quorum, absolute quorum, and absolute peer review. The same instance can therefore require a full role-wide supermajority to move the treasury while letting a two-of-five peer review approve a parameter change, without either rule leaking into the other.

Funds are held in `LlamaAccount` contracts belonging to the instance, with a delegation-aware variant for governance tokens the treasury holds in other protocols — the same problem [Safe](/wiki/dao-governance/tooling/treasury/safe)-based treasuries solve with modules. The design goal, stated in the repository, is programmatic control of funds: an approved action is a call the contracts make, not an instruction a multisig is trusted to carry out. The nearest live comparisons today are [Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol) for the role-as-token idea and [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) for modular execution rules bolted onto an existing treasury.

## How an instance is put together

Everything is deployed from a single `LlamaFactory`, which sits at [0xFf5d4E22…AbEB](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) — the identical address on all seven supported chains, the signature of a deterministic deployment. Each instance the factory creates is a `LlamaCore` (the action queue and execution engine), a `LlamaPolicy` (the role NFTs and the permission set), and an executor that performs approved calls. The strategy and account logic contracts are shared singletons the instances point at, so a new organisation deploys a small amount of code rather than a full framework. A read-only `LlamaLens` helper exists purely to make instances legible to interfaces, and two governance scripts batch the common multi-step administrative changes.

The framework was reviewed four times before its last release: [Spearbit in June 2023](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit.pdf), [Code4rena](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Code4rena-Audit.md), a second Spearbit in August 2023, and [a third for v1.1.0 in January 2024](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit-3.pdf). All four reports, and the framework's own [documentation directory](https://github.com/llamaxyz/llama/tree/main/docs), are still readable in the [archived repository](https://github.com/llamaxyz/llama) — which matters more than it sounds, because the hosted docs site went with the domain.

## Who actually deployed one

Because every instance creation emits an event from a known factory address, the adoption question has an exact answer rather than a marketing one. Reading the factory's decoded logs on the three chains whose public explorers answered this run — Ethereum, Base and Arbitrum — gives **21 instance creations**, and resolving each instance's on-chain name gives roughly fourteen distinct organisations. Several appear on more than one chain, which is one deployment decision rather than several.

- **Ethereum (5).** Llama's own instance and a "Demo", both dated 19 August 2023 — the framework's first day live; [the DeFi Education Fund](https://etherscan.io/address/0x585ebAC736B9d9A8Ee26C7A9fDa7a3987b4ff517), whose Uniswap proposal work has [its own repository](https://github.com/llamaxyz/def-uniswap-proposal) in the same organisation; MYSO; Daylight; and [Towns Mainnet](https://etherscan.io/address/0x343998c7056f75341C434E4db39A8be99A5EA4B4).
- **Base (7).** [Moonwell](https://basescan.org/address/0x9Ea8D23f0221A46152dF67097184C701899553B7), Socket, River, Drakula, Daylight, plus the launch-day Llama and Demo instances again.
- **Arbitrum (9).** [Perennial](https://arbiscan.io/address/0x635DE406f437911BCefFE6973CeD931A4ceb6cce), RabbitHole, a LI.FI test instance, three separate Socket deployments, Daylight, and the launch-day pair.

That is a real but small install base, and it is worth reading honestly in both directions. Fourteen organisations is more than a failed product usually gets, and several — Moonwell, Socket, Perennial, the DeFi Education Fund — are substantial. It is also far below the scale at which a framework becomes infrastructure other people build on, which is the outcome the [tooling market](/wiki/dao-governance/tooling/dao-tooling-overview) of that period was competing for.

## The framework outlived the company

The most interesting entry in that census is the last one. The Towns Mainnet instance was created on **3 March 2025**: roughly six and a half months after the final commit to any Llama repository, and around four months after llama.xyz stopped serving a page at all. Somebody deployed a production governance instance from a framework whose authors had already left, and it worked, because a factory on an immutable chain does not know or care whether its maintainer still exists.

This is the concrete case of the failure class [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) calls the dangerous one — a live contract with a dead maintainer — and it cuts both ways. On the good side, nothing was taken away: existing instances kept executing, the code is MIT-licensed and readable, the audit reports survived in the repository, and the on-chain record needs no vendor to be reconstructed. What did stop is everything that was not on-chain. There is no interface, no hosted documentation, no upgrade path, and no one to write a patch: the security review a prospective adopter would rely on is frozen at v1.1.0 in January 2024, and any vulnerability found after that date has no maintainer to report it to. An organisation adopting a framework in this state is choosing to become its own maintainer, whether or not it notices at the time.

## How Caper approaches this

Caper's answer to the same exposure is structural rather than promissory, and it is visible in the contract split. Each caper's state tier — the treasury, the proposal record and the ballots — is deployed once and never migrated, so nothing about a caper's existing decisions depends on a maintainer being around. The logic tier that carries the pricing and execution plumbing _can_ be replaced, but only by an [UPGRADE proposal](/wiki/governance/execution) passed by the `$CAPER` caper's own members and routed through the protocol's registry — there is no admin key that upgrades it and no vendor whose disappearance either freezes it or lets it change. The trade Llama's instances face, between an immutable contract and a maintained one, is put to a vote rather than settled by whoever is still employed. See [what a caper is](/wiki/foundations/what-is-a-caper) for the shape of that split.

## References

All figures on this page were read directly on 9 August 2026. [The llamaxyz GitHub organisation](https://github.com/llamaxyz) — 52 public repositories, every one flagged archived, latest push anywhere 16 August 2024. [llamaxyz/llama](https://github.com/llamaxyz/llama) — the framework repository, archived, MIT, created 10 January 2023. [LlamaFactory on Ethereum](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) — the same address on all seven deployment chains; instance counts and dates come from its decoded `LlamaInstanceCreated` logs on Ethereum, Base and Arbitrum, and each instance's name from an `eth_call` to its `LlamaCore`. The domain's disappearance is dated from the Internet Archive's index for llama.xyz, which records HTTP 200 responses through 10 October 2024 and 404s from 30 November 2024 onward.

## SPL Governance & Realms

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/spl-governance
Updated: 2026-07-27

**SPL Governance** is the on-chain program that most decentralized autonomous organizations on **Solana** run on, and **Realms** is the open-source web app that fronts it. The program is, in its maintainers' words, ["a program the chief purpose of which is to provide core building blocks and primitives to create Decentralized Autonomous Organizations"](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) – deliberately ["DAO type and asset type agnostic"](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) so a treasury, a protocol, or an NFT community can all be governed by the same primitive. It is the Solana equivalent of what [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) plus [Safe](/wiki/dao-governance/tooling/treasury/safe) are on the EVM: a canonical governance kernel that everything else composes around.

|  |  |
| --- | --- |
| **Category** | On-chain governance framework (Solana) · program + shared front-end |
| **Program** | SPL Governance – part of the [Solana Program Library](https://github.com/solana-labs/solana-program-library/tree/master/governance), now maintained by the [Mythic Project](https://github.com/Mythic-Project/solana-program-library/tree/master/governance) (took over the program and the Realms UI from Solana Labs) |
| **Front-end** | [Realms](https://app.realms.today/) – the [open-source governance UI](https://github.com/Mythic-Project/governance-ui) used by most Solana DAOs to create and run a realm |
| **Mainnet program IDs** | `GovER5Lthms3bLBqWub97yVrMmEogzX7xNjdXpPCVZw` (default) · `GTesTBiEWE32WHXXE2S4XbZvA5CrEc4xs6ZgRe895dP` (test) |
| **Vote model** | Token-weighted – a **community** mint and an optional **council** mint per realm; deposit = voting weight |
| **Extensibility** | Swappable voter-weight _addins_ (plugins): [Voter Stake Registry](https://github.com/blockworks-foundation/voter-stake-registry), [NFT voter, quadratic, gateway](https://github.com/solana-labs/governance-program-library) |
| **Notable users** | [Marinade](/wiki/daos/staking/marinade), [Jito](/wiki/daos/staking/jito), Mango, Metaplex, Helium (via VSR) |
| **Docs** | [docs.realms.today](https://docs.realms.today/) |

## The primitive: a realm, two mints

Everything in SPL Governance hangs off a **realm**. As the [program README](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) puts it, the ["Realm account ties Community Token Mint and optional Council Token mint to create a realm."](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) Members deposit governing tokens into the program and use ["the deposited amount as their voting weight to vote on Proposals."](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) That is plain [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) at the base layer.

The optional **council** mint is what makes the model expressive: a realm can run two voting populations at once. A small trusted council can hold veto or fast-track powers over the same DAO the broad community token governs – the program notes ["users can submit Proposals that have a different voting population from a different mint that can affect the same DAO."](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) It is the on-chain version of the two-chamber pattern many DAOs reach for, without bolting on a separate tool.

## Realms: the shared front-end

Almost no one interacts with the raw program. [Realms](https://app.realms.today/) is the [open-source UI](https://github.com/Mythic-Project/governance-ui) – ["a sophisticated, fully on-chain platform designed to simplify and enhance the management of decentralized autonomous organizations on the Solana blockchain"](https://docs.realms.today/) – that the large majority of Solana DAOs deploy and operate through. Its docs frame a realm around three moving parts: ["DAOs, proposals, and votes."](https://docs.realms.today/)

Because the front-end is shared and open source, a new Solana DAO gets a working governance surface – proposal creation, delegation, treasury views, member lists – without building any of it, the same way an EVM project reaches for [Tally](/wiki/dao-governance/tooling/voting/tally) or [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) rather than shipping its own governance app. Realms and the program are maintained together by the [Mythic Project](https://github.com/Mythic-Project/solana-program-library/tree/master/governance).

## Proposals, votes, and a governed treasury

A ["Proposal is an instance of a Governance created to vote on and execute a given set of instructions."](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) It moves through draft → voting → executing → completed, and a ["vote is tipped once it passes the defined vote_threshold"](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) – early resolution once the outcome is mathematically settled, rather than always waiting out the clock.

What separates SPL Governance from a pure [off-chain signalling tool](/wiki/dao-governance/tooling/voting/snapshot) is that the treasury _is_ the DAO. Assets are held in specialised governance accounts that only a passed proposal can move:

- **ProgramGovernance** – controls program (smart-contract) upgrades.
- **MintGovernance** – controls an SPL token mint (issuance).
- **TokenGovernance** – controls transfers out of a token account (the treasury proper).

Because execution is on-chain and account-scoped, a Realms DAO owns and moves its own funds by vote – the proposal _is_ the transaction, not a request for a multisig to act later.

## The plugin architecture: voter-weight addins

The program is ["modular and uses an open/close architecture where individual parts of the program\u2019s behavior can be customized through external plugins."](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) The default one-token-one-vote weight ["can be swapped with a custom program implementation"](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) – an _addin_ that computes each member's voting power however the realm wants. This is the most consequential design choice in the stack: governance math is pluggable.

The addins in wide use:

- [Voter Stake Registry (VSR)](https://github.com/blockworks-foundation/voter-stake-registry) – the dominant one, built by the [Blockworks Foundation](https://github.com/blockworks-foundation/voter-stake-registry). It lets a realm ["control which token mints can be used to vote, and at what scaling factor"](https://github.com/blockworks-foundation/voter-stake-registry), and lets members ["lock up tokens with different vesting schedules"](https://github.com/blockworks-foundation/voter-stake-registry) where ["locked up tokens may have extra voting weight."](https://github.com/blockworks-foundation/voter-stake-registry) It also supports [clawback](https://github.com/blockworks-foundation/voter-stake-registry) of locked grants. That makes VSR Solana's [vote-escrow (ve)](/wiki/dao-governance/concepts/voting/vote-escrow) analogue – time-lock for weight.
- [NFT voter](https://github.com/solana-labs/governance-program-library) – voting power derived from NFT holdings across accepted collections, for NFT-native communities.
- [Quadratic and Gateway plugins](https://github.com/solana-labs/governance-program-library) – a quadratic-weighting addin, and a Civic-gateway addin that gates voting behind identity/uniqueness passes.

An addin can also cap the _max_ voter weight, so quorum is measured against an effective supply rather than the raw mint – the same accounting problem [token-weighted systems](/wiki/dao-governance/concepts/voting/token-weighted-voting) everywhere have to solve.

## In production

SPL Governance and Realms are the default governance layer for the Solana ecosystem. [Marinade](/wiki/daos/staking/marinade) runs its mDAO in Realms with MNDE locked under VSR; [Jito](/wiki/daos/staking/jito) governs JTO, StakeNet, and its NCN fee routing through it; Mango, Metaplex, and Grape are long-running Realms DAOs; and [Helium](https://github.com/helium/voter-stake-registry) governs HNT through its own fork of VSR after migrating to Solana. Because the program and UI are shared, these DAOs differ mainly in _which addin_ and _which council setup_ they choose – the kernel underneath is identical.

## Limits and failure modes

- **Council centralisation.** The council mint that makes two-chamber governance possible is also the usual point of centralisation – an early-stage realm is frequently a small multisig council wearing a DAO's clothes until the community token is genuinely distributed.
- **Upgrade authority.** A DAO is only as trustless as its **ProgramGovernance** discipline. If the realm's own program upgrade authority isn't itself governed (or is retained by the team), the on-chain execution guarantees are advisory.
- **Plugin trust.** A voter-weight addin is unrestricted code that decides who has power. A buggy or malicious registrar config can silently mis-weight votes, and VSR lockups concentrate weight with the earliest, longest-locked holders – the [ve trade-off](/wiki/dao-governance/concepts/voting/vote-escrow) in full.
- **Turnout.** On-chain execution does not fix [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy); a realm still has to reach quorum, and many run on a thin active minority.

## How Caper approaches this

SPL Governance's pluggable weight is its strength and its exposure: VSR turns voting power into freely-tradeable capital plus an optional lockup multiplier, so a large enough bag – or a long enough lock – still buys the most say. [Caper](/wiki/foundations/what-is-a-caper) is built the other way. Its vote weight is a fixed formula, not a swappable addin: `w = (t · v) / (V · T)`, where a member's held governance tokens _t_ are multiplied by their earned, non-transferable votes _v_ (the `compute_vote_weight` formula in the Caper contracts). A zero in any input yields zero, so a bag that never participates captures no control.

Those votes are a **soulbound proof-of-vote token** (non-divisible, with mint and burn locked to the DAO's own immortal state component) – there is no VSR-style registrar to reconfigure and no market to buy weight on. And where a Realms DAO's members can only exit by selling on a secondary market, Caper's `exit` gives every member a pro-rata claim on the treasury sized at exactly that canonical weight, pre-burn – a built-in [credible exit](/wiki/dao-governance/concepts/voting/vote-escrow) rather than a purely political one. Same job as SPL Governance – own and move a treasury by vote – with participation, not capital, as the unit of power. See [Caper proposals](/wiki/governance/proposals).

## References

- [SPL Governance program README](https://github.com/solana-labs/solana-program-library/blob/master/governance/README.md) – solana-labs/solana-program-library
- [Mythic Project fork](https://github.com/Mythic-Project/solana-program-library/tree/master/governance) – current maintainer of the program and Realms UI
- [Realms documentation](https://docs.realms.today/) · [developer resources: spl-governance](https://docs.realms.today/developer-resources/spl-governance)
- [governance-ui](https://github.com/Mythic-Project/governance-ui) – the open-source Realms front-end
- [Voter Stake Registry](https://github.com/blockworks-foundation/voter-stake-registry) (Blockworks Foundation) · [governance-program-library](https://github.com/solana-labs/governance-program-library) (NFT / quadratic / gateway addins)

## Zodiac (Gnosis Guild)

URL: https://caper.network/wiki/dao-governance/tooling/frameworks/zodiac
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Category** | Execution · [Safe](/wiki/dao-governance/tooling/treasury/safe) modules · module standard |
| **Built by** | [Gnosis Guild](https://www.gnosisguild.org/) (2022); open standard, LGPL-3.0+ |
| **What it is** | A library of composable contracts that turn a [Safe](/wiki/dao-governance/tooling/treasury/safe) from a plain multisig into a programmable, DAO-governed account |
| **Architecture** | **Avatar** · **Module** · **Modifier** · **Guard** — each an interface, freely composable |
| **Key modules** | Reality Module (SafeSnap) · Optimistic Governor · Delay · Roles · Exit |
| **Source** | [github.com/gnosisguild/zodiac](https://github.com/gnosisguild/zodiac) · [zodiac.eco](https://www.zodiac.eco/) |
| **Related** | [Safe](/wiki/dao-governance/tooling/treasury/safe) · [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) · [Exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) · [Tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Zodiac** is the missing piece between how most DAOs _vote_ and how they _act_. A community runs its polls on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) — gasless, off-chain, and non-binding — while its money sits in a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig that only a handful of signers can move. Between the two is a gap: something has to take a passed vote and actually execute the transaction, and for years that "something" was a small human multisig trusted to faithfully carry out the community's decision. Zodiac, an open contract standard built by [Gnosis Guild](https://www.gnosisguild.org/) and first released in 2022, is the toolkit that closes that gap — letting a Safe execute the outcome of a vote directly, on trust-minimised rails, without handing a multisig the keys to the treasury.

## The Avatar / Module / Modifier / Guard standard

Zodiac's power is that it is a **standard**, not a single product. Per the [Zodiac specification](https://github.com/gnosisguild/zodiac/blob/master/README.md), it defines four composable roles around a programmable account:

- **Avatar** — the account that holds the assets and executes transactions (a [Safe](/wiki/dao-governance/tooling/treasury/safe) is the canonical avatar). It implements the `IAvatar` interface, whose `execTransactionFromModule` function is how everything else moves it.
- **Module** — a contract the avatar _enables_ that carries decision-making logic and can tell the avatar what to execute. A DAO can enable several at once.
- **Modifier** — a contract that sits _between_ a module and the avatar and alters the module's behaviour — for example forcing a mandatory time delay on everything the module tries to do. A modifier looks like an avatar to the module above it, so modules and modifiers chain.
- **Guard** — a contract enabled on a module that runs pre- and post-checks on each transaction, constraining what it is allowed to do.

Because each role is just an interface, the pieces snap together like an expansion pack: you can chain a _Delay_ modifier behind a _Reality_ module behind a Safe, and the Safe neither knows nor cares which combination it is. That composability — rather than the monolithic, all-or-nothing design of a full framework like early [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) — is the whole thesis.

## Reality Module (SafeSnap): executing a Snapshot vote

The flagship module — originally shipped as **SafeSnap** and now the [Reality Module](https://github.com/gnosisguild/zodiac-module-reality) — is what lets an off-chain [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote move an on-chain treasury. When a community drafts a Snapshot proposal, it can attach an array of transaction payloads to be executed if the vote passes. The outcome is then posted as a question to the [Reality.eth](https://reality.eth.limo/) optimistic oracle: anyone can assert "this proposal passed," a bond backs the assertion, and unless someone bonds a counter-claim within a challenge window, the result finalises. Disputes can escalate to [Kleros](https://kleros.io/) arbitration. Once the answer resolves and a cooldown elapses, the transactions become executable by anyone through the Safe — the multisig is out of the loop entirely. The oracle, not a trusted signer, is what asserts the off-chain vote's result on-chain, which is why this pattern is called **optimistic governance**. A sibling module, the [Optimistic Governor](/wiki/daos/infrastructure/uma), does the same job against [UMA](/wiki/daos/infrastructure/uma)'s optimistic oracle instead of Reality.eth.

## The rest of the kit: Delay, Roles, and Exit

The other modules address the everyday failure modes of running an on-chain organisation:

- **Delay Modifier** — enforces a mandatory cooldown between when a transaction is proposed and when it can execute, giving members a window to react (or exit) before anything moves. It turns any module into a timelocked one.
- **Roles Modifier** — grants scoped permissions, so a module or address can be allowed to call _only_ specific functions on specific contracts (e.g. "this contributor may stake treasury assets in Aave but may not withdraw them"). It is the least-privilege layer for delegated treasury operations.
- **Exit Module** — lets any holder of a designated token redeem it at any time for a _proportional share_ of the avatar's assets, generalising [MolochDAO](/wiki/daos/public-goods/molochdao)'s `rageQuit()` into a bolt-on any Safe can install ([zodiac-module-exit](https://github.com/gnosisguild/zodiac-module-exit), Exit App launched April 2022). It is the clearest on-chain expression of a member's [right to exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): dissent by withdrawal rather than by vote.

## Where it sits in the stack

Zodiac occupies the **execution and permissioning layer** of the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) — the connective tissue between the voting layer ([Snapshot](/wiki/dao-governance/tooling/voting/snapshot)), the custody layer ([Safe](/wiki/dao-governance/tooling/treasury/safe)), and the binding on-chain governance that tools like [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally) front. Its appeal to large DAOs is that it lets them keep cheap, high-participation off-chain voting _and_ get trust-minimised execution, without adopting a heavyweight on-chain [Governor](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) for every decision. The trade-off is assembly: a Zodiac-based DAO is a set of modules a team wires together and must configure correctly, and a misconfigured module or oracle is its own attack surface — the price of composability is that no single vendor hands you a finished, audited whole.

## How Caper approaches this

Zodiac exists because, in the mainstream stack, voting, custody, execution and exit are _separate contracts_ a DAO must bolt together — and each seam is a place where a multisig, an oracle, or a misconfiguration can sit between the members and their treasury. [Caper](/wiki/foundations/what-is-a-caper) takes the opposite route: those layers are one contract. A caper's [proposals](/wiki/governance/proposals), [votes](/wiki/governance/voting) and [execution](/wiki/governance/execution) are native to the protocol, so there is no SafeSnap-style bridge to trust — a passed proposal _is_ the authorisation to execute.

The contrast is sharpest at the **Exit Module**. Zodiac's exit is an optional add-on that returns a share strictly proportional to a redeemable token's balance. In Caper, exit is not a module you choose to install — every member holds it by construction, and the share is weighted by the _same earned metric that sets voting power_. A member redeeming caper tokens t together with their soulbound votes v receives a treasury fraction of `(t · v) / (V · T)` — the identical `compute_vote_weight` formula used when they vote (verified against `contracts/logic/src/lib.rs`). The vote tokens are soulbound and non-transferable, so exit weight is earned participation, not just a token you can buy on the way out. The right to leave with your fair share isn't a feature a caper's founders remembered to enable — it's the same primitive as the right to be heard.

## References

- Gnosis Guild, [Zodiac — composable tooling for onchain entities](https://github.com/gnosisguild/zodiac) (standard & README).
- Gnosis Guild, [Reality Module](https://github.com/gnosisguild/zodiac-module-reality) and [Exit Module](https://github.com/gnosisguild/zodiac-module-exit) repositories.
- Snapshot, [SafeSnap / Reality plugin documentation](https://docs.snapshot.box/v1-interface/plugins/safesnap-reality).
- Reality.eth, [optimistic oracle](https://reality.eth.limo/); UMA, [Optimistic Governor (oSnap)](https://docs.uma.xyz/resources/osnap) — retired 15 December 2025.
- Gnosis Guild, [zodiac.eco](https://www.zodiac.eco/).

## Collab.Land

URL: https://caper.network/wiki/dao-governance/tooling/membership/collab-land
Updated: 2026-07-23

|  |  |
| --- | --- |
| **Tool** | [Collab.Land](https://www.collab.land/) (collab.land) — token-gated community-management bot |
| **Category** | Access control / membership verification — the chat-native token-gating bot that assigns and re-checks roles from on-chain holdings |
| **Platforms** | Discord and Telegram |
| **Core primitive** | **TGRs** (Token Gating Rules) → platform **roles** |
| **Rule types** | Balance-based (ERC-20 amounts) and Attributes-based (NFT traits); the Role Composition miniapp AND-combines multiple tokens |
| **Verification** | Wallet signs a message to attest ownership → the bot reads the public chain → grants the role; balances are re-verified on a schedule, so a role is _revoked_ when the holding is sold |
| **Coverage** | 40+ chains, 30+ wallets; admin via the [Command Center](https://cc.collab.land/) (cc.collab.land) |
| **Token** | $COLLAB — 1,000,000,000 fixed supply, ERC-20 on Optimism; governs the Collab.Land DAO |
| **Origin** | Built by Abridged, Inc.; live since Spring 2020, used by tens of thousands of communities |

**Collab.Land** ([collab.land](https://www.collab.land/)) is the original token-gating bot for chat communities: it verifies that a wallet holds the tokens a community requires, then grants and periodically re-checks the corresponding [role](https://docs.collab.land/help-docs/key-features/token-gate-communities/) in that community's Discord server or Telegram group. Live since [Spring 2020](https://www.collab.land/), it turned "hold this token to get in" into infrastructure that tens of thousands of communities now run, and it sits at the entrance of a large share of the DAOs catalogued elsewhere in this directory — the gate a new member passes through before they ever reach a [vote](/wiki/dao-governance/tooling/voting/snapshot).

## Token Gating Rules

A community's access policy is expressed as one or more [Token Gating Rules](https://docs.collab.land/help-docs/key-features/token-gate-communities/) (TGRs): each rule names a token contract, a threshold, and the platform role to grant when a wallet meets it. TGRs come in two shapes. **Balance-based** rules check a fungible amount — hold at least _N_ of an ERC-20 to earn a role — and are the common case for token communities. **Attributes-based** rules check NFT metadata, granting a role for holding a token whose traits match a set the admin specifies, so a single collection can drive many tiers. The Role Composition [miniapp](https://docs.collab.land/help-docs/key-features/command-center/) lets a rule require a combination — both an ERC-20 balance _and_ a specific NFT — for finer-grained membership than a single holding can express.

## How verification works

Collab.Land never takes custody and never asks for a transaction. A member connects a wallet and [signs a message](https://docs.collab.land/help-docs/key-features/token-gate-communities/) to attest they control that address; the bot then reads the public blockchain to confirm the wallet satisfies the community's TGRs and assigns the matching role. The design point that distinguishes a gating bot from a one-time allowlist is **re-verification**: Collab.Land re-checks balances on a schedule, so a role is removed when the holding that earned it is sold or transferred away. Membership tracks the wallet's current state rather than a snapshot taken at the door — a property that matters for the failure modes discussed under [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos), since a borrowed or briefly-held balance loses its role once returned.

## Where it sits in the stack

Collab.Land is one of three complementary answers to "who is a member, and what may they do." It is the **chat-native gate**: deeply integrated with Discord and Telegram, it is where most communities' membership is actually enforced day to day. [Guild.xyz](/wiki/dao-governance/tooling/membership/guild-xyz) sits beside it as a **platform-agnostic requirement engine** — composing the same on-chain facts into roles across many surfaces (Discord, Telegram, GitHub, gated forms) from one definition. [Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol) works one layer deeper, encoding **on-chain roles and permissions** as transferable authority a contract can check, rather than a chat role a bot assigns. Collab.Land answers _are you in the room_; Hats answers _may this address execute_. Most DAOs run more than one, and the [tooling overview](/wiki/dao-governance/tooling/dao-tooling-overview) maps how the access, execution, and voting layers fit together.

## The $COLLAB token and the Collab.Land DAO

In 2023 Collab.Land distributed a governance token, **$COLLAB**, an ERC-20 on Optimism with a fixed supply of one billion. The published [allocation](https://tokeninsight.com/en/coins/collabland/tokenomics) reserves 50% to the DAO treasury, 25% to the team and its investors, and 25% to a retroactive airdrop — itself split 60% to the top-100 Discord communities, 16% each to Patron and Membership NFT holders, and 8% to members verified as of 14 February 2023. The [airdrop reached over two million wallets](https://www.coindesk.com/business/2023/02/23/collabland-to-airdrop-token-to-over-2m-wallets-on-optimism), one of the larger eligibility sets a community tool has distributed to. Token holders form the **Collab.Land DAO**, which votes on feature requests, funds bounties, and curates the miniapp Marketplace — making the gatekeeper for thousands of communities itself a token-governed organisation, and a fitting entry in a directory of DAOs.

## How Caper approaches this

A gating bot answers a binary question — _are you in?_ — and re-checks it periodically. That is the right tool for guarding a chat, but it is not how influence over a treasury should be measured: presence is not the same as stake in a decision. A [caper](/wiki/foundations/what-is-a-caper) does not gate the room at all — holding the token _is_ membership — and it does not reduce standing to a yes/no role. Voting weight is computed continuously from what a member actually holds: in the contract ([contracts/logic/src/lib.rs](https://github.com/)) `compute_vote_weight` returns `(held_amount × members_votes) / (vote_supply × tokens_in_circulation)`, so both a member's balance and their cast vote-tokens price their say — there is no role that is simply on or off. And where a gating bot's only lever against a member is to strip a role, a caper gives the outvoted member the [exit right](/wiki/governance/proposals): the same weight that measures your vote also measures the treasury share you can withdraw when a decision goes against you. Collab.Land decides who may enter; a caper decides how much each member's holding counts and what they can take with them if they leave.

## References

- Collab.Land, [Token Gating and TGRs](https://docs.collab.land/help-docs/key-features/token-gate-communities/) (balance- vs attributes-based rules, verification flow)
- Collab.Land, [Command Center](https://docs.collab.land/help-docs/key-features/command-center/) (admin portal, miniapps)
- Collab.Land, [homepage](https://www.collab.land/) (Spring 2020 launch, 40+ chains, tens of thousands of communities)
- CoinDesk, [Collab.Land to Airdrop Token to Over 2M Wallets on Optimism](https://www.coindesk.com/business/2023/02/23/collabland-to-airdrop-token-to-over-2m-wallets-on-optimism) (2023)
- TokenInsight, [$COLLAB tokenomics](https://tokeninsight.com/en/coins/collabland/tokenomics) (1B supply, allocation, DAO governance)

## Guild.xyz

URL: https://caper.network/wiki/dao-governance/tooling/membership/guild-xyz
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Tool** | [Guild](https://guild.xyz/) (guild.xyz) — token-gated access and community-management platform |
| **Category** | Access control / authorization layer — decides who may enter a gated space and what role they hold |
| **Core primitives** | **Requirements** → **Roles** → **Rewards** |
| **Gates** | Discord, Telegram, GitHub, Google Workspace, gated forms — 100+ integrations across 20+ chains |
| **Requirement types** | On-chain (token/NFT/POAP holdings, transactions, contract interaction), social proof, allowlists, other-guild activity, time-based |
| **Sybil resistance** | Native wallet-activity checks + [Human Passport](/wiki/dao-governance/tooling/membership/human-passport) (formerly Gitcoin Passport) Unique Humanity Score |
| **Origin** | Built by the [Agora Space](https://agora.space/) team (formerly ZGEN, founded 2020, Szeged, Hungary) |
| **Pricing** | Freemium — free to start, paid tiers for scale |
| **Related** | [Friends With Benefits](/wiki/daos/social/friends-with-benefits) · [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) · [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Guild** ([guild.xyz](https://guild.xyz/)) is the authorization layer for token-gated communities: it decides _who may enter a space and what role they hold there_, based on what a wallet holds or has done on-chain. Where a governance contract like [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) answers "whose vote counts," Guild answers the prior question — "who gets into the room at all." It is the plumbing behind most of the token-gated Discords, Telegram groups, and members-only spaces in Web3, including social DAOs such as [Friends With Benefits](/wiki/daos/social/friends-with-benefits). It is often paired with [Collab.Land](/wiki/dao-governance/tooling/membership/collab-land), the chat-native gating bot most communities run at the Discord/Telegram door.

## Requirements, Roles, and Rewards

Guild organises a community around three building blocks, documented in its [How Guild works](https://docs.guild.xyz/guild/how-guild-works) guide. **Requirements** are the conditions a person must meet: on-chain activity (own a `$TOKEN` or NFT, hold a [POAP](https://help.guild.xyz/en/articles/8123193-gitcoin-passport-as-guild-requirement), make N transactions, interact with a given contract), social proof (follow an X account, hold an existing Discord role, verify an email), other-guild activity (a points threshold or another guild's role), or time-based conditions (had a role before a date, transacted in the last seven days). Requirements span 20+ blockchains and 30+ apps, and a _"should not satisfy"_ rule can [exclude](https://help.guild.xyz/en/articles/6934741-wallets-social-accounts) wallets rather than admit them.

**Roles** bundle a set of requirements together with what meeting them grants; a single guild can layer many roles for tiered access. **Rewards** are what a satisfied role unlocks — the platform automatically grants Discord server roles, Telegram access, GitHub repository permissions, Google Workspace file sharing, POAPs, and token rewards, per the [rewards](https://docs.guild.xyz/guild/how-to-setup-rewards) documentation. Access is re-evaluated against live wallet state, so a role is revoked automatically when its holder no longer meets the requirement.

## What it gates, and where

Guild's value is that it turns an on-chain fact into an off-chain permission without any custom code. A community defines "hold 1 of this NFT" once, and Guild keeps a Discord role, a Telegram invite, and a private GitHub repo in sync with that condition across every member. Its homepage claims 100+ integrations and communities scaling from a hundred to hundreds of thousands of members, with reference deployments in the 160,000–483,000-member range. Because the gate is a requirement check rather than a smart-contract lock, the same guild can mix on-chain holdings with off-chain proofs — a token _and_ an X follow _and_ an allowlist entry — which is why it became the default access layer for [social DAOs](/wiki/daos/social/friends-with-benefits) and creator communities that gate a human space rather than a treasury.

## Sybil resistance and proof-of-personhood

A token gate has an obvious weakness: one person with enough capital can meet a holdings requirement from many wallets, or borrow tokens just long enough to pass the check. Guild addresses this at the access layer with native wallet-activity requirements and, since a 2023 partnership, an integration with [Human Passport](/wiki/dao-governance/tooling/membership/human-passport) (then Gitcoin Passport — [partnership announcement](https://guild.xyz/humanpassport)) — a guild can require a minimum _Unique Humanity Score_ so that roles are gated on a proof-of-personhood signal rather than on holdings alone. This makes Guild one of the practical building blocks discussed on [sybil resistance in DAOs](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos): it can filter who gets a voice in a forum or an allowlist, even though it does not itself weight anyone's on-chain vote.

## Origin and adoption

Guild is built by the [Agora Space](https://agora.space/) team — formerly ZGEN, founded in 2020 and based in Szeged, Hungary — positioning itself early as "the authorization layer for Web3." The project is freemium, free to start with paid tiers for scale, and grew into the widely-used token-gating standard for Discord and Telegram, trusted (per its own site) by 1,000+ teams. It sits in the access-and-identity slot of the broader [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), alongside contribution tools like [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) and voting layers like [Snapshot](/wiki/dao-governance/tooling/voting/snapshot): Guild decides who is in the community, and the governance tools decide what the community does.

## How Caper approaches this

Guild is the best answer to one specific question — _gate this space by what a wallet holds right now_. But a token gate is a snapshot: hold the token today and you are in; sell it, or return the tokens you borrowed for the check, and the role is revoked. It governs _access_, and access is exactly the thing a well-funded buyer can rent. A [caper](/wiki/foundations/what-is-a-caper) does not gate access at all — anyone can buy the token and become a member — but it makes the part of governance that actually matters something a wallet cannot buy or rent. Voting weight is `(t·v)/(V·T)`, combining tokens held with `v`, an earned, [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) proof-of-vote record that is minted one-per-vote and cannot be transferred, and the same weighting sets a member's pro-rata share on [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Stake still counts — `t` is a multiplier, not something the earned record replaces — but the decisive, earned factor has no spot price. The two are complementary rather than competing: a caper could happily use Guild to gate a token-holders' Discord. Guild decides who is in the room; a caper decides who has earned the standing to move the treasury, and makes that standing un-buyable.

## References

- Guild, [How Guild works](https://docs.guild.xyz/guild/how-guild-works) (Requirements, Roles, Rewards)
- Guild, [How to set up rewards](https://docs.guild.xyz/guild/how-to-setup-rewards)
- Guild Knowledge Base, [Wallets & social accounts](https://help.guild.xyz/en/articles/6934741-wallets-social-accounts)
- Gitcoin, [Guild.xyz and Gitcoin Passport partner to stop bots and sybil attackers](https://guild.xyz/humanpassport)
- [Agora Space](https://agora.space/) (the team behind Guild); company profile via [CB Insights](https://www.cbinsights.com/company/guildxyz)

## Hats Protocol

URL: https://caper.network/wiki/dao-governance/tooling/membership/hats-protocol
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Category** | Roles & permissions infrastructure (onchain org layer) |
| **What it is** | Programmable roles as ERC-1155 tokens ("hats") arranged in an admin tree |
| **Builder / status** | Originally [Haberdasher Labs](https://github.com/Hats-Protocol); wound down June 2026 — Hats Protocol is now a community-run [public good](https://www.kucoin.com/news/flash/dao-app-hats-protocol-to-shut-down-parent-company-and-transition-to-public-good) (open source, contracts unchanged) |
| **Composes with** | [Safe](/wiki/dao-governance/tooling/treasury/safe), [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Tally](/wiki/dao-governance/tooling/voting/tally) |
| **Adoption** | Self-reported "trusted by over 50 top DAOs" |
| **Related** | [DAO tooling overview](/wiki/dao-governance/tooling/dao-tooling-overview), [Execution](/wiki/governance/execution) |

**Hats Protocol** is onchain infrastructure for **roles and permissions** — the layer that answers _who in a DAO is allowed to do what_. Most governance tooling decides _what_ an organization does ([Snapshot](/wiki/dao-governance/tooling/voting/snapshot) for signalling, [Tally](/wiki/dao-governance/tooling/voting/tally) for onchain proposals, [Safe](/wiki/dao-governance/tooling/treasury/safe) for custody); Hats sits underneath them and encodes _who_, turning a job description into a token a smart contract can read. It describes itself as [“roles & permissions for the open internet”](https://www.hatsprotocol.xyz/) and was built as open-source infrastructure by [Haberdasher Labs](https://github.com/Hats-Protocol). In June 2026 Haberdasher Labs [announced it was winding down](https://www.kucoin.com/news/flash/dao-app-hats-protocol-to-shut-down-parent-company-and-transition-to-public-good) and transitioning Hats Protocol into a community-run public good — the onchain contracts are unchanged and the full stack is now open source.

## Hats are role tokens

A **hat** is a role represented as an [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155) token, per the [protocol documentation](https://docs.hatsprotocol.xyz/). When an address holds a balance of one of a given hat, it is a **wearer** of that hat and carries whatever responsibilities and permissions the hat bundles. A single hat can have many wearers up to a `maxSupply`, and — crucially — **hats are not transferable**: a wearer can voluntarily _renounce_ a hat, but cannot sell or send it to someone else. A role is granted by the organization, not traded on a market. Each hat carries a fixed set of [properties](https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/hat-properties) — `details` (name/description metadata), `maxSupply`, an `admin`, an `eligibility` module, a `toggle` module, a `mutable` flag, and an `imageURI`.

## The Hats tree and admin hierarchy

Hats are linked into a **Hats tree** — a hierarchy that mirrors an org chart. At the apex sits the **Top Hat**, held by whoever holds ultimate authority over the tree: an individual, a multisig, or a whole DAO. Every other hat has an **admin** — a parent hat whose wearers can create child hats, mint them to new wearers, change a mutable hat's properties, and revoke hats that are misused or no longer needed. Because admin authority flows down the tree, a DAO can delegate a branch of responsibility to a working group without handing over control of everything else, and can always reach back down the branch to reclaim it. This is the mechanism Hats calls an **accountability relationship**: authority is delegated but revocable, so a contributor's power lasts exactly as long as the org wants it to.

## Eligibility and toggle modules

Two pluggable modules make a hat _programmable_ rather than merely administered, per the [hat-properties reference](https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/hat-properties):

- **Eligibility modules** decide, per wearer, whether an address is _eligible_ to wear the hat and remains in **good standing**. An eligibility module can be another contract — a token balance check, a staking requirement, a [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote, an offchain attestation — so a role can be granted or automatically stripped by rule, not by a manual transaction.
- **Toggle modules** decide whether the _hat itself_ is active or inactive, affecting every wearer at once regardless of individual standing — useful for time-bounded roles or roles that switch off when a condition lapses.

Whether these can change after creation depends on the `mutable` flag: an **immutable** hat locks its properties permanently, while a **mutable** hat lets its admin adjust them later — the same immutability-versus-adaptability trade-off that runs through DAO design, from [Liquity's](/wiki/daos/stablecoins/liquity) frozen contracts to [governed](/wiki/daos/stablecoins/aave-gho) parameters.

## How it composes with the rest of the stack

Hats is deliberately a _layer_, not an app — its value is that other tools read hats to gate their own actions. The landing page names integrations with [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (gating who can create or pass certain votes), [Tally](/wiki/dao-governance/tooling/voting/tally) (proposals), Decent (workspaces), and Unlock (identity), and the protocol is commonly paired with [Safe](/wiki/dao-governance/tooling/treasury/safe) multisigs and [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) modules so that _wearing a hat_ becomes the permission to sign a transaction or trigger a module. The project reports Hats is [“trusted by over 50 top DAOs”](https://www.hatsprotocol.xyz/); as with all self-reported adoption figures, treat the exact count as directional. Its natural place in a treasury stack is alongside execution tooling like [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac): Zodiac decides _how_ a decision reaches a Safe, Hats decides _who_ is authorized to be part of it.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no role layer to install, because it needs almost no privileged roles in the first place. Membership is flat: influence is not a hat an admin grants but a record you earn — each vote mints a _soulbound, non-transferable_ vote token, and your weight is `w = (t · v) / (V · T)`, the product of what you hold and the participation you have accumulated (see [Voting](/wiki/governance/voting)). No wearer sits between a member and the treasury: once a proposal passes, [execution is permissionless](/wiki/governance/execution) — anyone can submit the transaction that carries out the winning option — and the one credential that _is_ privileged, the treasury admin badge, never leaves the contract's own vault; it is presented as a proof inside a single atomic call and returned before the transaction ends. Where Hats gives a large organization a revocable tree of delegated authority, a caper aims to need less delegated authority at all: fewer roles to grant, fewer to revoke, and no standing key for anyone to lose or abuse.

## Human Passport (formerly Gitcoin Passport)

URL: https://caper.network/wiki/dao-governance/tooling/membership/human-passport
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Tool** | [Human Passport](https://passport.human.tech/) (passport.human.tech) — proof-of-personhood scoring and Sybil-defence layer |
| **Formerly** | Gitcoin Passport → Passport XYZ → Human Passport |
| **Owner** | Holonym Foundation (acquired December 2024); one of three [human.tech](https://human.tech/) products alongside Human Network and Human Wallet |
| **Core primitive** | **Stamps** (verifiable credentials) → a single **Unique Humanity Score** |
| **Default threshold** | **20** — `GITCOIN_PASSPORT_THRESHOLD = "20"` in the [deployed scorer config](https://raw.githubusercontent.com/passportxyz/passport-scorer/main/api/scorer/settings/gitcoin_passport_weights.py) |
| **Stamp catalogue** | 51 weighted stamps, from 0.202 to 16.246 points, ~180 points in total (same config file) |
| **Expiry** | 90 days, offchain and onchain stamps alike |
| **Deduplication** | LIFO on the stamp `hash` — a credential already claimed elsewhere scores zero |
| **Products** | Stamps API · Passport Embed (React) · Passport Models (ML address classification, −1 to 100) · ZK individual verifications |
| **Source** | [passportxyz/passport](https://github.com/passportxyz/passport) (AGPL-3.0) · [passportxyz/passport-scorer](https://github.com/passportxyz/passport-scorer) |
| **Best known for** | Gating matching eligibility in [Gitcoin's quadratic-funding rounds](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) |
| **Related** | [Sybil resistance in DAOs](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) · [Guild.xyz](/wiki/dao-governance/tooling/membership/guild-xyz) · [Collab.Land](/wiki/dao-governance/tooling/membership/collab-land) |

**Human Passport** ([passport.human.tech](https://passport.human.tech/)) is the most widely deployed proof-of-personhood layer in DAO funding. It aggregates a scattered pile of credentials — an exchange KYC attestation, a government-ID proof, a biometric check, a Discord account, an ENS name, a record of on-chain activity — into one number, the _Unique Humanity Score_, which any application can gate on. It was built inside Gitcoin as **Gitcoin Passport** to stop Sybil attackers farming its quadratic-funding matching pool, spun out as Passport XYZ, and [acquired by the Holonym Foundation in December 2024](https://human.tech/blog/human-passport-proof-of-personhood-and-sybil-resistance-for-web3) and rebranded under the human.tech umbrella.

It is the tooling answer to the problem set out in [Sybil resistance in DAOs](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos): not _who is this person_, but _how confident are we that this wallet is a distinct human, and what is that confidence worth_. Where [Collab.Land](/wiki/dao-governance/tooling/membership/collab-land) and [Guild.xyz](/wiki/dao-governance/tooling/membership/guild-xyz) answer “does this wallet hold the right token,” Passport answers the harder question of whether ten wallets holding it are ten people.

## Stamps, the score, and the threshold

A **Stamp** is a verifiable credential issued by Passport's IAM service after the user proves control of some account or attestation. The catalogue spans five families: KYC, biometrics, web3 activity, web-of-trust, and web2 activity. Each stamp carries a weight, and the [scorer](https://docs.passport.human.tech/building-with-passport/major-concepts/scoring-thresholds) “adds up the weights of each Stamp owned by each user and compares the result to a pre-defined threshold value.”

The default threshold is **20**. The documentation is explicit that this is a tuned default rather than a law of nature, and publishes the trade-off it encodes:

|  |  |  |
| --- | --- | --- |
| **Score** | **Sybil elimination** | **False-positive risk** |
| 20 | Effective | Low |
| 25 | More effective | Medium |
| 30 | Most effective | High |

Integrators are not stuck with it: a custom scorer can move the threshold, upweight or downweight individual stamps, or require a specific stamp as a prerequisite regardless of score. A DAO gating a treasury vote and a grants round gating a $5 donation are entitled to different answers, and the config supports that.

## Where the weight actually sits

The weights are not a black box — they are a public Python dict in the deployed scorer, [`gitcoin_passport_weights.py`](https://raw.githubusercontent.com/passportxyz/passport-scorer/main/api/scorer/settings/gitcoin_passport_weights.py), alongside the threshold constant itself. As currently deployed it lists **51 stamps** summing to about **180 points**, and the distribution is extremely top-heavy:

|  |  |
| --- | --- |
| **Heaviest stamps** | `NFTScore#50` 16.246 · `CoinbaseDualVerification` 16.042 · `HolonymGovIdProvider` 16.026 · `BinanceBABT` 16.021 · `ETHScore#50` 16.021 |
| **Lightest stamps** | `Brightid` 0.202 · `ETHDaysActive#50` 0.207 · `Ens` 0.208 · `GnosisSafe` 0.222 · `SnapshotProposalsProvider` 0.239 |

Set that against a threshold of 20 and the practical shape of the system is clear. A single Binance or Coinbase attestation carries roughly **80% of the bar** on its own. The entire decentralised-identity tail that aggregate personhood was meant to lean on — BrightID, ENS, a Gnosis Safe, a history of Snapshot proposals — sums to about one point between them. Having actually participated in on-chain governance is worth around **1%** of the score that certifies you as a human.

This is a defensible engineering choice rather than a scandal: exchange KYC is the strongest and most expensive-to-forge signal available at scale, and the government-ID and biometric routes exist precisely so that people who will not use an exchange have a path. But a DAO adopting the default threshold should be clear about what it is adopting. Aggregate proof-of-personhood, in production, mostly resolves to _did a centralised exchange verify you_ — and that is a different trust assumption from the one the phrase “decentralised identity” suggests. The file is live config and changes; check the current values before quoting them.

## Expiry and deduplication

Two rules do more work than the score itself.

**Deduplication is LIFO.** Every stamp carries a `hash`, and when two Passports present the same credential [“the _duplicate_ Stamp is ignored and not counted towards the score”](https://docs.passport.human.tech/building-with-passport/major-concepts/deduplicating-stamps) — the first claim keeps it. This, not the threshold, is the actual Sybil defence. Nothing stops one human from creating ten Passports; what stops them is that ten Passports cannot all point at one Coinbase account. Because the heaviest stamps are exactly the scarce ones, every additional wallet has to clear 20 points out of the cheap tail, and the cheap tail does not add up.

**Credentials decay.** Offchain and onchain stamps alike [expire after 90 days](https://docs.passport.human.tech/building-with-passport/stamps/major-concepts/expirations), extendable by re-verifying in the app; onchain scores carry no explicit expiry, so the docs advise treating the attestation timestamp under the same 90-day rule. For a one-shot funding round that is irrelevant. For a standing membership roster it is a maintenance obligation — a member verified today is unverified next quarter, and a gate that silently drops people is a governance problem, not just an ops one.

## How DAOs actually use it

- **Quadratic-funding rounds.** This is the origin and still the flagship use. [Gitcoin Grants 18](https://www.gitcoin.co/blog/announcing-gitcoin-grants-18) required a score of 20 or above for a donation to be eligible for matching; [Grants 19](https://www.gitcoin.co/blog/announcing-gitcoin-grants-19) softened the cliff into a ramp — “a minimum score of 15 to be eligible for matching” with “matching power… proportionally increase[d] for scores between 15 and 25.” That ramp is the honest response to false positives: a mis-scored human loses matching weight rather than their vote. See [quadratic voting and funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) for why QF collapses entirely without a personhood layer, and [Gitcoin DAO](/wiki/daos/public-goods/gitcoin-dao) for the organisation running the rounds.
- **Role gating.** [Guild.xyz](/wiki/dao-governance/tooling/membership/guild-xyz) can require a minimum Unique Humanity Score as a role requirement ([partnership since 2023](https://guild.xyz/humanpassport)), so access is gated on a personhood signal rather than on holdings alone.
- **Airdrop filtering.** Distribution teams use it to thin out farmed claimant sets — see [airdrops and token distribution](/wiki/economics/airdrops-and-token-distribution).
- **Addresses with no Passport.** The [Models API](https://docs.passport.human.tech/building-with-passport/models/) classifies any EVM address from its transaction history alone, returning −1 (insufficient data) or 0–100, across eight models covering an aggregate score plus Ethereum L1, NFT activity, Arbitrum, Base, Optimism, Polygon, and zkSync. This is the retroactive tool: you can score a claimant set that never opted in.
- **In-app verification.** Passport Embed is a React component that puts the stamp-collection flow inside the integrator's own dApp instead of bouncing users to a second site.

The stack is open source under AGPL-3.0 — [the monorepo](https://github.com/passportxyz/passport) carries the app, the `iam` credential-issuance server, a Ceramic-backed database client, and the infra config, with onchain attestations published across roughly a dozen networks.

## From Gitcoin to Holonym

Passport was built inside Gitcoin, spun out as Passport XYZ, and [acquired by the Holonym Foundation in December 2024](https://human.tech/blog/human-passport-proof-of-personhood-and-sybil-resistance-for-web3), which rebranded it Human Passport and folded it in beside Human Network and Human Wallet. The project's own figures — self-reported, not independently audited — put it at over 2 million users, 150+ campaigns, 120+ integrating projects as of March 2026, nine consecutive Gitcoin Grants rounds defended, and more than $512M in capital flow protected.

The handover is worth noting on its own terms. The Sybil defence that decides who is eligible for a DAO's matching pool is now maintained by a different organisation than the DAO running the pool, on a weights file that organisation controls. That is an ordinary vendor relationship, and it is also a governance dependency: a round's eligibility rules can change without the round's voters approving anything. Anyone treating a Passport threshold as a constitutional parameter should pin the scorer they mean, the way [any other external dependency](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) gets pinned.

## The limits

- **A score is a property of a wallet, not a person.** Deduplication is the only thing binding the two, so the defence is exactly as strong as the scarcity of the heaviest stamps — and no stronger.
- **The cheap route in is a centralised exchange.** That excludes people who cannot or will not KYC, which is the privacy-and-inclusivity half of the tension named on the [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) page. Personhood systems buy security by charging someone; the question is always who pays.
- **Trust moves off-chain, it does not disappear.** A Passport is a claim about attestations from Coinbase, Binance, Civic, Holonym, Idena, and Discord. The DAO is not verifying humans; it is verifying that someone else did, and inheriting their failure modes.
- **It says nothing about vote weight.** Passport decides who may participate. Whether one verified human then counts for one vote or ten thousand is entirely a question for [the voting layer](/wiki/dao-governance/concepts/voting/token-weighted-voting) — which is why personhood tooling sits in the access tier of the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), not the governance tier.

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) runs no identity check at all, and makes no claim that any member is human. It attacks the same problem from the cost side instead. A member's vote weight is `w = (t × v) / (V × T)` — governance tokens held, multiplied by that account's own soulbound vote tokens, over the vote-token supply and circulating supply (`compute_vote_weight`, `contracts/logic/src/lib.rs`). Vote tokens are minted one per accepted ballot, straight into the voter's account by the immortal state component, and the resource's depositor role admits no other frame — so a voting record cannot be bought, sold, or transferred between wallets. Each ballot costs that caper's vote fee (100 XRD by genesis default), paid into the caper's own treasury.

The multiplicative form is what does the Sybil work. Splitting one holding across ten wallets multiplies nothing: each wallet then holds a tenth of the tokens, and to reproduce the original weight every one of them would have to pay the vote fee on every proposal to build its own record — ten times the cost for, at best, the same weight, while each extra mint inflates `V`, the denominator every member shares. Extra identities are strictly a worse deal than one.

It is a narrower promise than proof of personhood: Caper cannot tell you a member is a distinct human, only that concentrated influence had to be paid for and shown up for. But it is a promise the contract keeps by itself, with no external issuer, no expiring credential, and no weights file that a third party can re-tune. See [proposals](/wiki/governance/proposals) for the voting mechanics.

## References

- Human Passport, [documentation](https://docs.passport.human.tech/) — product overview, Stamps, Embed, Models, Data Services.
- Human Passport, [Scoring thresholds](https://docs.passport.human.tech/building-with-passport/major-concepts/scoring-thresholds) — the threshold-20 default and the sybil-elimination / false-positive trade-off table.
- Human Passport, [Deduplicating Stamps](https://docs.passport.human.tech/building-with-passport/major-concepts/deduplicating-stamps) — the LIFO rule and the `hash` field.
- Human Passport, [Stamp and score expirations](https://docs.passport.human.tech/building-with-passport/stamps/major-concepts/expirations) — the 90-day window.
- passportxyz/passport-scorer, [`gitcoin_passport_weights.py`](https://raw.githubusercontent.com/passportxyz/passport-scorer/main/api/scorer/settings/gitcoin_passport_weights.py) — the deployed stamp weights and `GITCOIN_PASSPORT_THRESHOLD`.
- passportxyz/passport, [monorepo](https://github.com/passportxyz/passport) (AGPL-3.0) — app, IAM credential issuance, Ceramic database client, infra.
- human.tech, [Human Passport: proof of personhood and Sybil resistance for Web3](https://human.tech/blog/human-passport-proof-of-personhood-and-sybil-resistance-for-web3) — the Holonym acquisition and the project's self-reported adoption figures.
- Gitcoin, [Announcing Gitcoin Grants 18](https://www.gitcoin.co/blog/announcing-gitcoin-grants-18) and [Announcing Gitcoin Grants 19](https://www.gitcoin.co/blog/announcing-gitcoin-grants-19) — the 20-point matching gate and its replacement by a 15–25 sliding scale.

## Coordinape

URL: https://caper.network/wiki/dao-governance/tooling/treasury/coordinape
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Category** | Contributor compensation · peer allocation |
| **Operated** | 2021–2025 (app sunset 2025; [CoDAO](https://about.coordinape.com/codao) stewards the IP) |
| **Core mechanic** | Per-epoch **GIVE** allocation inside “circles” — contributors reward each other; your reward share = GIVE received ÷ total GIVE |
| **Token** | $CO — governance handed from the founding team to CoDAO holders |
| **Status** | App closed; contracts open-source; GIVE attestations moved on-chain (EAS on Base, 2025) |
| **Site** | [coordinape.com](https://coordinape.com/) · [docs](https://docs.coordinape.com/) |
| **Related** | [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Safe](/wiki/dao-governance/tooling/treasury/safe) |

**Coordinape** was the canonical tool for **peer-allocated compensation** in [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) — a way to decide who gets paid without a manager, a committee, or a token vote. Instead of one authority setting salaries, the contributors themselves signalled who created value, and rewards flowed accordingly. It ran for four years (2021–2025) and shaped how a generation of DAOs handled contributor pay before its app [wound down in 2025](https://coordinape.com/). ([Coordinape docs](https://docs.coordinape.com/))

## How circles and GIVE worked

A team formed a **circle** — the set of contributors to be rewarded for a period. Each **epoch** (say, a month), every member received a budget of **GIVE** tokens and allocated them to the peers whose work they valued, optionally with a note. GIVE could not be kept for yourself, so the mechanic surfaced a collective, bottom-up judgement of contribution. When the epoch closed, each member’s share of a real reward pool (USDC, a governance token, whatever the DAO funded) was simply their _GIVE received divided by total GIVE allocated_. It replaced the fraught task of a core team guessing everyone’s worth with a distributed signal from the people actually doing the work. ([Coordinape docs](https://docs.coordinape.com/))

## Why it mattered

Compensation is one of the hardest problems in a DAO: contributions are fluid, contributors are pseudonymous, and there is no HR department. Coordinape’s insight was that the people _inside_ a circle have far better information about who contributed than any central allocator, and that a low-stakes per-epoch signal captures it cheaply. It made contributor pay legible and participatory, and the pattern — peer signal in, proportional reward out — influenced how many DAOs still think about rewarding work. It is the **contributor-comp** layer in the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview).

## Wind-down and CoDAO

In 2024 the founding team executed what it called “one of the more honest governance transitions in web3”: it transferred control to **[CoDAO](https://about.coordinape.com/codao)** — the community of $CO token holders — and stepped back fully rather than gradually. The hosted app then closed in 2025. Its work persists as on-chain record: the [protocol contracts](https://github.com/coordinape/coordinape-protocol) are open-source, and the GIVE allocations were migrated to on-chain **attestations** (via [EAS](https://attest.org/) on Base) so the history of who-rewarded-whom cannot be erased. CoDAO continues as steward of the intellectual property. ([CoDAO](https://about.coordinape.com/codao))

## How Caper approaches this

Coordinape sat _beside_ a DAO’s governance — a separate app that decided who to pay, whose output a treasury still had to honour. Caper routes contributor payouts through the same binding path as any other treasury action: a [payout proposal](/wiki/governance/proposals) is [voted](/wiki/governance/voting) and [executed](/wiki/governance/execution) on-chain directly against the caper’s vault, with no separate allocation tool and no off-chain step to later ratify. The trade-off mirrors the one Coordinape made deliberately: Caper gains a single auditable path from decision to payment, but does not (today) replicate Coordinape’s fine-grained peer-signal for _dividing_ a reward among many contributors — a caper decides payouts by vote, not by circle.

## References

- Coordinape, [coordinape.com](https://coordinape.com/) and [documentation](https://docs.coordinape.com/).
- Coordinape, [CoDAO](https://about.coordinape.com/codao) (governance and IP steward).
- Coordinape, [coordinape-protocol](https://github.com/coordinape/coordinape-protocol) (open-source contracts).

## Den (multisig operations)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/den
Updated: 2026-08-05

|  |  |
| --- | --- |
| **Category** | Treasury · multisig operations |
| **What it does** | An operations layer on top of an existing [Safe](/wiki/dao-governance/tooling/treasury/safe) — notifications, decoded transactions, simulation and payment requests to get signatures collected |
| **Smart contracts** | **None.** "Built on the Safe Contracts with no additional smart contract code" ([Den docs](https://docs.onchainden.com/overview/safe-contracts)) |
| **Networks** | 13 EVM chains where Safe's official deployments run — Ethereum, Polygon, Optimism, Arbitrum, Base, Gnosis Chain, Avalanche, BNB Chain, Berachain, Zora, Corn, Blast, World Chain ([docs](https://docs.onchainden.com/overview/supported-chains)) |
| **Notable** | Votes in [SafeDAO](/wiki/daos/infrastructure/safe-dao) governance as a delegate under `jgov.onchainden.eth` and `igov.onchainden.eth` |
| **Site** | [onchainden.com](https://onchainden.com/) · [docs](https://docs.onchainden.com) |
| **Related** | [Safe](/wiki/dao-governance/tooling/treasury/safe), [Squads](/wiki/dao-governance/tooling/treasury/squads), [Request Finance](/wiki/dao-governance/tooling/treasury/request-finance), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [The DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**Den** is an operations layer for organisations whose money sits in a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig. It does not custody assets and it does not deploy contracts: signing in fetches the Safes an address already owns, and Den's own documentation is explicit that it is [built on the Safe Contracts with no additional smart contract code](https://docs.onchainden.com/overview/safe-contracts). What it adds is everything that happens _between_ a transaction being proposed and the threshold being met — the part of [treasury operations](/wiki/dao-governance/concepts/treasury/dao-treasury-management) that is a human coordination problem rather than a cryptographic one.

## The bottleneck is inaction, not theft

A Safe is designed so that no minority can move funds. The corollary, which gets far less attention, is that no minority can move funds _even when they should_. Den's own framing of the problem it solves names coordination first: teams "[spend days getting everyone to sign multisig transactions](https://docs.onchainden.com/overview/den)", with hardware wallets in the wrong city and signers who simply forget. A 4-of-7 treasury that cannot assemble four signatures inside a week is, operationally, a treasury that cannot act — and unlike a capture attack, nothing about that failure is visible on-chain. It shows up as proposals that passed and payments that never went out.

This is a distinct failure mode from the ones catalogued under [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail): the governance layer works, the vote carries, and execution stalls at the last mile because the executing body is a group of individuals with day jobs. Tools in this category treat signature collection itself as the product.

## Coordination as the product

Den's answer is deliberately unglamorous. Discord, Telegram, Slack and SMS bots fire when a transaction is created, executed or rejected, and then keep firing: [reminder notifications repeat at a configured frequency](https://docs.onchainden.com/notifications/overview) until a pending transaction is executed. The bots tag the signers who have _not_ yet signed, and generate [statistics on who the least active signers are](https://docs.onchainden.com/overview/den).

That last feature is quietly a governance instrument rather than a convenience. Per-signer responsiveness is exactly the kind of metric a DAO otherwise has no record of: a signer set is usually appointed by a vote and then never measured again, and a member who has stopped signing is functionally a reduction in the effective threshold that nobody has ratified. Making non-signing legible is the same accountability move that [delegate scorecards](/wiki/dao-governance/tooling/analytics/karma) make for voting, applied to the custody layer — and it bears on the [participation-rate arithmetic](/wiki/dao-governance/concepts/analysis/delegate-incentive-programs) DAOs now use to price governance work.

## Reading what you sign

The second problem Den names is comprehension: complex calldata, [numbers divided by 1018](https://docs.onchainden.com/overview/den), and no context for what a payload actually does. Den decodes transaction data, lets owners attach plain-language descriptions, supports [simulation at creation time](https://docs.onchainden.com/creating-transactions/simulations) and again [before execution](https://docs.onchainden.com/signing-and-executing/simulation), and offers a [custom transaction builder](https://docs.onchainden.com/creating-transactions/custom-transaction-builder) plus JSON upload so that teams stop maintaining bespoke scripts to construct treasury calls.

There is a structural point worth stating plainly here, and Den's own [security page](https://docs.onchainden.com/overview/security-practices) is the source for it. Because Den adds no contracts, it "is not able to modify the Safe Contracts or any transactions that a user has signed or executed" — the custody guarantee is untouched. But the descriptions and address labels that signers _read_ are off-chain data held on Den's servers, visible to Safe owners who prove ownership with an [EIP-4361](https://eips.ethereum.org/EIPS/eip-4361) signature. So the human-readable account of what a transaction does is a mutable, off-chain artifact sitting beside an immutable on-chain payload. That is not a flaw in the design — it is where the design draws its trust boundary, and it is the reason decoding and simulation matter more than the description field: those are derived from the payload itself.

## Gas paid from the Safe

Den defaults new transactions to having the Safe reimburse whoever executes them. This is not a Den invention: gas refunds are [native functionality of the Safe contracts](https://docs.onchainden.com/pay-gas-from-safe/how-it-works), exposed in `Safe.sol`'s execution parameters. Den's contribution is turning it on by default and routing execution through a relayer, so a signer holding no native token on the chain in question is no longer a blocker.

The safety property is the part worth noting: the [maximum refund is included in the signature itself](https://docs.onchainden.com/pay-gas-from-safe/faq) and enforced by the Safe contract, so the ceiling on what a treasury can pay out for gas is fixed at signing time rather than trusted to the executor. A DAO that reimburses signers manually instead pays for a second transaction each time — and, more importantly, pays it through a discretionary process with no such ceiling.

## Organisations, bookkeeping and the vendor question

Above the single-Safe view, Den groups related Safes into an organisation, lets non-signers hold read-and-annotate permissions on the off-chain data, and exports categorised bookkeeping to conventional accounting software. Den documents this as [an upcoming premium tier in limited early access](https://docs.onchainden.com/organizations/overview), which is a useful reminder that most of the DAO tooling stack is commercial software with a roadmap, not a protocol.

Den also occupies a position the wiki covers under [DAO service providers](/wiki/dao-governance/concepts/analysis/dao-service-providers): it votes in [SafeDAO](/wiki/daos/infrastructure/safe-dao) as a delegate, publishing two delegate addresses, `jgov.onchainden.eth` and `igov.onchainden.eth`, and inviting `$SAFE` holders to [delegate to them on Snapshot](https://snapshot.org/#/delegate/safe.eth). SafeDAO is a substantial governance body — [17,717 followers and 55 proposals](https://snapshot.org/#/safe.eth) on its Snapshot space as of August 2026. A vendor whose product depends on a set of contracts holding delegated voting power in the DAO that stewards those contracts is a genuine alignment _and_ a genuine conflict, of the same shape as the service-provider relationships mapped on that page. Den states the arrangement openly, which is the right disclosure; it does not make the structure disappear.

## Where it sits in the stack

In the layering described on [the DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), Den is not a custody choice — the custody choice is Safe. It is an operations veneer over a custody decision already made, in the same band as [Request Finance](/wiki/dao-governance/tooling/treasury/request-finance) (which turns vendor invoices into batched multisig payments) and distinct from an asset manager like [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey), which decides what the treasury _holds_. On Solana the equivalent role is bundled into [Squads](/wiki/dao-governance/tooling/treasury/squads) rather than sold separately. The category exists at all because Safe deliberately stayed minimal, leaving the workflow above it to third parties.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no signer set, so the coordination bottleneck Den exists to solve has no surface to appear on. A [proposal](/wiki/governance/proposals) that passes is [executed against the treasury by the contract](/wiki/governance/execution) after its execution delay; there is no interval in which a passed decision waits on individuals to sign.

Caper converges with Den on the gas question, from the other direction. Settling a large ballot is genuinely expensive work — the tally is crystallised in chunks across many transactions — and none of it depends on the proposal passing, so charging it to whoever clicks settle taxes one member for a public good. The contract reimburses each settle-path call from the caper's own treasury against a per-call ceiling (`SETTLEMENT_GAS_PER_CALL`) and a per-proposal budget (`SETTLEMENT_GAS_BUDGET`) sized to the proposal fee that proposal already paid in, so a proposal funds its own settlement and cannot draw down the treasury beyond its own contribution; past the budget the caller pays, which degrades the path rather than bricking it (`contracts/logic/src/lib.rs`). Den fixes the refund ceiling in the signature; a caper fixes it in a constant and a per-proposal allowance. Both refuse to leave execution costs on whoever happened to be available.

## References

- Den, [What is Den?](https://docs.onchainden.com/overview/den) and [Safe Contracts](https://docs.onchainden.com/overview/safe-contracts).
- Den, [Security Practices](https://docs.onchainden.com/overview/security-practices) — the off-chain data and EIP-4361 ownership proof.
- Den, [Paying gas from your Safe](https://docs.onchainden.com/pay-gas-from-safe/how-it-works) and its [FAQ](https://docs.onchainden.com/pay-gas-from-safe/faq).
- Den, [Notifications](https://docs.onchainden.com/notifications/overview), [Organizations](https://docs.onchainden.com/organizations/overview) and [Supported Chains](https://docs.onchainden.com/overview/supported-chains).
- Snapshot, [SafeDAO space](https://snapshot.org/#/safe.eth) and [SafeDAO delegation](https://snapshot.org/#/delegate/safe.eth).
- Safe, [safe-contracts](https://github.com/safe-global/safe-contracts) — the audited contracts Den builds on.

## Enzyme (on-chain asset management)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/enzyme
Updated: 2026-07-25

|  |  |
| --- | --- |
| **Tool** | [Enzyme](https://enzyme.finance) (formerly Melon) — non-custodial on-chain asset management |
| **Category** | Treasury asset management — the vault primitive that _works_ a treasury inside coded policies |
| **Trust model** | Non-custodial vaults: the manager can allocate across whitelisted protocols but cannot withdraw depositors' assets |
| **Founded** | Melonport AG, Zug (2016); rebranded to Enzyme [15 Dec 2020](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d) |
| **Token / governance** | `MLN`, governed on-chain by the Enzyme Council (formerly Melon Council) |
| **Track record** | $7B+ transaction volume, $200M+ under technology management, 8+ years, no reported security breach ([enzyme.finance](https://enzyme.finance)) |
| **Related** | [Safe](/wiki/dao-governance/tooling/treasury/safe) · [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) · [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**[Enzyme](https://enzyme.finance)** is an Ethereum-based protocol for decentralized, on-chain asset management: it lets anyone “set up, manage and invest in customized on-chain investment vehicles” ([protocol repo](https://github.com/enzymefinance/protocol)). Where [Safe](/wiki/dao-governance/tooling/treasury/safe) answers _where a treasury's money sits_ and an on-chain governor answers _how a vote moves it_, Enzyme answers _how a treasury is actively worked_ — deployed into DeFi positions, rebalanced, and reported on — without the party doing the work ever holding the assets. It is the same active-management problem [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) solves as a service; Enzyme solves it as a reusable smart-contract primitive. The protocol has processed over $7B in transaction volume and administers $200M+ in assets, across 8+ years with no reported security breach ([enzyme.finance](https://enzyme.finance)).

## The non-custodial vault

The core object is a **vault**. A manager (the vault owner) configures it; depositors deposit an accepted asset and receive **vault shares** that represent a pro-rata claim on the vault's holdings, so their share of any gains or losses tracks their share of the pool. The manager can then trade and allocate the pooled assets across the protocols the vault integrates — **Enzyme Blue** advertises end-to-end strategy management across 30+ DeFi protocols ([enzyme.finance](https://enzyme.finance)) — through standard _integration adapters_ for lending markets, DEXes, staking and derivatives.

The property that matters for a treasury is what the manager _cannot_ do. Assets live in the vault's own contract, and the manager's authority is scoped to moving them _between integrated positions_; there is no function that lets the manager send depositor assets to an arbitrary outside address. That is the whole meaning of “non-custodial” here: the worst a compromised or malicious manager can do is reallocate within the vault's permitted universe, never abscond with the balance ([docs.enzyme.finance](https://docs.enzyme.finance)). It is the same “work it, don't take it” guarantee [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) reaches with a [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles Modifier bolted onto a Safe — here it is baked into the vault contract itself.

## Policies and fees: the manager's leash

A vault's constraints are set at configuration time and enforced on-chain. **Policies** bound the manager's discretion — which assets the vault may hold, which adapters and protocols it may touch, who is allowed to deposit, minimum/maximum deposit sizes and lock-ups. **Fees** are configurable too: management fees on assets under management, performance fees on gains (typically high-water-marked), and entrance/exit fees, all charged programmatically in shares ([docs.enzyme.finance](https://docs.enzyme.finance)). For a DAO, the policy set is the point: a treasury can hand a mandate to a manager and know, by code rather than by trust, exactly which venues and instruments that mandate can and cannot reach.

## From Melon to Enzyme

Enzyme began as **Melon**, built by **Melonport AG** — a company founded in Zug, Switzerland in 2016 by [Mona El Isa](https://enzyme.finance) (a former Goldman Sachs vice-president) and Reto Trinkler, with a single mandate to build “an asset management computer built on Ethereum.” The name came from the Greek _μéλλων_ (“future”). On 15 December 2020 the project announced its rebrand to **Enzyme**, phased in alongside the launch of Enzyme v2; the `MLN` token's ticker and contract address (`0xec67…1892`) were left unchanged, and the rename was driven partly by brand confusion with the bank BNY Mellon ([Enzyme](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d)). The codebase is open source under GPL-3.0 (with a BUSL-1.1 option for affiliated products), with a live Immunefi bug bounty and the current Enzyme Blue v4 developed and tested under Foundry ([protocol repo](https://github.com/enzymefinance/protocol)).

## Governance: MLN and the Enzyme Council

Enzyme is governed on-chain through its native token, `MLN`, and the **Enzyme Council** (the renamed Melon Council) — a delegate body that ratifies protocol changes, adds and vets integration adapters and price feeds, and manages the protocol's parameters. New DeFi integrations are gated through this process precisely because an unvetted adapter would widen every vault's attack surface at once, so the “asset universe” a manager can reach is itself a governed set rather than an open one ([docs.enzyme.finance](https://docs.enzyme.finance)). Governance here is doing operational security work, not just parameter-tuning.

## Who uses it — DAO treasuries

Enzyme vaults are compatible with both externally-owned accounts and multi-sig wallets, so a DAO can hold treasury assets in a vault and delegate active management to a manager (an internal working group or an outside firm) without surrendering custody or opening a withdrawal path out of the treasury ([enzyme.finance](https://enzyme.finance)). This puts it in the same problem space as the [treasury-management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) question every large DAO faces: a nine-figure balance sitting idle in stablecoins is itself a costly decision, and a vault with coded policies is one way to earn on it without hiring a custodian. Enzyme has since generalised into a product family — **Onyx** (vault-as-a-service for tokenized funds), **Blue** (multi-protocol strategy management), and **Myso** (on-chain options) — and extended to institutional infrastructure such as the Canton network ([enzyme.finance](https://enzyme.finance)).

## Where it fits in the stack

On the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), custody ([Safe](/wiki/dao-governance/tooling/treasury/safe)) and execution ([Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), on-chain governors) settle where funds live and how a vote moves them. Enzyme sits at the _allocation_ layer above, alongside [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey): once the treasury is safely held and governable, something still has to decide what the assets do. The two split the same layer differently — karpatkey is a professional manager that operates on your Safe through scoped roles; Enzyme is a self-serve vault contract into which you (or a manager you appoint) run a strategy under on-chain policies. Both keep the _work-it-don't-take-it_ boundary; they differ on whether you hire that discipline or configure it.

## How Caper approaches this

Enzyme and [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) exist because the mainstream DAO treasury is a passive [Safe](/wiki/dao-governance/tooling/treasury/safe), and turning it into a productive one means bolting an allocation layer on top and fencing that layer in with policies or roles. A [caper](/wiki/foundations/what-is-a-caper) removes the seam that layer spans. The treasury is a protocol-controlled vault _inside_ the contract, and capital moves only through a governed on-chain [proposal](/wiki/governance/proposals) that members [vote](/wiki/governance/voting) on and that [executes](/wiki/governance/execution) permissionlessly — an `INVEST` that withdraws treasury XRD and buys another caper's tokens on its bonding curve, or a `PAYOUT` that funds work. Vote weight is `(t·v)/(V·T)`, combining tokens held with the earned, soulbound record of past voting, so a passive whale (`v = 0`) carries no weight; the same weighting sets each member's pro-rata share on [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). The trade-off is deliberate and honest. A caper has no vault owner to appoint and no continuous, discretionary rebalancing between votes — it forgoes exactly the always-on, professionally-managed DeFi yield that is Enzyme's whole reason to exist, in exchange for having no manager role and no custody boundary to trust at all. For a treasury that wants active, expert asset management, Enzyme is a reference primitive; a caper is the answer for one that wants every deployment of its capital to be a governed act of the membership by construction, not a mandate handed to a manager.

## References

- Enzyme, [enzyme.finance](https://enzyme.finance) and [docs.enzyme.finance](https://docs.enzyme.finance).
- Enzyme, [From Melon to Enzyme](https://medium.com/enzymefinance/from-melon-to-enzyme-b5b56512f40d) (15 Dec 2020).
- Enzyme Finance, [protocol repository](https://github.com/enzymefinance/protocol) (GPL-3.0 / BUSL-1.1, Enzyme Blue v4).

## Juicebox

URL: https://caper.network/wiki/dao-governance/tooling/treasury/juicebox
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Category** | On-chain [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · crowdfunding protocol |
| **Launched** | July 2021 on Ethereum; governed by JuiceboxDAO ([$JBX](https://juicebox.money/@juicebox)) |
| **What it does** | Programmable, rules-based fundraising — funding cycles, project tokens, redemption bonding curves and payout splits, all on-chain |
| **Known for** | The fundraising engine behind [ConstitutionDAO](/wiki/dao-governance/concepts/fundamentals/history-of-daos) (~$47M, 2021) and AssangeDAO (~17,400 ETH, 2022) |
| **Current version** | V4 omnichain (Ethereum, Optimism, Arbitrum, Base) + revnets; V5 is the latest |
| **Site** | [juicebox.money](https://juicebox.money/) · [docs](https://docs.juicebox.money/dev/) |
| **Related** | [Rage quit & exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) · [Types of DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos) · [Safe](/wiki/dao-governance/tooling/treasury/safe) |

**Juicebox** is the money layer of the DAO stack. Where [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) and [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally) run a community's votes and [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) measures the field, Juicebox is where a community actually _raises and holds the money_ — a programmable, fully on-chain protocol for community fundraising and [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) management. Launched on Ethereum in July 2021 and governed by JuiceboxDAO, it lets anyone spin up a treasury that issues its own token against contributions, pays out on pre-set rules, and lets backers redeem their tokens back against the funds — the machinery behind the most famous crowdfunding [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) of the last cycle. ([Juicebox docs](https://docs.juicebox.money/dev/))

## How funding cycles work

A Juicebox project runs on **funding cycles** — time-boxed configurations of the treasury's rules. During a cycle the parameters are locked; a project owner can queue changes, but they only take effect in the _next_ cycle, so backers always know the rules can't be rewritten mid-flight. Each cycle sets a **weight** (how many project tokens each contributed ETH mints), a **reserved rate** (a share of newly minted tokens withheld for the team, contributors or other Juicebox projects), and **payout splits** that route outgoing funds to a fixed list of addresses or other treasuries. Contributors pay in, receive the project's token, and the splits distribute the proceeds exactly as configured — no multisig discretion required. ([Juicebox protocol overview](https://docs.juicebox.money/dev/v3/learn/overview))

## Project tokens and the redemption bonding curve

The primitive that made Juicebox interesting to DAOs is **redemption**. A project sets a **redemption rate** that governs a [bonding curve](/wiki/markets/bonding-curve) for cashing project tokens back in: at a 100% rate the curve is linear, so redeeming X% of the token supply returns X% of the redeemable treasury; lower rates bend the curve to favour those who stay. That single dial is a built-in [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — a backer who changes their mind, or whose project fails its goal, can burn their tokens and reclaim a pro-rata slice of the funds. ConstitutionDAO ran a 100% redemption rate precisely so contributors could get their ETH back if the bid lost, which it did.

## ConstitutionDAO, AssangeDAO and the crowdfunding-DAO moment

Juicebox is best known for two raises that defined the 2021–22 crowdfunding-DAO wave. **ConstitutionDAO** used a Juicebox treasury to raise roughly **$47M in ETH from over 17,000 contributors in about a week** in November 2021, aiming to buy a first-printing copy of the US Constitution at Sotheby's; it was outbid at $43.2M by Citadel's Ken Griffin, and its 100%-redemption config let backers reclaim their funds afterward, with the [$PEOPLE token](https://www.coindesk.com/tech/2021/11/19/constitutiondao-outbid-for-first-printing-of-americas-founding-document-in-sothebys-auction) persisting as a memento. Three months later **AssangeDAO** raised an even larger **~17,400 ETH (~$54M)** through Juicebox for Julian Assange's legal defence, [concluding in February 2022](https://cryptopotato.com/assangedao-concludes-fundraise-after-securing-17422-eth-54-million/). Both are canonical [crowdfunding-DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) case studies — proof that a rules-based on-chain treasury could coordinate tens of millions of dollars from strangers in days, with the refund path baked into the contract rather than promised by an organiser. ([Juicebox on ConstitutionDAO](https://docs.juicebox.money/blog/constitutiondao-highlight/))

## Governance, fees and the V4 rewrite

The protocol governs itself: **JuiceboxDAO** is project ID 1 on Juicebox, steered by the **$JBX** token, and it sets a **membership fee** — historically 2.5%, adjustable by governance up to a 5% cap — charged only when funds are paid _out_ of the Juicebox ecosystem; treasury-to-treasury transfers are free. The 2025 **V4** release was an omnichain rewrite: projects can now deploy across Ethereum, Optimism, Arbitrum and Base in any combination, it introduced **revnets** (immutable, ownerless revenue-sharing treasuries), routed protocol fees to a $NANA revnet, and renamed the core concepts (funding cycles became “rulesets,” redemptions became “cash outs”). The current on-chain contracts live under the [Bananapus / nana-core](https://github.com/Bananapus/nana-core) organisation, with V5 shipping as a bug-fix fork of V4. ([Juicebox developer docs](https://docs.juicebox.money/dev/))

## How Caper approaches this

Of all the DAO tooling, Juicebox is the closest cousin to a [caper](/wiki/foundations/what-is-a-caper)'s economic core: both are on-chain treasuries that issue a token against contributions and let holders redeem against the pooled funds along a curve. The difference is **configurable protocol versus fixed protocol**. A Juicebox project owner picks and can reconfigure the weight, reserved rate, redemption rate and splits each cycle — flexibility that suits a bespoke fundraise. A caper instead ships one set of rules every caper shares: a [single bonding curve](/wiki/markets/bonding-curve) that prices both [buys and sells](/wiki/markets/trading), a fixed founder allocation and 0.5% trade fee, and a [pro-rata exit](/wiki/governance/voting) whose share is the member's canonical vote weight `(t·v)/(V·T)` — so exit tracks _participation_, not just token balance, and no operator can retune the terms after people have paid in. Juicebox optimises for a fundraise you shape yourself; Caper optimises for a standing organisation whose economic guarantees are the same for everyone and can't be quietly changed.

## References

- Juicebox, [developer documentation](https://docs.juicebox.money/dev/) and [protocol overview](https://docs.juicebox.money/dev/v3/learn/overview).
- Juicebox, [“ConstitutionDAO” case study](https://docs.juicebox.money/blog/constitutiondao-highlight/) (Juicebox attribution and config).
- CoinDesk, [“ConstitutionDAO Outbid for First Printing of America's Founding Document”](https://www.coindesk.com/tech/2021/11/19/constitutiondao-outbid-for-first-printing-of-americas-founding-document-in-sothebys-auction) (raise, contributors, winning bid).
- CryptoPotato, [“AssangeDAO Concludes Fundraise After Securing 17,422 ETH”](https://cryptopotato.com/assangedao-concludes-fundraise-after-securing-17422-eth-54-million/) (final total).
- Bananapus, [nana-core](https://github.com/Bananapus/nana-core) (Juicebox V4 contracts).

## karpatkey (kpk)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/karpatkey
Updated: 2026-07-25

|  |  |
| --- | --- |
| **Tool** | karpatkey (rebranded [kpk](https://kpk.io/about), 2025) — non-custodial DAO treasury manager |
| **Category** | Active on-chain treasury management — the allocation layer that sits on top of custody |
| **Trust model** | Proxy [Safe](/wiki/dao-governance/tooling/treasury/safe) + [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles Modifier — role-scoped permissions, no custody |
| **Founded** | 2021, inside [GnosisDAO](/wiki/daos/networks/gnosisdao) to manage its treasury |
| **Notable mandates** | [ENS](/wiki/daos/infrastructure/ens-dao), [Balancer](/wiki/daos/dexs/balancer-dao), [CoW](/wiki/daos/dexs/cow-dao), [Aave](/wiki/daos/lending/aave-dao), [Lido](/wiki/daos/staking/lido-dao), Nexus Mutual, Safe |
| **Track record** | 7,000+ DeFi transactions, $2.6B+ managed, no reported losses or hacks (per GnosisDAO spin-off reporting) |
| **Governance** | Spun out of GnosisDAO (GIP-92); KPK token launched May 2025 |
| **Related** | [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [Safe](/wiki/dao-governance/tooling/treasury/safe) · [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) · [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**karpatkey** (rebranded **[kpk](https://kpk.io/about)** in 2025) is a non-custodial, on-chain manager for DAO treasuries. Most DAO tools answer “where does the money sit” (custody) or “how does a vote move it” (execution); karpatkey answers a different question — _what should an idle treasury actually do_. It is the active-management layer that sits on top of a [Safe](/wiki/dao-governance/tooling/treasury/safe): it designs an allocation strategy, deploys treasury assets into vetted DeFi positions, rebalances them, and reports the results, all without ever holding the DAO's keys. It grew up inside [GnosisDAO](/wiki/daos/networks/gnosisdao), which it was founded in 2021 to serve, and became the reference name for “professional treasury management, done on-chain and non-custodially” ([kpk](https://kpk.io/about)).

## The non-custodial model

The whole design turns on one constraint: the manager must be able to _work_ the treasury without being able to _take_ it. karpatkey solves this with a proxy **Management [Safe](/wiki/dao-governance/tooling/treasury/safe)** paired with the **[Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) Roles Modifier** — an open-source module that grants an address a _role_: permission to call only pre-approved functions on pre-approved contracts, with pre-approved parameters. ENS's own mandate describes the setup in exactly those terms — management runs through “a proxy Management Safe and the Zodiac Roles Modifier” ([CoinDesk](https://www.coindesk.com/tech/2022/11/23/ethereum-name-service-selects-karpatkey-dao-as-endaoment-fund-manager)).

In practice the DAO keeps its assets in its own Safe and hands karpatkey a role that can, say, supply to a specific Aave market or add liquidity to a named pool — but _cannot_ transfer funds to an outside address, cannot touch unapproved protocols, and can be revoked by the DAO at any time. The manager's discretion is bounded by code, not by trust. This is what “non-custodial” means here: the worst a compromised manager can do is move money between whitelisted DeFi positions, never out the door. It is the same permission-scoping idea that [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) brings to governance execution, applied to treasury operations.

## Mandates and track record

karpatkey's credibility rests on the size and prominence of the treasuries it has run. Beyond its origin at [GnosisDAO](/wiki/daos/networks/gnosisdao), its best-known mandate is the [ENS](/wiki/daos/infrastructure/ens-dao) _Endaoment_ — the endowment ENS created to fund development independent of registration revenue. In a November 2022 community vote (1.76M votes to 1.3M for “none of the above”), ENS selected karpatkey, working with Steakhouse Financial, to manage an endowment proposed to start near $52M and scale toward $69M, invested through “low-risk, medium-complexity DeFi strategies” over a USDC-and-ETH base ([CoinDesk](https://www.coindesk.com/tech/2022/11/23/ethereum-name-service-selects-karpatkey-dao-as-endaoment-fund-manager)). Its client roster has since grown to include [Balancer](/wiki/daos/dexs/balancer-dao), [CoW Protocol](/wiki/daos/dexs/cow-dao), [Aave](/wiki/daos/lending/aave-dao), [Lido](/wiki/daos/staking/lido-dao), Nexus Mutual and Safe.

By the time GnosisDAO moved to spin it out, karpatkey reported having executed more than 7,000 DeFi transactions and managed over $2.6B in DAO treasuries without a reported loss or hack ([The Block](https://www.theblock.co/post/298551/gnosisdao-karpatkey-spin-off)). Those figures are the sell: an active strategy is only worth running if the operational risk it adds stays smaller than the yield it earns.

## From service to protocol: the kpk spin-off

In 2025 karpatkey stopped being a unit of one DAO and became its own. Under [GIP-92](https://forum.gnosis.io/t/gip-92-should-gnosis-dao-spin-off-karpatkey-dao-and-deploy-the-kpk-token/8115), GnosisDAO voted to spin karpatkey off as an independent entity and deploy a governance token; the rebrand to **kpk** and the launch of the **KPK token** followed on 15 May 2025 ([The Defiant](https://thedefiant.io/news/defi/kpk-launches-kpk-token-and-updated-dao-governance-structure)).

Freed from a single mandate, kpk has generalised its playbook into a product: **curated, non-custodial vaults** that apply the same role-scoped, policy-bounded automation to DeFi protocols and, increasingly, to retail depositors — including agent-powered vaults launched on Morpho in late 2025 ([kpk](https://kpk.io/articles/)). The trajectory is a familiar one in DAO tooling: a bespoke service, proven on a flagship treasury, hardens into reusable infrastructure.

## Where it fits in the stack

On the [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), custody ([Safe](/wiki/dao-governance/tooling/treasury/safe)) and execution ([Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), on-chain governors) answer where funds live and how a vote moves them. karpatkey occupies the layer above: once the treasury is safely held and governable, _someone still has to decide what to do with it_. For a nine-figure endowment sitting in stablecoins, doing nothing is itself a costly decision — the [treasury-management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) problem of turning a static balance into sustainable runway. karpatkey's contribution is to make that active management delegable without making it custodial, so a DAO can hire professional allocation without handing over the keys. The alternative to hiring that discipline is configuring it: [Enzyme](/wiki/dao-governance/tooling/treasury/enzyme) bakes the same non-custodial, policy-bounded allocation into a self-serve vault contract rather than a managed service.

## How Caper approaches this

karpatkey exists because the mainstream DAO treasury is a [Safe](/wiki/dao-governance/tooling/treasury/safe) that most DAOs don't have the mandate or expertise to actively manage, so they delegate that work to an outside manager and bound the delegation with [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) role permissions. A [caper](/wiki/foundations/what-is-a-caper) removes the seam that delegation spans. The treasury is a protocol-controlled vault _inside_ the contract, not an external Safe with a manager attached: assets move only through an on-chain [proposal](/wiki/governance/proposals) that members [vote](/wiki/governance/voting) on and that [executes](/wiki/governance/execution) permissionlessly — a `PAYOUT` to fund something or an `INVEST` to deploy capital — with vote weight `(t·v)/(V·T)` combining tokens held and the earned, soulbound record of past voting. There is no manager address to grant a role to, and no discretionary allocation between votes; the same weighting also sets a member's pro-rata share on [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). The trade-off is deliberate and honest: a caper forgoes the professional, actively-managed yield karpatkey delivers in exchange for having no external manager and no custody boundary to trust — every treasury move is a governed, on-chain act by definition. For a treasury that _wants_ active DeFi management, karpatkey remains the reference; a caper is the answer for one that wants the treasury and the vote that moves it to be the same thing.

## References

- kpk, [About](https://kpk.io/about) and [Articles](https://kpk.io/articles/).
- CoinDesk, [Ethereum Name Service Selects Karpatkey DAO to Manage Its Endowment Fund](https://www.coindesk.com/tech/2022/11/23/ethereum-name-service-selects-karpatkey-dao-as-endaoment-fund-manager) (2022).
- GnosisDAO, [GIP-92: Should Gnosis DAO spin-off karpatkey DAO and deploy the KPK Token?](https://forum.gnosis.io/t/gip-92-should-gnosis-dao-spin-off-karpatkey-dao-and-deploy-the-kpk-token/8115)
- The Block, [GnosisDAO approves Karpatkey's spin-off to become independent entity with KPK token](https://www.theblock.co/post/298551/gnosisdao-karpatkey-spin-off).
- The Defiant, [kpk launches KPK Token and updated DAO governance structure](https://thedefiant.io/news/defi/kpk-launches-kpk-token-and-updated-dao-governance-structure) (2025).
- Gnosis Guild, [Zodiac Roles Modifier](https://github.com/gnosisguild/zodiac-modifier-roles).

## Request Finance (invoicing, payroll & payables)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/request-finance
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Tool** | [Request Finance](https://www.requestfinance.com/) — the commercial app; [Request Network](https://request.network/) is the protocol under it |
| **Category** | Accounts payable & receivable · contributor payroll · expenses · accounting export |
| **Founded** | 2017 — [Y Combinator W17](https://www.ycombinator.com/companies/request-network), Christophe Lassuyt (CFO) and Etienne Tatur (CTO) |
| **Protocol** | Open-source, non-custodial; [MIT-licensed monorepo](https://github.com/RequestNetwork/requestNetwork), request data on Ethereum + IPFS |
| **Networks** | Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism and Tron, plus bank rails (ACH, SEPA, SWIFT, Faster Payments) |
| **Known DAO users** | The Sandbox, [Aave](/wiki/daos/lending/aave-dao), [MakerDAO](/wiki/daos/stablecoins/sky-dao) ([2021 reporting](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/)) |
| **Sits beside** | [Safe](/wiki/dao-governance/tooling/treasury/safe) for custody · [Sablier](/wiki/dao-governance/tooling/treasury/sablier) / [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) for streams |

**Request Finance** is the invoicing and payables layer of a DAO treasury: the place where a contributor's claim on the treasury becomes a document — an invoice, an expense, a payroll run — that somebody approves before any money moves. It sits above the multisig rather than replacing it. Custody stays in the [Safe](/wiki/dao-governance/tooling/treasury/safe); what Request Finance adds is the paperwork, the approval trail, and the export that turns a wall of token transfers into something an accountant can read.

That is a real gap. A DAO can vote a budget on-chain and hold it in a multisig, but [paying the people who do the work](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) still means collecting invoices, checking them, converting some of them to fiat, and reconciling the lot at the end of the quarter. Most DAO tooling addresses the authorization problem. Very little of it addresses the bookkeeping.

## Two things with one name

Request splits into a protocol and a business built on it, and the distinction matters when you are assessing how much of the stack you actually depend on.

[Request Network](https://request.network/) is the protocol: an open-source, non-custodial payment-request standard where, in its own words, funds are never held. Its [TypeScript monorepo](https://github.com/RequestNetwork/requestNetwork) is MIT-licensed, and request data is stored on Ethereum and [IPFS](https://ipfs.tech/) (with a [TheGraph](https://thegraph.com/) indexing path as an alternative), so an invoice is a shared on-chain artifact rather than a row in one vendor's database. The network reaches the major EVM chains — Ethereum, BNB Chain, Base, Polygon, Arbitrum, Optimism — and Tron, and the foundation describes the contracts and SDK as public goods that integrators can keep operating regardless of what happens to the foundation itself.

[Request Finance](https://www.requestfinance.com/) is the product: a business account with corporate cards, accounts payable, accrual accounting, and stablecoin-plus-bank settlement, sold to finance teams. Its [developer documentation](https://docs.request.finance/) describes it as an accounts-payable and receivable API sitting on Request Network, so an integrator can issue invoices and track their status without querying a chain directly. The company reports 1,500+ finance leaders processing over $1B in payments.

## How a DAO actually uses it

The working pattern is unglamorous and it is the point:

- **Contributors invoice the DAO.** Each contributor or vendor issues an invoice denominated in a stablecoin or token, which becomes a request on the protocol rather than a PDF in someone's inbox.
- **An approver clears the queue.** Operations staff review and approve bills, which is where budget discipline actually lands — long after the [proposal](/wiki/dao-governance/concepts/voting/proposal-lifecycle) that authorized the budget in the first place.
- **The multisig pays in a batch.** Approved bills are paid from the connected wallet — [Safe](/wiki/dao-governance/tooling/treasury/safe), MetaMask or Ledger are the [listed integrations](https://www.requestfinance.com/) — so signers approve one transaction covering many invoices instead of signing each transfer by hand.
- **Accounting exports out.** Xero, QuickBooks and SAP integrations carry the result into ordinary books, and bank rails (ACH, Wire, SEPA, SWIFT, SPEI, Faster Payments) cover the contributors who need fiat.

Nothing here changes who controls the money. The signers on the Safe still control it. What changes is that the DAO can answer “what did we pay, to whom, for what, and under which budget” without an archaeologist.

## Adoption

Request Invoicing found its first real market among DAOs and token-treasury companies, precisely because they had money and no back office. By [November 2021](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/), reporting named The Sandbox, [Aave](/wiki/daos/lending/aave-dao), [MakerDAO](/wiki/daos/stablecoins/sky-dao) and Chainstack among its users, with roughly $144M in crypto invoices processed across 900+ corporate clients — The Sandbox's COO put the saving at a 90% reduction in monthly payment time. Support then spanned 40+ digital currencies, 9+ fiat currencies and 10+ chains.

The trajectory since is worth reading honestly. The company's own marketing now leads with enterprise stablecoin payments and CFO tooling — corporate cards, accrual accounting, bank rails — not with DAO payables. That is the same drift seen elsewhere in [DAO tooling](/wiki/dao-governance/tooling/dao-tooling-overview): the crypto-native niche proves the product, and then the addressable market pulls it toward companies with a CFO. A DAO evaluating it today is buying enterprise finance software that happens to settle on-chain, rather than a DAO-first tool.

## Where it sits in the stack

Treasury tooling divides by the question it answers, and Request Finance answers only one of them.

- **Custody** — [Safe](/wiki/dao-governance/tooling/treasury/safe) and [Squads](/wiki/dao-governance/tooling/treasury/squads) hold the assets and decide who can move them.
- **Asset management** — [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) and [Enzyme](/wiki/dao-governance/tooling/treasury/enzyme) decide what the assets do while they sit there.
- **Continuous pay** — [Sablier](/wiki/dao-governance/tooling/treasury/sablier) and [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) stream salaries and vesting by the second, replacing the invoice entirely for recurring roles.
- **Allocation** — [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) decides who deserves what, before anyone bills for it.
- **Payables and books** — Request Finance, for the one-off, the vendor, the contractor and the tax authority.

A mature [treasury operation](/wiki/dao-governance/concepts/treasury/dao-treasury-management) usually runs several of these at once: streams for core contributors, invoices for everyone else, and a multisig underneath all of it.

## Limits

The honest caveats are structural rather than incidental.

- **The record of obligation is off-chain.** The payment settles on-chain, but the approval workflow, the budget, and the audit trail live in a hosted application. If the vendor disappears, the transfers survive and the institutional memory of why they happened may not — though the protocol's public-goods contracts and MIT SDK give an integrator a path to keep operating.
- **Fiat means KYC.** The bank rails that make the product useful come with identity requirements a pseudonymous DAO may not want to meet, which pushes the DAO toward a [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) to sign for them.
- **It does not constrain spending.** Approval workflows are a control only if the signers respect them; nothing in the tool stops a multisig from paying an unapproved address directly. The enforcement, if you want any, has to live in the treasury contract itself.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no invoicing layer, and a caper paying real-world contractors would still need one — the bookkeeping problem does not vanish because the ledger is public. What a caper moves on-chain is the authorization, not the paperwork.

Treasury money leaves a caper only through a payout proposal, and the recipient account, the currency and the amount are frozen into the option members actually voted on. Execution reads that stored recipient rather than accepting one from whoever submits the transaction, so the person who triggers the payment cannot redirect it, and the step is once-only. The transfer is delivered through an account locker, so a recipient's deposit rules cannot strand it, and it emits a transfer event against the treasury's opening and closing balance.

Which is to say the control Request Finance implements as an approval workflow, a caper implements as the shape of the proposal: there is no separate approval stage to bypass, because the vote and the payment instruction are the same object. Everything a finance team would call reconciliation — invoices, expense categories, statutory books — stays outside, where a tool like Request Finance is still the right answer.

## References

- Request Network, [protocol site](https://request.network/) · [protocol documentation](https://docs.request.network/) · [RequestNetwork/requestNetwork (MIT)](https://github.com/RequestNetwork/requestNetwork)
- Request Finance, [product site](https://www.requestfinance.com/) · [AP/AR API documentation](https://docs.request.finance/)
- Y Combinator, [Request Network company profile (W17)](https://www.ycombinator.com/companies/request-network)
- crypto.news, [“The Sandbox, AAVE & major ICOs all use Request Invoicing”](https://crypto.news/sandbox-aave-ico-request-invoicing-crypto-fiat-invoicing-payroll/) (23 Nov 2021)

## Sablier (token streaming)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/sablier
Updated: 2026-07-20

|  |  |
| --- | --- |
| **Tool** | [Sablier](https://sablier.com/) |
| **Category** | Token streaming · onchain vesting · airdrops · payroll |
| **Launched** | December 2019 (Ethereum mainnet); [V2](https://medium.com/sablier/introducing-sablier-v2-b72f1aa7e458) in 2023 |
| **Origin** | Implements [ERC-1620 “Money Streaming”](https://eips.ethereum.org/EIPS/eip-1620) (Paul Razvan Berg, Nov 2018) |
| **Contracts** | Non-upgradeable, permissionless; Ethereum + EVM chains and Solana |
| **Governance token** | None |
| **Status** | [Maintenance mode since 13 Jul 2026](https://x.com/PaulRBerg/article/2076695661303443667); contracts and streams run indefinitely |

**Sablier** ([sablier.com](https://sablier.com/)) is a token-_streaming_ protocol: instead of paying a lump sum, a sender locks ERC-20 tokens in a smart contract that releases them to the recipient continuously, second by second, over a set period. It is widely recognised as the [first token-streaming protocol](https://docs.sablier.com/concepts/what-is-sablier) on Ethereum, and it is the reference primitive for the pattern DAOs reach for constantly — vesting a contributor grant, paying an ongoing salary, or distributing an airdrop that unlocks over time rather than all at once.

## Money streaming: the idea

The concept predates the protocol. In November 2018 Sablier co-founder Paul Razvan Berg published [ERC-1620, “Money Streaming”](https://github.com/ethereum/eips/issues/1620) — a standard for representing continuous payments on-chain, where a locked balance is released to a recipient at a fixed rate per unit of time. Berg and co-founder Gabriel Apostu then built the first implementation, deploying it to Ethereum mainnet in December 2019. Sablier frames this as [“real-time finance”](https://docs.sablier.com/concepts/what-is-sablier): the passage of time itself is the settlement mechanism, so a stream needs no trusted intermediary to meter out the drip — the contract simply makes the vested portion withdrawable as the clock advances.

## Lockup, Flow, and Merkle airdrops

The [V2 architecture](https://medium.com/sablier/introducing-sablier-v2-b72f1aa7e458) splits the protocol into distinct, single-purpose product lines:

- **Lockup** — finite-duration streams for [vesting](https://sablier.com/vesting) and vested airdrops. A stream can carry a _cliff_ (nothing withdrawable until a date, then a jump) and be created _cancelable_ or non-cancelable, letting a DAO choose whether it can claw an unvested balance back.
- **Flow** — open-ended, cancelable streams for recurring payments and grants with no fixed end, closer to a live payroll rail than a vesting schedule.
- **Merkle Airdrops** — on-chain claim campaigns where eligibility is proven against a Merkle root, so an instant or vesting airdrop can be distributed to thousands of wallets without the issuer pre-funding a stream for each one.

Because the contracts are [non-upgradeable and permissionless](https://docs.sablier.com/concepts/what-is-sablier), anyone can create a stream with any ERC-20 on any supported chain, and no admin can alter a stream after the fact.

## Why DAOs use it

Streaming solves a governance problem, not just a payments one. A DAO that votes a contributor a twelve-month grant does not want to hand over the whole sum on day one — that is a trust and alignment risk. Streaming the grant means the recipient earns it as they keep working, and (with a cancelable stream) a governance vote can stop the unvested remainder if the relationship ends. The same logic covers [contributor compensation](/wiki/dao-governance/tooling/treasury/coordinape), team and investor token unlocks, and airdrops designed to reward continued participation rather than an instant flip. By its own reporting Sablier has served [over 297,000 users and 550,000+ streams](https://blog.sablier.com/analyzing-500k-vesting-streams-patterns-and-insights/), moving billions in cumulative volume — it sits alongside [Safe](/wiki/dao-governance/tooling/treasury/safe) and [the rest of the tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) as core treasury infrastructure. The continuous, open-ended counterpart is [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid), which streams money per-second with no escrowed pot — the two are the escrowed-vesting and live-netflow poles of on-chain streaming.

## Maintenance mode and the public-good ending

On 13 July 2026 Sablier Labs announced it was [entering maintenance mode](https://x.com/PaulRBerg/article/2076695661303443667) and halting active development. Berg pointed to a sharp Q1-2026 drop in usage as customers postponed token launches, and to AI-assisted coding making it cheap for competitors to clone the product, concluding there was no venture-scale business in onchain streaming. The move is instructive for anyone relying on DAO tooling: the company stopped, but the protocol did not. The immutable, permissionless contracts keep running with no operator, existing streams and vesting plans are unaffected, the hosted frontend is committed through June 2028 before becoming a community-run public good, and Sablier accelerated its license flip from Business Source License to GPL, immediately open-sourcing the core EVM contracts. Depending on a contract that outlives its company is exactly what “permissionless” is supposed to buy.

## How Caper approaches this

Sablier answers _“pay this out gradually over time.”_ [Caper](/wiki/foundations/what-is-a-caper) answers a different question — _“should the treasury spend at all, and on what?”_ A caper's treasury releases funds only through [proposals](/wiki/governance/proposals) that clear a vote and then execute a discrete `PAYOUT` or `INVEST` action, so every disbursement is a governed, on-the-record decision rather than a continuous drip. The two are complementary: a caper could vote a grant and settle it as a single payout, or a payout could itself fund a Sablier stream for a contributor. Where they differ is emphasis — Caper puts the deliberation and the [funding decision](/wiki/markets/raising-funds) on-chain and auditable; Sablier puts the _schedule_ of an already-agreed payment on-chain. Both share the same underlying bet: money movement is safer when the rails, not a person, enforce the terms.

## References

- Sablier, [“What is Sablier” (docs)](https://docs.sablier.com/concepts/what-is-sablier)
- Ethereum, [ERC-1620: Money Streaming](https://eips.ethereum.org/EIPS/eip-1620) · [original proposal thread](https://github.com/ethereum/eips/issues/1620)
- Paul Razvan Berg, [“Introducing Sablier V2”](https://medium.com/sablier/introducing-sablier-v2-b72f1aa7e458)
- Sablier, [Token Vesting](https://sablier.com/vesting) · [“Analyzing 500K+ Vesting Streams”](https://blog.sablier.com/analyzing-500k-vesting-streams-patterns-and-insights/)
- Paul Razvan Berg, [“Sablier Labs is Entering Maintenance Mode” (13 Jul 2026)](https://x.com/PaulRBerg/article/2076695661303443667)

## Safe (multisig treasury)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/safe
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Category** | Treasury · custody |
| **Origin** | Gnosis Multisig (2017) → Gnosis Safe (2018) → rebranded **Safe** (2022) |
| **What it does** | _m_-of-_n_ smart-contract wallet: funds move only when a threshold of signers approves |
| **Scale** | The default DAO treasury; secures assets across 30+ EVM networks |
| **Extensible via** | Modules & guards — e.g. [Zodiac / SafeSnap](/wiki/dao-governance/tooling/frameworks/zodiac) for governance execution |
| **Site** | [safe.global](https://safe.global/) · [docs](https://docs.safe.global/) |
| **Related** | [SafeDAO](/wiki/daos/infrastructure/safe-dao), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [Juicebox](/wiki/dao-governance/tooling/treasury/juicebox) |

**Safe** (formerly Gnosis Safe) is the smart-contract wallet that holds the money for most of the DAO world. It is a **multisignature** account: instead of one private key, a Safe is controlled by a set of signers and a threshold — an “_m_-of-_n_” rule such as 4-of-7 — so no single person can move funds, and a transaction executes only once enough signers approve it on-chain. First shipped as Gnosis Multisig in 2017, rewritten as Gnosis Safe in 2018 and [rebranded to Safe in 2022](https://safe.global/), it has become the base custody layer for [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) treasuries. ([Safe docs](https://docs.safe.global/)) On non-EVM chains the same custody role falls to dedicated multisig standards — on Solana, [Squads](/wiki/dao-governance/tooling/treasury/squads).

## How a Safe works

A Safe is deployed as its own contract account with an owner list and a confirmation threshold. To spend from the treasury, an owner proposes a transaction; other owners add their signatures; once the threshold is met the Safe contract executes it atomically. Ownership, threshold and the queued transactions are all on-chain and publicly inspectable, which is why a DAO can hold a nine-figure treasury in a Safe and have every member verify exactly who can authorize a spend. ([what is Safe](https://docs.safe.global/home/what-is-safe))

## Modules, guards and governance execution

Safe is deliberately minimal at its core and extended through **modules** (which can trigger transactions under custom rules) and **guards** (which add pre-execution checks). This is the seam where custody meets governance: [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac)'s SafeSnap module lets a passed [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote execute against the Safe under an [optimistic challenge window](/wiki/dao-governance/concepts/voting/optimistic-governance), turning an off-chain signal into a binding treasury action without handing the keys to a single party. (UMA retired oSnap, the other module of this shape, on [15 December 2025](https://docs.uma.xyz/resources/osnap); treasuries that still have it installed should disable it.) Most DAO payments, streaming and analytics tools build directly on the Safe account model, and a further layer sells the workflow _above_ it — [Den](/wiki/dao-governance/tooling/treasury/den) adds notifications, decoded transactions and gas paid from the Safe without deploying any contract of its own. ([Safe modules](https://docs.safe.global/advanced/smart-account-modules))

## Why DAOs standardize on it

A treasury is a DAO's most valuable and most attacked asset, and Safe hit the pragmatic sweet spot: fully self-custodial and on-chain, but simpler and cheaper to run than a bespoke on-chain governor for a small or early organization. Its ubiquity is self-reinforcing — because nearly every treasury tool integrates Safe, new DAOs adopt it by default, and it secures a large share of all EVM DeFi value. ([Messari: Safe](https://messari.io/project/safe))

## Trade-offs

A multisig is a deliberate compromise. It buys speed, low cost and operational safety, but it concentrates power in the signer set: the treasury is only as decentralized as its _m_-of-_n_, and a colluding or compromised majority of signers is a real risk — which is why mature DAOs pair a Safe with on-chain governance (a Snapshot-plus-SafeSnap bridge or a full Governor) rather than letting a small council spend unchecked.

## How Caper approaches this

Caper folds custody into the protocol instead of bolting on a separate multisig. A caper's treasury is a contract-controlled vault governed directly by member [votes](/wiki/governance/voting) and [executed on-chain](/wiki/governance/execution), so there is no signer set to trust and no threshold to capture. It also adds a property a Safe does not have: members can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) and redeem a slice of that treasury sized by their canonical [vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — not a pro-rata claim by balance, since the redemption consumes both the governance tokens and the soulbound vote tokens earned by participating — so custody and exit are governed by the same rules rather than by a council's discretion.

## References

- Safe, [Documentation](https://docs.safe.global/) and [safe.global](https://safe.global/).
- Safe, [Zodiac module collection](https://github.com/gnosisguild/zodiac) (Gnosis Guild).
- Messari, [Safe project profile](https://messari.io/project/safe).

## Squads (Solana multisig & smart accounts)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/squads
Updated: 2026-07-27

| What it is | An open-source Solana program for multisig custody and account abstraction — the standard way Solana teams hold treasuries and control program upgrade authority. |
| --- | --- |
| Current program | Squads V4 ("Smart Account" standard), deployed to Solana mainnet-beta, Devnet, and Eclipse ([Squads-Protocol/v4](https://github.com/Squads-Protocol/v4)) |
| Category | Multisig / treasury custody / account abstraction |
| Chain | Solana (also deployed on Eclipse SVM) |
| License | AGPL-3.0 (some files Apache-2.0 / MIT) |
| Audits | OtterSec, Neodyme, Certora, Trail of Bits ([audit reports in-repo](https://github.com/Squads-Protocol/v4)) |
| Self-reported scale | 450+ teams, $15B+ in assets secured ([squads.xyz](https://squads.xyz/protocol)) |
| Ethereum analog | [Safe](/wiki/dao-governance/tooling/treasury/safe) |

**Squads** is the multisig and smart-account layer most Solana treasuries run on. Where Ethereum DAOs custody funds behind [Safe](/wiki/dao-governance/tooling/treasury/safe), Solana teams reach for Squads: an audited on-chain program that turns a single-key account into an _m-of-n_ account with roles, spending limits, and time locks. Squads Labs describes the protocol as "the autonomous finance layer built on Solana" ([squads.xyz](https://squads.xyz/protocol)), and the current [V4 program](https://github.com/Squads-Protocol/v4) is designed to "make it easier for developers to leverage multisig consensus and account abstraction on Solana."

It solves the first thing every DAO has to get right — _who can move the money_ — without a custodian and without trusting a hosted dashboard. That makes it a piece of treasury infrastructure rather than a governance framework: Squads decides who signs, while systems like [SPL Governance / Realms](/wiki/dao-governance/tooling/frameworks/spl-governance) decide how token holders _vote_ on what those signers should do.

## From V3 to V4: multisig as a smart account

Squads V4 reframes a multisig as a programmable **Smart Account** rather than a bare signer set. The on-chain program ([Squads-Protocol/v4](https://github.com/Squads-Protocol/v4)) ships:

- **Roles & permissions** — members can be granted distinct rights (propose, vote, execute) instead of a flat "all signers are equal" model.
- **Spending limits** — recurring caps that let day-to-day payments flow without a full multisig ceremony, while large moves still need the full threshold.
- **Time locks** — an enforced delay between approval and execution, the same [execution-delay safety primitive](/wiki/dao-governance/concepts/voting/governance-timelocks) used across DAO governance to create a window to react before a transaction lands.
- **Sub-accounts (vaults)** — multiple isolated vaults under one multisig, so a treasury, an ops float, and a grants budget can share governance without sharing a balance.

The V4 program is deployed to Solana mainnet-beta and Devnet, and to the [Eclipse](https://github.com/Squads-Protocol/v4) SVM rollup, under AGPL-3.0 and audited by OtterSec, Neodyme, Certora, and Trail of Bits.

## Securing program upgrade authority

A Solana program is deployed with a single **upgrade authority** — one key that can replace the program's code at will ([Solana docs: deploying programs](https://solana.com/docs/programs/deploying)). For a protocol holding user funds, that key _is_ the protocol: whoever controls it can ship a malicious upgrade in one transaction. Leaving it on a single hot key is the Solana equivalent of an unguarded proxy admin.

The standard fix is to hand upgrade authority to a Squads multisig, so a code change requires _m-of-n_ approval (and, with a time lock, a public delay before it takes effect). This is why Squads shows up in the risk footprint of most serious Solana protocols — treasuries like [Jito](/wiki/daos/staking/jito) and [Marinade](/wiki/daos/staking/marinade) custody funds and privileged authorities behind multisig control rather than a lone signer.

## Where it sits in the DAO stack

Squads is _custody_, not _governance_. It answers "which keys must sign," which is necessary but not sufficient for a DAO:

- It pairs with [SPL Governance / Realms](/wiki/dao-governance/tooling/frameworks/spl-governance), which supplies token-weighted voting on top — the vote decides _what_ to do, the multisig _executes_ it.
- It is the Solana counterpart to [Safe](/wiki/dao-governance/tooling/treasury/safe) on Ethereum; much of the tooling ecosystem (payments, streaming, analytics) plugs into one or the other.
- For small DAOs and working groups it is often the _whole_ governance stack — a signer set with roles and limits, no token vote at all, which keeps things simple but concentrates trust in the signers.

See the [DAO tooling stack overview](/wiki/dao-governance/tooling/dao-tooling-overview) for how custody, voting, membership, and analytics layers fit together.

## Limits and considerations

A multisig is a custody control, not a legitimacy mechanism. A 3-of-5 Squads account is exactly as decentralized as its five signers — if they are one team's laptops, the "DAO" is a company with extra steps. Multisig custody says nothing about whether the broader membership consented to a spend, only that the threshold of signers did.

It also inherits the classic multisig failure modes: lost or compromised keys, signer collusion at the threshold, and the coordination cost of getting _m_ humans to sign in time during an incident. Spending limits and time locks soften the day-to-day friction and the blast radius, but the trust still rests on _who holds the keys_ — a question multisig custody organizes rather than dissolves. That gap is exactly where on-chain governance and [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) pick up.

## How Caper approaches this

Squads answers "who can move the treasury." [Caper](/wiki/foundations/what-is-a-caper) is built around the harder question underneath it: _can a holder who disagrees leave with their share of the treasury_, without asking a signer set for permission? In a caper the treasury and each holder's claim on it are enforced by the protocol contract, so redeeming your share is a right you exercise on-chain — not a payment a multisig has to choose to send you ([rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)).

The two are complementary, not competing: a Solana team might still hold operating funds in a Squads multisig, but Caper's design assumes the strongest guarantee for members is one custody arrangements can't offer on their own — a contract-enforced exit, so control never comes down to trusting whoever holds the keys.

## References

- [Squads](https://squads.xyz) — official site
- [Squads Protocol](https://squads.xyz/protocol) — protocol overview and adoption figures
- [Squads-Protocol/v4](https://github.com/Squads-Protocol/v4) — the V4 program source, features, deployments, license, and audit reports
- [Squads documentation](https://docs.squads.so)
- [Solana docs — deploying programs](https://solana.com/docs/programs/deploying) (program upgrade authority)

## Superfluid (money streaming)

URL: https://caper.network/wiki/dao-governance/tooling/treasury/superfluid
Updated: 2026-07-20

|  |  |
| --- | --- |
| **Tool** | [Superfluid](https://superfluid.org/) |
| **Category** | Real-time money streaming · one-to-many distributions · payroll & subscriptions |
| **Founded** | 2020 (London); seed round [$9M led by Multicoin Capital](https://www.theblock.co/post/111139/ethereum-money-streaming-protocol-superfluid-raises-9-million-seed), July 2021 |
| **Founders** | Francesco Renzi, Michele D’Aliessi, Zhicheng Miao |
| **Core primitive** | [Super Tokens](https://docs.superfluid.org/docs/concepts/superfluid) + agreements (CFA money streams, GDA distribution pools) |
| **Contracts** | Upgradeable; Ethereum + EVM chains (Base, Optimism, Polygon, Arbitrum, Gnosis, …) |
| **Governance token** | [SUP](https://superfluid.org/post/introducing-sup-the-superfluid-token) (Feb 2025) — governs Superfluid DAO |

**Superfluid** ([superfluid.org](https://superfluid.org/)) is a real-time asset-streaming protocol: instead of sending a payment as a one-off transaction, an account opens a _stream_ that moves tokens to a recipient continuously, every second, at a set flow rate — and keeps flowing, with no further transactions, until someone cancels it or the sender runs out of balance. It is the reference primitive for treating money as a live _flow_ rather than a sequence of discrete transfers, and DAOs reach for it for exactly the payments that never really stop: contributor salaries, grants, subscriptions, and streaming reward programs. It sits alongside [Sablier](/wiki/dao-governance/tooling/treasury/sablier) as the other pole of on-chain streaming — where Sablier escrows a fixed pot and releases it over a set vesting schedule, Superfluid locks up no capital and simply nets every inflow and outflow in real time.

## Super Tokens: money as a flow

Everything in Superfluid is built on the **Super Token**, which the docs describe as [“an extension to the ERC-20 standard enabling the transfer of value in completely novel ways.”](https://docs.superfluid.org/docs/concepts/superfluid) Any ERC-20 can be _wrapped_ into its Super Token form (USDC becomes USDCx), and the protocol also supports natively-built _Pure Super Tokens_. The critical property is that a Super Token balance changes with the passage of time: rather than being updated only when a transaction lands, it is computed live from the account’s net flow rate, so a salary recipient’s balance visibly climbs each second while the payer’s falls. Because [“no capital is locked up, and all inflows and outflows are netted in real-time,”](https://docs.superfluid.org/docs/concepts/superfluid) a treasury that pays ten contributors and earns fees from a product nets all eleven flows into a single continuously-updating balance without a transaction per period.

## Money streaming: the Constant Flow Agreement

The streaming behaviour itself is one of Superfluid’s _agreements_. The [ConstantFlowAgreement (CFA)](https://docs.superfluid.org/docs/technical-reference/Architecture) governs a per-second flow: an account sets a flow rate (denominated in wei per second) to a recipient, and from that moment value moves continuously with no further action. As Superfluid puts it, [“Money Streaming allows for continuous, per-second token transfers between accounts”](https://docs.superfluid.org/docs/protocol/money-streaming/overview), and a [stream continues until it is cancelled by the sender or the sender’s balance depletes](https://docs.superfluid.org/docs/concepts/superfluid). This is the difference from a vesting stream: a CFA stream has no built-in end date and no escrowed pot behind it — it runs open-endedly as long as the sender keeps enough Super Token balance to sustain it, which makes it a natural fit for salaries and subscriptions that should simply keep paying.

## Distributions: one-to-many pools

Paying many recipients at once uses a different agreement. The [GeneralDistributionAgreement (GDA)](https://docs.superfluid.org/docs/technical-reference/Architecture) lets a pool admin create a [Superfluid Pool](https://docs.superfluid.org/docs/protocol/distributions/guides/pools) and assign each member a number of _units_; a distribution — whether an instant lump or an ongoing stream into the pool — is then split across members in proportion to their units, in a single scalable operation rather than one transfer per recipient. The GDA supersedes the earlier [InstantDistributionAgreement (IDA)](https://docs.superfluid.org/docs/technical-reference/Architecture), now deprecated. For a DAO this is the machinery behind proportional reward programs, revenue sharing, and gas-cheap airdrops: adjust a member’s units and their share of every future distribution changes automatically.

## Keeping streams solvent

An open-ended stream that carries no escrow raises an obvious question: what happens when the sender’s balance finally runs dry? Superfluid’s answer is a small _buffer_ — when a stream is opened the sender locks a modest deposit, sized to a short slice of the flow, rather than the whole future value. If the sender’s balance is exhausted while the stream is still open, the stream becomes liquidatable: anyone can close it, and the buffer is forfeited to cover the shortfall and reward the liquidator for cleaning up an insolvent stream. This keeps the system honest without escrowing capital — the buffer is the sender’s incentive to top up or cancel before running out, and the reason recipients can trust a live balance they never had to lock. The whole protocol is coordinated by a central [Host contract](https://docs.superfluid.org/docs/technical-reference/Architecture) that routes calls between the Super Token contracts and the CFA/GDA agreements.

## Why DAOs use it

Streaming reframes a recurring-payments problem that DAOs hit constantly. A treasury that votes a contributor a monthly salary does not want to run a governance transaction — or a manual multisig payout — every single month; a stream lets the DAO open the flow once and let it run, cancelling it with a single action if the engagement ends. The same shape covers [contributor compensation](/wiki/dao-governance/tooling/treasury/coordinape), retroactive and ongoing grants, product subscriptions billed per-second, and reward campaigns that pay continuously rather than in a lump. Because Super Tokens net all flows live, a DAO can watch its runway change in real time instead of reconciling it after each disbursement — a different emphasis from [Sablier](/wiki/dao-governance/tooling/treasury/sablier)’s escrowed vesting schedules, and a complement to active-management approaches like [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) in the broader picture of [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## From protocol to DAO: the SUP token

Superfluid is now governed by the tool it helped popularise. In February 2025 the Superfluid Foundation [introduced SUP](https://superfluid.org/post/introducing-sup-the-superfluid-token), the governance token of the protocol, distributed under a model it calls _Streaming Programmatic Rewards_ — fittingly, the token is itself streamed to ecosystem users over time rather than dropped all at once. One billion SUP were minted at genesis, with 60% allocated to the community (rewards, staking, and governance) and the team and early backers receiving 25% and 15% respectively under multi-year lockup streams with a one-year cliff. Holders participate through [Superfluid DAO](https://claim.superfluid.org/governance), making Superfluid both a piece of DAO tooling and a DAO in its own right.

## How Caper approaches this

Superfluid answers _“let this payment run continuously on its own.”_ [Caper](/wiki/foundations/what-is-a-caper) deliberately does the opposite: a caper’s treasury moves only in discrete, governed lumps. Every disbursement is a typed [proposal](/wiki/governance/proposals) — a `PAYOUT` that must win a vote and then executes a single on-chain transfer of a fixed amount, not an open-ended flow (verified in `caper_dao.rs`: `execute_proposal_payout` calls `treasury_vault.transfer(recipient, currency, amount)` once). There is no streaming primitive in the contract, and that is intentional — the point is that spending the treasury is always a decision on the record, not a standing drip. The two are complementary rather than competing: a caper could vote a grant and, if it wanted continuous settlement, fund a Superfluid stream out of a single approved payout. Where Caper puts the [funding decision](/wiki/markets/raising-funds) and the vote on-chain and auditable, Superfluid puts the _schedule_ on-chain — and a treasury can use both.

## References

- Superfluid, [“What is Superfluid” (docs)](https://docs.superfluid.org/docs/concepts/superfluid) · [Protocol Architecture](https://docs.superfluid.org/docs/technical-reference/Architecture)
- Superfluid, [Money Streaming overview](https://docs.superfluid.org/docs/protocol/money-streaming/overview) · [Distribution Pools](https://docs.superfluid.org/docs/protocol/distributions/guides/pools)
- Superfluid, [“Introducing SUP: The Superfluid Token”](https://superfluid.org/post/introducing-sup-the-superfluid-token) · [Superfluid DAO claim & governance](https://claim.superfluid.org/governance)
- The Block, [“Superfluid raises $9 million in seed funding”](https://www.theblock.co/post/111139/ethereum-money-streaming-protocol-superfluid-raises-9-million-seed)

## Agora

URL: https://caper.network/wiki/dao-governance/tooling/voting/agora
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Category** | On-chain governance platform — proposals, voting, delegation & execution front-end |
| **Launched** | 2022 |
| **Model** | Open-source (MIT); a hosted interface over on-chain Governor contracts, [free to fork](https://github.com/voteagora/agora-next) and self-deploy |
| **Powers** | [Optimism](/wiki/daos/networks/optimism-collective), [Uniswap](/wiki/daos/dexs/uniswap-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Nouns](/wiki/daos/social/nouns-dao), Scroll, Ether.fi, Derive and others |
| **Notable** | Acquired governance-analytics rival [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom) in January 2025 |
| **Scale** | 800k+ votes processed across its governor contracts; ~103k monthly users (Agora, 2026) |
| **Related** | [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), [Tally / Cactus](/wiki/dao-governance/tooling/voting/tally), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) |

**Agora** is an open-source, on-chain governance platform that gives a protocol a full voting stack — [proposals](/wiki/dao-governance/concepts/voting/proposal-lifecycle), [voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation), and execution — without the DAO writing its own governance front-end. It is the interface most of the largest [on-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) DAOs use to run binding votes: [Optimism](/wiki/daos/networks/optimism-collective), [Uniswap](/wiki/daos/dexs/uniswap-dao) and [ENS](/wiki/daos/infrastructure/ens-dao) all govern through Agora deployments. ([agora.xyz](https://www.agora.xyz/))

## What it does

Agora sits on top of a DAO’s on-chain Governor contracts and turns them into a usable product: [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) management, gasless voting, multiple-choice and standard proposals, delegate directories, transaction simulation before execution, and governance primitives such as security councils and dual governance. The whole codebase is [MIT-licensed](https://github.com/voteagora/agora-next) — a protocol can fork and self-host rather than depend on a hosted vendor, which matters for a system meant to [outlive its operators](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks). Agora positions this as letting engineers "progressively decentralize" while it carries the governance infrastructure. ([Agora](https://www.agora.xyz/))

## Where it sits in the stack

Governance tooling splits along the [on-chain / off-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) line. [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) owns the off-chain signaling layer — cheap, wallet-signed temperature checks with no binding effect. On the on-chain side, where a passed vote executes a transaction directly, Agora and [Tally (now Cactus)](/wiki/dao-governance/tooling/voting/tally) are the two dominant interfaces to OpenZeppelin-style Governor contracts. Agora’s niche is bespoke, deeply-integrated deployments for large L2 and protocol DAOs rather than a self-serve directory; a DAO typically pairs it with a [Safe](/wiki/dao-governance/tooling/treasury/safe) treasury and Snapshot for early signaling, as the [tooling-stack map](/wiki/dao-governance/tooling/dao-tooling-overview) lays out.

## The Boardroom acquisition (2025)

On [23 January 2025](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) Agora acquired [Boardroom](/wiki/dao-governance/tooling/analytics/boardroom), one of the oldest governance-analytics dashboards — a delegate-and-proposal aggregator whose API tracked over 2 million delegates across more than 300 protocols. Agora committed to [keeping Boardroom running as-is](https://www.agora.xyz/blogs/6-boardroom-acquisition), with founder Kevin Nielsen staying on as an advisor. The deal is part of a wider 2025–26 consolidation of governance tooling — the same period in which [Tally wound down its hosted product](/wiki/dao-governance/tooling/voting/tally) into Cactus — as the once-fragmented vendor landscape contracts toward a few full-stack governance providers. ([Boardroom’s announcement](https://governance.substack.com/p/boardroom-joins-the-agora-governance))

## How Caper approaches this

Agora exists because on-chain governance is normally a _separate layer_ bolted onto a protocol — a front-end and a set of Governor contracts a DAO adopts, integrates, and can later migrate off of. A [caper](/wiki/foundations/what-is-a-caper) folds that layer into the protocol itself: [proposal](/wiki/governance/proposals), [vote](/wiki/governance/voting) and [execution](/wiki/governance/execution) are native methods on the DAO’s own on-chain component, so there is no governance vendor to choose, wire up, or trust to stay live. The trade-off is the usual one — less pick-your-own-interface flexibility in exchange for no seam between the tool and the treasury it governs. For DAOs that do want a dedicated, battle-tested governance UI over standard Governor contracts, Agora is among the strongest choices.

## References

- Agora, [Great Onchain Governance](https://www.agora.xyz/) (product site); [agora-next](https://github.com/voteagora/agora-next) (source, MIT).
- Agora, [Boardroom joins Agora](https://www.agora.xyz/blogs/6-boardroom-acquisition) (23 Jan 2025).
- CoinDesk, [DAO Governance Platform Agora Acquires Older Competitor, Boardroom](https://www.coindesk.com/tech/2025/01/23/dao-governance-platform-agora-acquires-older-competitor-boardroom) (2025).

## Commonwealth (the DAO forum layer)

URL: https://caper.network/wiki/dao-governance/tooling/voting/commonwealth
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Tool** | [Common](https://common.xyz/) – the crypto-native governance forum launched as **Commonwealth**, whose original domain `commonwealth.im` now returns a 301 to common.xyz rather than serving the app |
| **Category** | Deliberation layer · governance forum · threads, polls and proposal staging ahead of a vote |
| **Operator** | Commonwealth Labs (Dillon Chen, CEO); [$20M raised, May 2022](https://decrypt.co/100437/common-raises-20m-to-build-dao-management-platform-launch-token) from Polychain, Dragonfly, Spark, Wintermute, LongHash and Mirana |
| **Code** | [hicommonwealth/commonwealth](https://github.com/hicommonwealth/commonwealth) – TypeScript, GPL-3.0, public since March 2020 |
| **Today** | Repositioned as an [“all-in-one product and protocol to launch a token, manage a DAO, or coordinate with agents”](https://docs.common.xyz/commonwealth/readme.md); token launchpad on Base, $COMMON retrodrop in claim registration |
| **Incumbent alternative** | [Discourse](https://www.discourse.org/) – self-hosted, generic, and still what Uniswap, Aave, Arbitrum and Sky run |
| **Related** | [The DAO proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [On-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) |

**Commonwealth** is the crypto-native governance forum: wallet-authenticated threads, token-gated topics, on-chain polls and a direct line into [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), built for the stage of governance that happens before anybody votes. It now trades as **Common**, and its centre of gravity has moved to launching tokens and coordinating AI agents. The forum layer it was built to own is still, in 2026, mostly [Discourse](https://www.discourse.org/).

That stage matters more than the tooling map usually admits. A DAO's binding decisions are made by contract, but they are _shaped_ in a thread: the version of the proposal that reaches a vote is the version the forum argued into shape, and the options that never make the ballot die there too. The forum is also the archive – the only durable record of why a treasury did what it did. Custody has a standard, voting has a standard, and deliberation has a text box.

## The deliberation layer, and who actually runs it

The [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) starts with discussion and a temperature check long before a Governor contract sees a transaction. That first stage needs somewhere to live, and the market settled on general-purpose forum software rather than anything DAO-specific. A check of the four largest governance forums today returns the same answer from each: [gov.uniswap.org](https://gov.uniswap.org/), [governance.aave.com](https://governance.aave.com/), [forum.arbitrum.foundation](https://forum.arbitrum.foundation/) and [forum.sky.money](https://forum.sky.money/) all identify themselves as [Discourse](https://github.com/discourse/discourse) installations in their own page metadata.

Discourse is a decade-old open-source forum with no crypto features at all: no wallet login, no token gating, no vote weighting. It won this layer on the properties that matter for an archive rather than the ones that demo well – the DAO self-hosts it, owns the database, and can export the whole thing. Commonwealth's wager was that the deliberation layer should instead be native to the chain the DAO governs.

## What Commonwealth built

The product is a forum with the governance machinery wired in rather than bolted on.

- **Wallet-native identity.** Members sign in with an EVM, Cosmos or Solana wallet (or social login backed by a managed wallet), so the account posting in the thread is the account that holds the tokens – the [stated case](https://docs.common.xyz/commonwealth/readme/product-features.md) for a crypto-native forum over Reddit or Discourse.
- **Stages.** A [thread-tagging system](https://docs.common.xyz/commonwealth/community-overview/capabilities/manage-community/stages.md) that communities mostly use, in the docs' own words, “to document which governance stage the thread is in”. It is the lifecycle rendered as a filter: the forum knows the difference between an idea and a proposal in voting.
- **Groups and gating.** Topics and threads can be gated on ERC-20, ERC-1155 or other on-chain credentials, which turns [who may speak](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) into an on-chain question rather than a moderator's.
- **Trust levels.** A [spam-resistance ladder](https://docs.common.xyz/commonwealth/account-overview/user-trust-levels.md) mixing on-chain and social signals, with per-level daily caps on posts, upvotes and AI generations – an admission that an open, wallet-authenticated forum is cheap to flood.
- **Snapshot, both directions.** Admins connect one or more Snapshot spaces, and members [create and vote on Snapshot proposals from inside the thread](https://docs.common.xyz/commonwealth/community-overview-2/governance/snapshot-bi-directional-integration/off-chain-governance.md), so the temperature check does not require leaving the discussion. The integration is restricted to ERC-20 communities.
- **Native governance surfaces.** The platform [reads](https://docs.common.xyz/commonwealth/community-overview-2/governance.md) Governor Alpha, Governor Bravo, Aave, Substrate, Cosmos and Sputnik v2 governance alongside Snapshot and its own polls, which is what let one forum serve DAOs that had nothing in common at the contract level.
- **Discourse import.** A [full migration path](https://docs.common.xyz/commonwealth/launch/launch-a-community-on-common/discourse-import.md) that carries threads, comments and upvotes across from an existing Discourse backup. The documentation index covers that direction and no equivalent route back out.

## Community Stake: pricing a seat in the room

The most consequential design decision was to make participation itself an asset. [Community Stake](https://docs.common.xyz/commonwealth/community-overview-1/community-stake.md) gives a community an ERC-1155 namespace and a stake contract; members buy and sell stake directly from that contract, priced on a [bonding curve](/wiki/markets/bonding-curve) that rises with supply, and holding stake places them in a stakeholder subgroup with elevated rights inside the forum. Trades pay a fee, part of which routes to a community treasury controlled by the admin who enabled stake. It launched on Base and Blast in March 2024.

This is a genuinely different theory of a forum. Discourse gives moderators discretion and members equality; Community Stake gives the community a market in its own attention, and standing in the discussion becomes something you can buy or sell at a price that moves. It also gives the platform a fee to earn from a conversation, which is the hinge the rest of the story turns on.

## From forum to launchpad

In May 2022 Commonwealth raised [$20M](https://decrypt.co/100437/common-raises-20m-to-build-dao-management-platform-launch-token) from Polychain, Dragonfly, Spark Capital, Wintermute, LongHash and BitDAO's Mirana, reporting 60,000 active users across 700+ communities including dYdX, Axie Infinity, NEAR, Solana, BitDAO and Polygon, and announced a governance token, $CMN, as its route to decentralising the platform.

What shipped four years later is a different product. Common now describes itself as [“the coordination layer for communities, contributors, and AI agents”](https://docs.common.xyz/commonwealth/readme.md) and reports 100,000+ communities, 4M users and 50k tokens launched. The [Ideacoin Launchpad](https://docs.common.xyz/commonwealth/launch/launchpad.md) mints ERC-20s on Base in one click and names its audience plainly: creators, “degens & early adopters” looking for high-risk, high-reward opportunities, and anyone after a fun, fast, low-cost launch. The [protocol documentation](https://docs.common.xyz/commonwealth/protocol/protocol-overview-introduction.md) describes the whole system as “tokenized attention for actions, ideas, and more”, built from a namespace, contests, referrals and a bonding-curve launchpad. The quest ladder rewards [launching a token](https://docs.common.xyz/commonwealth/commonaura/commonaura/season-2/season-2-week-1/quest-99-or-launch-token.md), graduating it and trading it; [Postcoins](https://blog.common.xyz/introducing-postcoins/) (March 2026) makes an individual thread a tradable asset. The token that arrived is $COMMON, [distributed by retrodrop on Base](https://docs.common.xyz/commonwealth/protocol/common-claims.md) through Magna, with contributor and investor allocations on a four-year vest and a one-year cliff.

The clearest statement of the turn is the house blog arguing that [conditional markets will replace token voting](https://blog.common.xyz/why-conditional-markets-will-replace-token-voting/) (December 2025): one token one vote produces plutocracy, apathy and whale capture, so run [prediction markets](/wiki/dao-governance/concepts/voting/futarchy) on proposal outcomes instead. The diagnosis matches what the wiki's own [turnout data](/wiki/dao-governance/concepts/analysis/voter-apathy) shows. But it is a striking thing to read from the company that spent seven years hosting the deliberation, and it tells you what the platform now thinks the forum is for.

## Why the incumbent held

Commonwealth's features were real and the DAOs with the most at stake still did not move. The reasons are unglamorous and worth stating plainly, because they generalise to any hosted governance tool.

- **The archive outlives the vendor.** A governance forum is the institutional memory of every decision a treasury has made. Self-hosted Discourse means the DAO holds that record in its own database; a hosted forum means the record's availability is a function of somebody's runway and roadmap.
- **Neutrality is a feature.** Generic software has no opinion about tokens, no fee to earn from the conversation and no launchpad to cross-sell. When the venue for deliberation has its own token economics, the venue is a participant.
- **Migration is one-way in practice.** Importing a Discourse backup is a documented service; reconstructing years of threads out of a hosted platform is not a path anyone has published.
- **Crypto-native login solves a problem forums do not have.** Wallet identity is essential for voting and gating, and largely optional for arguing. The pain that moved DAOs off Discourse was never authentication.

## What to weigh before adopting one

- **Deliberation has no execution guarantee.** Nothing said in a forum binds anyone. It is the softest layer of [off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), which is exactly why it is where capture is cheapest – controlling which proposals get drafted, framed and stress-tested is more valuable than controlling any single vote.
- **Gating the discussion narrows the argument.** Token-gated topics keep out spam and also keep out the researcher, the journalist and the affected user who hold nothing. Every gate on speech is a decision about whose objections the DAO will hear before it votes.
- **Pricing standing changes who speaks.** A staked or token-weighted forum reproduces the [plutocracy problem](/wiki/dao-governance/concepts/analysis/voter-apathy) one layer earlier, where it is far less visible than a public vote tally.
- **Keep the record portable.** Whatever venue a DAO picks, the test is whether it can walk away with the full history intact. If it cannot, the vendor holds a veto over the DAO's memory.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no forum. There is no discussion stage, no temperature check and no venue the protocol knows about – members argue wherever they already talk, and none of it is on the ledger.

What the protocol does hold is the proposal itself. A [proposal](/wiki/governance/proposals) carries its title and description on-ledger as part of the proposal record, so the case put to members is stored with the decision rather than on a forum that may not outlive it. Posting one costs a fee that is deposited into the DAO's own treasury and requires holding the DAO's token, which is the whole of the spam defence – there are no trust levels and no moderators. Every proposal must offer members more than one option, and each option carries its consequences as structured data: the recipient, the currency, the amount. There is no separate drafting window, either: [voting](/wiki/governance/voting) opens the moment the proposal is created and runs to a fixed close, so the debate happens against a clock that is already running.

The trade-off is honest. A caper gains a decision record that cannot be edited, taken down or lost with a vendor, and gives up the deliberation stage where a proposal is usually improved before anyone commits to it.

## References

- Common, [Welcome to Common](https://docs.common.xyz/commonwealth/readme.md) · [Features](https://docs.common.xyz/commonwealth/readme/product-features.md) · [Governance](https://docs.common.xyz/commonwealth/community-overview-2/governance.md) · [Community Stake](https://docs.common.xyz/commonwealth/community-overview-1/community-stake.md) · [Ideacoin Launchpad](https://docs.common.xyz/commonwealth/launch/launchpad.md) · [Protocol overview](https://docs.common.xyz/commonwealth/protocol/protocol-overview-introduction.md) · [Common Claims](https://docs.common.xyz/commonwealth/protocol/common-claims.md)
- Common blog, [Why Conditional Markets Will Replace Token Voting](https://blog.common.xyz/why-conditional-markets-will-replace-token-voting/) (Jay Peredo, 20 Dec 2025) · [Introducing: Postcoins](https://blog.common.xyz/introducing-postcoins/) (18 Mar 2026)
- Decrypt, [Common Raises $20M to Build DAO Management Platform, Launch Token](https://decrypt.co/100437/common-raises-20m-to-build-dao-management-platform-launch-token) (24 May 2022)
- GitHub, [hicommonwealth/commonwealth](https://github.com/hicommonwealth/commonwealth) (GPL-3.0)
- Discourse, [project site](https://www.discourse.org/) · [discourse/discourse](https://github.com/discourse/discourse)
- Governance forums checked: [Uniswap](https://gov.uniswap.org/) · [Aave](https://governance.aave.com/) · [Arbitrum](https://forum.arbitrum.foundation/) · [Sky](https://forum.sky.money/)

## Kleros

URL: https://caper.network/wiki/dao-governance/tooling/voting/kleros
Updated: 2026-08-06

**Kleros** is a decentralized arbitration protocol on Ethereum — a general-purpose [“crypto supreme court”](https://kleros.io/) that renders binding rulings on subjective disputes that a smart contract cannot decide by itself. When code needs a human judgement — did a freelancer deliver the work, is this token listing legitimate, is this a real person — Kleros supplies a decentralized, game-theoretic answer instead of a trusted human moderator. It is the most widely deployed of the DAO-tooling category's _dispute-resolution_ primitives, and a common building block behind curated registries, escrow, and identity systems.

|  |  |
| --- | --- |
| **Category** | Dispute resolution · arbitration · oracle for subjective facts |
| **Founded** | 2017 (France, as Coopérative Kleros); court & token live from 2018 |
| **Founders** | Federico Ast, Clément Lesaege |
| **What it does** | Crowdsourced jurors, drawn by staked PNK, rule on disputes; incentives converge on the honest answer |
| **Token** | PNK (pinakion) — staked for jury duty and used for protocol governance |
| **Built on** | Ethereum; Kleros V2 extends to further chains ([deployment addresses](https://docs.kleros.io/reference/contracts/deployment-addresses)) |
| **Site** | [kleros.io](https://kleros.io/) · [docs](https://docs.kleros.io/) · [GitHub](https://github.com/kleros) |
| **Related** | [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

## The gap Kleros fills: disputes code can’t settle

On-chain governance is good at questions with objective, verifiable answers: did a proposal reach quorum, did a transfer execute. It is helpless at _subjective_ questions — whether delivered work met a spec, whether a submitted photo is really the claimed person, whether an insurance condition was met. Traditionally these route to a trusted moderator, an admin multisig, or an off-chain court, each of which reintroduces exactly the centralized chokepoint a DAO is trying to remove.

Kleros positions itself as a neutral third party for these cases: an [arbitration protocol](https://docs.kleros.io/court/overview) that any contract can call to obtain a ruling, and whose jurors are anonymous, self-selected, and economically motivated to answer honestly. It is the decentralized analogue of an appeals court — invoked when a smart-contract relationship needs judgement rather than computation.

## The court: staking PNK and random selection

Jurors opt in by staking **PNK** (pinakion) in a [subcourt](https://docs.kleros.io/court/overview) — a specialization such as general, software development, or curation. Courts form a tree with the _General Court_ at the root; staking in a subcourt automatically stakes you in every court above it. When a dispute arises, jurors are drawn at random with probability _proportional to the PNK they have staked_: the more you stake, the more often you are selected, which also puts more of your own capital at risk on each case.

Drawn jurors review the evidence and cast a vote — typically _Yes_, _No_, or _Refuse to Arbitrate_ for invalid or illegal cases — and, in hidden-vote courts, first commit a hashed vote and reveal it later so jurors cannot copy one another. Jurors are expected to justify their vote in writing. Neither party knows who the jurors are, which is what makes the panel hard to bribe or intimidate.

## The coherence incentive: a Schelling point for truth

Kleros never asks a juror to prove they are right — it rewards _coherence_ with the eventual majority. Jurors who vote with the majority are paid the arbitration fees the parties deposited, _plus_ PNK [redistributed from jurors who voted incoherently](https://docs.kleros.io/concepts/tokenomics). Jurors on the losing side forfeit part of the PNK they staked to be drawn.

This turns the honest answer into a [focal (Schelling) point](https://en.wikipedia.org/wiki/Focal_point_(game_theory)): absent collusion, a rational juror’s best guess of what other jurors will conclude is the true, evidenced answer, so voting honestly is the profit-maximizing strategy. A juror who votes randomly without reading the evidence is more likely to land incoherently and lose their stake, so over time careless or dishonest jurors bleed capital and leave. The security model is economic, not reputational — influence and risk both scale with money staked.

## Appeals: escalating juries and crowdfunded fees

Any party who disagrees with a ruling can **appeal**, which re-tries the case before a larger panel — the number of jurors roughly doubles each round, raising both the cost of capturing a majority and the fees at stake. Because appeal fees can be [crowdfunded](https://docs.kleros.io/court/appeals), third parties who believe a ruling is wrong can chip in toward the correct side’s appeal, and crowdfunders backing the side that ultimately wins are financially rewarded. The escalating cost is deliberate: it makes frivolous appeals expensive while giving an obviously-wrong first-round result a path to be overturned by a bigger, more expensive jury.

## Beyond the court: Curate, Escrow, Proof of Humanity, Scout

Kleros Court is the engine; most people meet Kleros through the products built on it:

- [**Kleros Curate**](https://docs.kleros.io/products/curate) — token-curated registries: decentralized lists (of tokens, addresses, content) where entries are challenged and disputes settle in court. This is the modern descendant of the token-curated-registry idea.
- [**Kleros Escrow**](https://docs.kleros.io/products/escrow) — a payment escrow where a disputed release is arbitrated by the court rather than a platform.
- [**Proof of Humanity**](https://docs.kleros.io/products/proof-of-humanity) — a Sybil-resistant registry of unique humans (video submission plus social vouching, issuing soulbound IDs), with challenges adjudicated by Kleros. It underpins [UBI-style](https://en.wikipedia.org/wiki/Universal_basic_income) distribution and one-person-one-vote experiments.
- [**Kleros Scout**](https://docs.kleros.io/products/scout) — a community-curated database of contract and token metadata used to flag scams inside wallets and explorers.

Each product is really the same pattern: put a subjective claim on-chain, let anyone challenge it, and fall through to the court when they do.

## The PNK token, governance, and V2

[PNK](https://docs.kleros.io/concepts/pnk-token) does double duty: it is the stake that gates jury selection (and the collateral slashed for incoherence) and the governance token of the Kleros DAO, which votes on protocol parameters, court creation, and treasury. Notably, PNK is deliberately _not_ a general-purpose payment token — arbitration fees are paid in ETH or stablecoins, while PNK is the skin-in-the-game that secures juror honesty, an intentional separation so that buying influence over rulings is distinct from paying for them.

**Kleros V2** re-architects the court and extends it beyond Ethereum mainnet to additional chains, lowering the gas cost of participating; current deployments are listed in the [developer docs](https://docs.kleros.io/reference/contracts/deployment-addresses).

## Limits and failure modes

Kleros’s guarantees are probabilistic and economic, and they have edges. A **51% attack** is possible in principle: an actor holding a majority of the PNK staked in a small subcourt can force coherent-but-wrong verdicts, which is why high-value disputes belong in deep, well-staked courts and why appeals escalate. **P + ε bribery** — paying jurors a small premium above the honest payoff to vote a certain way — is the classic theoretical attack on Schelling-point schemes, mitigated but not eliminated by appeals and stake redistribution. Rulings are only as good as the **evidence and policy** the parties and subcourt supply, so a poorly specified dispute yields a poorly reasoned verdict. And because influence tracks staked PNK, the court’s neutrality rests on token distribution being wide enough that no single party can quietly dominate a subcourt.

## How Caper approaches this

Caper has no arbitration court, and for its core decision — how a [caper’s](/wiki/foundations/what-is-a-caper) treasury is spent — it does not need one: a [proposal](/wiki/governance/proposals) is voted and [executed](/wiki/governance/execution) in one binding on-chain flow, with no subjective step for a jury to adjudicate. Where a member simply _disagrees_ with where the collective is heading, Caper’s answer is not litigation but the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): you redeem your canonical share of the treasury — vote weight `(t·v)/(V·T)`, verified in the contract’s `compute_vote_weight` — and leave, rather than appealing to a paid panel.

The two protocols also make opposite bets on whether adjudication power should be _for sale_. A Kleros juror’s influence scales with purchasable PNK stake; Caper’s governing weight is a **soulbound**, non-transferable proof-of-vote token that must be earned by participating and cannot be bought or sold. Kleros makes juror honesty a market (stake, risk, reward); Caper removes the market from voting power entirely. They are complements, not competitors: a caper that ever needed to settle a genuinely subjective condition — did a funded milestone actually ship — could call an oracle like Kleros for that fact while keeping the money decision on its own binding rails.

## References

- Kleros, [kleros.io](https://kleros.io/) and [documentation](https://docs.kleros.io/).
- Kleros docs, [Court: how it works](https://docs.kleros.io/court/how-it-works), [Appeals](https://docs.kleros.io/court/appeals) and [Tokenomics](https://docs.kleros.io/concepts/tokenomics) (dispute lifecycle, appeal-fee crowdfunding, the coherence incentive, PNK).
- Kleros, [Court](https://docs.kleros.io/court/overview), [Curate](https://docs.kleros.io/products/curate), [Escrow](https://docs.kleros.io/products/escrow), [Proof of Humanity](https://docs.kleros.io/products/proof-of-humanity).
- Kleros, [Deployment addresses](https://docs.kleros.io/reference/contracts/deployment-addresses) (V2 chains).
- Kleros, [GitHub organization](https://github.com/kleros) and [blog](https://blog.kleros.io/).

## OpenZeppelin Governor

URL: https://caper.network/wiki/dao-governance/tooling/voting/openzeppelin-governor
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Tool** | OpenZeppelin Governor — the modular, on-chain governance contract library used by most token-voting DAOs |
| **Category** | Governance execution layer — the smart contract that turns a passed vote into an on-chain action |
| **Lineage** | Compound **GovernorAlpha** (2020) → **GovernorBravo** (2021) → OpenZeppelin generalised the pattern into a reusable [Governor](https://docs.openzeppelin.com/contracts/5.x/governance) library |
| **Voting power** | Read from an [IVotes](https://docs.openzeppelin.com/contracts/5.x/api/governance) token ([ERC20Votes](https://docs.openzeppelin.com/contracts/5.x/api/governance) / [ERC721Votes](https://docs.openzeppelin.com/contracts/5.x/api/governance)) — snapshot balances + delegation, not raw balances |
| **Execution** | Optional [TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance) — a passed proposal is queued, then executes after a delay |
| **Front-ends** | [Tally](/wiki/dao-governance/tooling/voting/tally) · [Agora](/wiki/dao-governance/tooling/voting/agora) read Governor state directly from chain |
| **Licence** | MIT (OpenZeppelin Contracts) · [source on GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) |
| **Library version** | [v5.7.0](https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v5.7.0), released 29 July 2026 · governance extensions dated in the [CHANGELOG](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) |
| **Module count** | 17 contracts in [contracts/governance/extensions](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) – most descriptions of Governor stop at the original five |
| **Related** | [On- vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) · [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) · [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) |

**OpenZeppelin Governor** is the smart-contract framework that most token-voting DAOs use to run their governance _on-chain_ — where the vote and its execution both live in code, not on a signer's discretion. Where [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) records off-chain sentiment and a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig then acts on it by hand, a Governor closes the loop: a proposal carries the exact calls it will make, token holders vote, and if it passes anyone can trigger the execution the contract already holds. It is the reference implementation of [on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), shipped as auditable, MIT-licensed modules in the [OpenZeppelin Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) library.

## From Compound Bravo to a reusable library

The design descends from Compound. [Compound](/wiki/daos/lending/compound-dao) shipped **GovernorAlpha** in 2020 to hand protocol control to COMP holders, then replaced it with **GovernorBravo** — which put the governance logic behind an upgradeable proxy and added an explicit _Abstain_ option alongside For and Against. OpenZeppelin then [generalised that pattern](https://docs.openzeppelin.com/contracts/5.x/governance) into a modular Governor that any project can deploy without forking Compound's code, keeping deliberate [compatibility with GovernorAlpha and GovernorBravo](https://docs.openzeppelin.com/contracts/5.x/governance) (via `ERC20VotesComp` and `GovernorTimelockCompound`) so Compound-lineage DAOs can migrate. Compound's live parameters still read as the canonical example: a [25,000 COMP proposal threshold, a 2-day review period, 3 days of voting, a 400,000-vote quorum, and a 2-day timelock](https://docs.compound.finance/v2/governance/) — roughly a week from proposal to execution.

## A contract assembled from modules

Governor is not one monolith but a base contract plus opt-in extensions, so a DAO composes only the policy it wants ([full module reference](https://docs.openzeppelin.com/contracts/5.x/api/governance)):

- **GovernorSettings** — the tunable knobs: `votingDelay` (snapshot lag before voting opens), `votingPeriod` (how long the poll stays open), and `proposalThreshold` (voting power required to submit).
- **GovernorVotes** — hooks the Governor to an [IVotes](https://docs.openzeppelin.com/contracts/5.x/api/governance) token so voting power is read from historical, delegated balances rather than whatever a wallet holds at the moment of voting.
- **GovernorVotesQuorumFraction** — defines quorum as a percentage of total token supply, so it scales as the token does.
- **GovernorCountingSimple** — the tally rule: three options (For, Against, Abstain), where [only For and Abstain count toward quorum](https://docs.openzeppelin.com/contracts/5.x/governance).
- **GovernorTimelockControl** — routes execution through a [TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance) so a passed proposal is queued and executes only after a mandatory delay, giving holders a window to [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) before a change lands.

Because voting power comes from a snapshot taken at the proposal's start block, buying tokens after a vote opens grants no extra weight — a core defence discussed under [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) and [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation).

## The proposal lifecycle

Every proposal walks a fixed state machine — the [eight states](https://docs.compound.finance/v2/governance/) shared by Bravo and OZ Governor: **Pending** (submitted, waiting out the voting delay), **Active** (voting open), then a terminal branch. A proposal that fails to reach quorum or a majority becomes **Defeated**; one that passes becomes **Succeeded**, is **Queued** in the timelock, and finally **Executed**. A proposer below threshold can be **Canceled**, and a queued proposal left un-executed past its grace window turns **Expired**. This is the concrete, code-enforced version of the abstract [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle): no step can be skipped, and the calldata that executes is the exact calldata that was voted on.

## What the library added after 2023

The five modules above are the set almost every live Governor was assembled from, and the set most descriptions of Governor still stop at. The library did not stop there. The [extensions directory](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) now holds seventeen contracts, and the [CHANGELOG](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) dates each one:

- **v4.5.0** (9 February 2022) – [GovernorPreventLateQuorum](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorPreventLateQuorum.sol) extends the deadline when a vote reaches [quorum](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) late, so a large holder cannot trip quorum in the closing minutes and end the poll before anyone can answer. v5.7.0 bounded it: `_maxLateQuorumVoteExtension` defaults to `votingPeriod()`, capping total voting duration at twice the period, because an unbounded extension could otherwise brick governance.
- **v5.0.0** (5 October 2023) – [GovernorTimelockAccess](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorTimelockAccess.sol) routes execution through an `AccessManager` instead of a single `TimelockController`, so the delay is set per restricted function rather than globally for every proposal.
- **v5.1.0** (17 October 2024) – [GovernorCountingFractional](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol), the subject of the next section.
- **v5.2.0** (8 January 2025) – [GovernorCountingOverridable](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol) lets a token holder overrule the vote their [delegate](/wiki/dao-governance/concepts/voting/voting-and-delegation) already cast, emitting `OverrideVoteCast` and a matching `VoteReduced` against the delegate. It requires a token inheriting [VotesExtended](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol), which checkpoints delegations and balances rather than voting units alone – so an existing `ERC20Votes` token cannot switch it on without changing the token.
- **v5.3.0** (9 April 2025) – four at once: [GovernorSuperQuorum](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorSuperQuorum.sol) and its supply-fraction variant let a proposal that clears a higher bar reach **Succeeded** before the deadline; [GovernorProposalGuardian](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) names an address that may cancel any proposal at any stage; and `GovernorSequentialProposalId` numbers proposals 1, 2, 3 instead of hashing their calldata.
- **v5.4.0** (17 July 2025) – `GovernorNoncesKeyed`, keyed nonces for voting by signature.
- **v5.7.0** (29 July 2026) – [GovernorCrosschain](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCrosschain.sol) relays a passed proposal to a remote executor on another chain over an [ERC-7786](https://eips.ethereum.org/EIPS/eip-7786) gateway, which is the first time the library treats the executing chain as a parameter rather than an assumption.

The pattern is worth naming. Every one of these changes what a vote _means_ – who may cast it, when counting stops, who may stop it – while leaving the proposal interface untouched. A DAO can therefore alter its own franchise by swapping a counting module, and the change is invisible to any dashboard reading only proposal state.

## Fractional voting, and the DAOs that paid for it and never switched it on

[GovernorCountingFractional](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol) adds a fourth support value alongside For, Against and Abstain: `255`, which means "split my weight". A vote cast with it carries a `params` blob of three packed `uint128` values – against, for, abstain – and the module tracks `usedVotes` per voter, so weight can be spent across several transactions rather than all at once. Cast a plain Bravo vote instead and it consumes the whole remaining balance in one option, exactly as [GovernorCountingSimple](https://docs.openzeppelin.com/contracts/5.x/api/governance) does.

The point is not that individuals want to hedge. It is that a _contract_ holding tokens on behalf of many people can finally vote the way those people actually split. The library's own header lists the cases: tokens sitting in a DeFi pool, tokens bridged to an L2 and held by the bridge, and [shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting) from a pool using zero-knowledge proofs. Without it, a pooled position votes as one bloc or not at all – which is why so much delegated weight goes uncast.

The module is not OpenZeppelin's invention. Its source header credits [ScopeLift's Flexible Voting](https://github.com/ScopeLift/flexible-voting), built under a Uniswap Grants Program grant and [introduced to the Uniswap DAO in July 2022](https://gov.uniswap.org/t/temperature-check-upgrading-to-a-flexible-voting-enabled-governor/17098). That temperature check drew two replies and went nowhere. In 2024 ScopeLift built it again for [Arbitrum](/wiki/daos/networks/arbitrum-dao), as `L2ArbitrumGovernorV2` with a `GovernorCountingFractionalUpgradeable`, and OpenZeppelin [reviewed it between 8 and 19 July 2024](https://forum.arbitrum.foundation/t/arbitrum-governor-v2-review/26118) – nine issues, eight resolved.

The on-chain proposal to deploy it did not pass. The objection Offchain Labs raised in the [follow-up thread](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) is the sharpest available argument about adopting a counting module piecemeal: Arbitrum One runs **five** governors, the upgrade covered two, and the three [Security Council](/wiki/dao-governance/concepts/fundamentals/security-councils) governors would have been left behind – so voters using fractional clients would not take part in council elections by default, "giving non-flexible votes an exaggerated effect ... and affecting quorums". The work was then split, and the half that kept moving was proposal cancellation, not fractional voting. By February 2026 the cancellation upgrade had been audited and bundled onto a constitutional AIP, while a delegate noted in the same thread that Flexible Voting "is still pending to be delivered" – from a temperature check approved in March 2024.

So the mechanism outlived both proposals that commissioned it. It is in the standard library, MIT-licensed, available to any DAO deploying a new Governor today; the two DAOs that paid to have it built still do not run it. That gap between what the tooling can do and what deployed governance does is the recurring shape of [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity).

## Where the modules pull against each other

Modules compose mechanically but not always politically, and the library says so in its own comments – which makes these the cheapest governance-design warnings a DAO will ever get.

- **Early closure defeats the override.** `GovernorCountingOverridable` notes that override votes can only be cast while a proposal is _active_, so "mechanisms that shorten the voting duration, such as the early closure implemented in `GovernorSuperQuorum`, may therefore prevent token holders from overriding the votes cast with their tokens by their delegates". A DAO that adopts both has handed holders a check on their delegates and then built the thing that can close the window before they use it.
- **A low super quorum can decide a vote before the opposition arrives.** `GovernorSuperQuorum` warns that if the bar is set low enough for For votes to clear it early, a proposal "can succeed prematurely before enough AGAINST voters have a chance to vote". The module's safety depends entirely on a parameter, and that parameter is set by the DAO that benefits from setting it low.
- **The proposal guardian is a discretionary actor by another name.** `GovernorProposalGuardian` lets one address cancel any proposal at any stage of its lifecycle – and if no guardian is configured, [the proposer inherits that power over their own proposals](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol). Governor's selling point is that no one has discretion over a passed vote; this module reintroduces discretion before the vote finishes, which is a defensible safety valve and a governance decision that deserves to be argued rather than inherited from a default.

None of these is a bug. Each is a real trade-off written down where an integrator can read it, which is more than most governance frameworks offer – but a DAO that assembles modules without reading the trade-offs has changed its constitution by import.

## Who runs on it

Governor and its Bravo ancestor underpin a large share of on-chain DAO governance: [Compound](/wiki/daos/lending/compound-dao), [Uniswap](/wiki/daos/dexs/uniswap-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), [Nouns](/wiki/daos/social/nouns-dao), and the [Arbitrum](/wiki/daos/networks/arbitrum-dao) and [Optimism](/wiki/daos/networks/optimism-collective) L2 DAOs all execute through Governor-family contracts. That concentration is why the tooling ecosystem standardised on it: governance dashboards like [Tally](/wiki/dao-governance/tooling/voting/tally) and [Agora](/wiki/dao-governance/tooling/voting/agora) can index any Governor by reading the same well-known interface, no bespoke integration per DAO.

## Strengths and known failure modes

Governor's value is credible neutrality: the rules are public, immutable per-deployment, and execute without a trusted operator. But on-chain execution is not the same as good governance. The recurring failure modes are covered under [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) — low turnout letting a small quorum decide, whales or delegated blocs steering outcomes, and the sharpest risk, a malicious proposal whose _on-chain_ execution is exactly what makes it dangerous once it clears the timelock. The timelock is the mitigation, not a cure: it buys review and exit time, but a passed proposal still runs the calldata it carried. Governor gives a DAO a trustworthy _machine_; whether the machine does the right thing still depends on [participation and incentive design](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) shares Governor's core stance — a passed vote executes on-chain, not at a signer's discretion — but narrows the execution surface deliberately. Rather than arbitrary calldata queued behind a timelock, a Caper proposal resolves to one of a few _typed_ actions: a treasury payout, an investment into another caper, or a vote it casts on the DAO's behalf. Each type runs through its own dedicated execution path rather than a general-purpose call, so the set of things a winning proposal can do is bounded by the contract, not by whatever bytecode a proposer attached. It is the same [on-chain-execution](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) guarantee with a smaller blast radius.

## References

- [OpenZeppelin Contracts – CHANGELOG](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) (release dates for every governance extension cited above) and the [v5.7.0 release](https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v5.7.0), 29 July 2026
- [contracts/governance/extensions](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) – the seventeen modules, including [GovernorCountingFractional.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol) (the `255` support value, the packed `uint128` params, `usedVotes`), [GovernorCountingOverridable.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol) (the early-closure note, `OverrideVoteCast`, `VoteReduced`), [GovernorSuperQuorum.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorSuperQuorum.sol) (the premature-success warning) and [GovernorProposalGuardian.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) (`_validateCancel` and the unconfigured-guardian fallback)
- [VotesExtended.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol) – the delegation and balance checkpoints the override module requires of the token
- [ScopeLift – Flexible Voting](https://github.com/ScopeLift/flexible-voting) and [flexiblevoting.com](https://flexiblevoting.com) (the UGP grant, the use cases upstreamed into v5.1)
- [Uniswap governance forum – Temperature Check: Upgrading to a Flexible Voting enabled Governor](https://gov.uniswap.org/t/temperature-check-upgrading-to-a-flexible-voting-enabled-governor/17098), 14 July 2022
- [Arbitrum DAO forum – Arbitrum Governor V2 Review](https://forum.arbitrum.foundation/t/arbitrum-governor-v2-review/26118) (OpenZeppelin's review of ScopeLift's `L2ArbitrumGovernorV2`, 8–19 July 2024) and [Change to New Governance Contracts that Allow Proposal Cancellation](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) (the failed vote, the Offchain Labs five-governor objection, the split, and the February 2026 status)
- [OpenZeppelin docs – Governance](https://docs.openzeppelin.com/contracts/5.x/governance) and the [Governance API reference](https://docs.openzeppelin.com/contracts/5.x/api/governance)

## Snapshot

URL: https://caper.network/wiki/dao-governance/tooling/voting/snapshot
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Category** | Off-chain governance · voting |
| **Launched** | 2020, by Snapshot Labs |
| **What it does** | Gasless off-chain voting via wallet-signed messages stored on IPFS |
| **Scale** | Tens of thousands of governance “spaces” — the de facto DAO voting venue |
| **On-chain arm** | [Snapshot X](https://snapshot.box/) — fully on-chain voting on Starknet & EVM chains |
| **Site** | [snapshot.org](https://snapshot.org/) · [docs](https://docs.snapshot.box/) |
| **Related** | [DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Safe](/wiki/dao-governance/tooling/treasury/safe), [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) |

**Snapshot** is the most widely used voting platform in DAO governance — so ubiquitous that “taking a vote” in most DAOs means opening a Snapshot proposal. Built by Snapshot Labs and launched in 2020, it lets a community poll its token holders **off-chain**: votes are cryptographic messages signed with a member's wallet and stored on [IPFS](https://ipfs.tech/), so voting costs no gas and anyone can verify the tally without trusting the organizers. It is the signaling layer that sits above a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao)'s discussion forum and below its treasury. ([Snapshot docs](https://docs.snapshot.box/))

## How off-chain voting works

A DAO creates a **“space”** — its governance home — and configures a _strategy_ that tells Snapshot how to read voting power (typically the balance of a governance token, snapshotted at a fixed past block so votes cannot be inflated by tokens bought after the proposal opens). Members then vote by signing a structured message; nothing touches the chain, so there is no gas fee and no on-chain footprint. The signed ballots and the final result are pinned to IPFS, making the vote publicly auditable but **non-binding by default** — Snapshot records what the community wants, it does not itself move funds. ([voting guide](https://docs.snapshot.box/user-guides/voting))

## Voting strategies

Snapshot's flexibility comes from its pluggable strategies. A space can weight votes by plain token balance (one-token-one-vote), by [quadratic](https://a16zcrypto.com/posts/article/governance-faq/) rules, by [delegated](https://docs.snapshot.box/user-guides/voting-strategies) power, or by more exotic measures (LP positions, NFT holdings, vote-escrow locks). A _strategy_ is not the same thing as a _voting type_, and Snapshot's documentation is careful to separate them: the strategy computes an individual's voting power, while the type “calculates the outcome of the proposal”. Snapshot ships six types – single choice, weighted, approval, quadratic, ranked choice (instant runoff) and basic ([voting types](https://docs.snapshot.box/proposals/voting-types)) – and which one a space picks changes outcomes rather than presentation; see [ranked and alternative ballot methods](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods). This is why Snapshot underpins so many different [governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) without each DAO needing to write its own tallying code.

## From signaling to execution

Because a Snapshot vote is off-chain, it must be _carried out_ somewhere. The dominant pattern is a two-stage flow: a Snapshot “temperature check” establishes consent cheaply, then the result is executed by a [Safe](/wiki/dao-governance/tooling/treasury/safe) multisig — often wired automatically through [Zodiac / SafeSnap](https://github.com/gnosisguild/zodiac), which lets a passed Snapshot proposal trigger an on-chain transaction under an [optimistic challenge window](/wiki/dao-governance/concepts/voting/optimistic-governance). UMA [retired oSnap](https://docs.uma.xyz/resources/osnap), the other bridge of this shape, on 15 December 2025; the Reality-based route is unaffected. This keeps day-to-day voting gasless while preserving a real on-chain outcome. ([on-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/))

## Snapshot X: on-chain voting

To close the trust gap in that hand-off, Snapshot Labs built **Snapshot X**, a fully on-chain voting protocol that brings proposals, voting-power computation and execution into smart contracts while keeping the familiar Snapshot interface. It runs on [Starknet and EVM chains](https://snapshot.box/) (Ethereum, Optimism, Polygon, Arbitrum) and uses **storage proofs** to verify a voter's token balance trustlessly across chains — pushing computation onto Starknet to make voting and proposing far cheaper than executing the same logic directly on Ethereum L1. ([Snapshot X docs](https://docs.snapshot.box/))

## Strengths and criticisms

Snapshot's strength is friction: free, fast, verifiable polling drove its near-universal adoption. Its most-cited weakness is the flip side — classic off-chain votes are _signaling_, not binding execution, so a DAO still relies on trusted signers (or a SafeSnap-style bridge) to honour the result, and the same low friction that boosts turnout also makes [vote-buying and delegate apathy](https://vitalik.eth.limo/general/2021/08/16/voting3.html) easy. Snapshot also ships one privacy lever, a space-level **shielded voting** setting that encrypts ballots to Shutter's threshold key and reveals them at close; measured across the flagship spaces it is used almost exclusively for elections ([private and shielded voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting)). Snapshot X is the ecosystem's answer to the first critique; the second is inherent to token voting itself.

## How Caper approaches this

Caper collapses the signaling-then-execution split that Snapshot spans. A [Caper proposal](/wiki/governance/proposals) is voted and [executed](/wiki/governance/execution) in one binding on-chain flow — there is no separate off-chain poll to later ratify, and no multisig standing between the vote and the outcome. Weight is read from a past snapshot block, the same defence Snapshot spaces use against last-minute token loading. The trade-off is the mirror image of Snapshot's: Caper gives up gasless convenience to make every vote directly enforceable.

## References

- Snapshot, [Documentation](https://docs.snapshot.box/).
- Snapshot Labs, [Snapshot X](https://snapshot.box/) (on-chain voting protocol).
- Tally, [On-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/).
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/).

## Tally (now Cactus)

URL: https://caper.network/wiki/dao-governance/tooling/voting/tally
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Category** | On-chain governance · [Governor](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) tooling |
| **Launched** | 2020, by Tally (CEO Dennison Bertram) |
| **What it did** | Hosted read / propose / vote / queue / execute interface for OpenZeppelin Governor DAOs |
| **Scale** | Powered on-chain governance for [Uniswap](/wiki/daos/dexs/uniswap-dao), [Arbitrum](/wiki/daos/networks/arbitrum-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Aave](/wiki/daos/lending/aave-dao) and 500+ DAOs |
| **Status** | Hosted product wound down March 2026; platform continued as **Cactus** under [ScopeLift](https://scopelift.co/blog/tally-is-now-cactus) |
| **Site** | [tally.xyz](https://www.tally.xyz/) (now Cactus) · [shutdown notice](https://newsletter.tally.xyz/p/tally-is-shutting-down) |
| **Related** | [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) · [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) · [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) |

**Tally** was, for most of the on-chain-governance era, the place a major DAO went to actually run a vote. Where [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) handled gasless off-chain signaling, Tally was the **binding on-chain** layer: a hosted interface sitting on top of the [OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/5.x/governance) contracts, where a proposal moved from draft to an executed transaction that actually moved the treasury. Launched in 2020 by CEO Dennison Bertram, it powered governance for [Uniswap](/wiki/daos/dexs/uniswap-dao), [Arbitrum](/wiki/daos/networks/arbitrum-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Aave](/wiki/daos/lending/aave-dao) and more than 500 other DAOs. In March 2026 the hosted product [announced it was winding down](https://www.coindesk.com/markets/2026/03/17/gensler-and-biden-were-just-better-for-crypto-says-tally-ceo-as-dao-governance-platform-shuts-down); the platform has since been taken over by [ScopeLift and rebranded Cactus](https://scopelift.co/blog/tally-is-now-cactus).

## What Tally standardized

Tally didn't invent on-chain governance — it made it legible. A Governor DAO's state lives in a contract: who can propose, the voting delay and period, quorum, and a timelock that queues a passed proposal before it can execute. Tally read that state directly from chain and wrapped the whole [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) in one interface — draft a proposal as executable calldata, open it for [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), watch it reach quorum, queue it in the timelock, then trigger the on-chain execution. Because it indexed every [OZ-Governor](https://docs.openzeppelin.com/contracts/5.x/api/governance) deployment the same way, any DAO using the standard contracts got a working governance front-end for free, and delegates got one dashboard across every protocol they participated in.

## Who ran on Tally

The client list read like a census of on-chain governance: [Uniswap](/wiki/daos/dexs/uniswap-dao), [Arbitrum](/wiki/daos/networks/arbitrum-dao) — one of the largest DAO treasuries anywhere — [ENS](/wiki/daos/infrastructure/ens-dao), [Aave](/wiki/daos/lending/aave-dao), ZKsync, and hundreds of smaller protocols. By its own account the platform processed over a billion dollars in on-chain governance transactions across those DAOs. That concentration is exactly why its wind-down mattered: a large slice of the industry's binding governance flowed through one hosted interface.

## The March 2026 wind-down

On 17 March 2026 Tally announced it would [shut the hosted product down](https://newsletter.tally.xyz/p/tally-is-shutting-down) after six years, having scrapped a nearly-complete ICO first. Bertram's reasoning was pointedly counter-intuitive: the regulatory pressure that had made on-chain governance a near-necessity had eased. He argued that the Gensler-era SEC [effectively forced decentralization through legal risk](https://www.coindesk.com/markets/2026/03/17/gensler-and-biden-were-just-better-for-crypto-says-tally-ceo-as-dao-governance-platform-shuts-down), and that a more permissive stance — alongside the 2025 Clarity and stablecoin frameworks — gave projects compliant, centralized paths that no longer required DAO governance as legal cover. Demand for the tooling, in his telling, fell with the pressure that had created it. The episode became a marker of a wider **governance-tooling retrenchment** in 2026, as the sector consolidated toward a handful of professional-governance vendors.

## Continued as Cactus

The story didn't end at shutdown. Engineering studio [ScopeLift took over the platform](https://scopelift.co/blog/tally-is-now-cactus) and relaunched it as **Cactus** — “new name, same platform” — keeping the Governor-indexing interface alive for the DAOs still running binding on-chain votes. The underlying OpenZeppelin Governor contracts were always the DAOs' own on-chain property, unaffected by any front-end changing hands; Tally was the interface, not the governance itself. That distinction is the useful lesson of the whole episode.

## How Caper approaches this

Tally's wind-down is a clean illustration of front-end risk: when a DAO's governance runs through a hosted third-party app, the app is a dependency that can be sold, rebranded, or shut down. [Caper](/wiki/foundations/what-is-a-caper) removes that layer by making governance native to the protocol. A caper's proposals are [created](/wiki/governance/proposals), [voted on](/wiki/governance/voting), and [executed](/wiki/governance/execution) by the caper's _own_ on-chain contract — there is no separate governance company whose survival the members depend on. If every interface to Caper disappeared tomorrow, the proposal and voting logic would still be sitting in the contract, executable directly. Governance you don't have to keep a vendor alive to use is the point.

## References

- Tally, [“Tally Is Shutting Down”](https://newsletter.tally.xyz/p/tally-is-shutting-down) (shutdown announcement).
- CoinDesk, [‘Gensler and Biden were just better for crypto,’ says Tally CEO as DAO governance platform shuts down](https://www.coindesk.com/markets/2026/03/17/gensler-and-biden-were-just-better-for-crypto-says-tally-ceo-as-dao-governance-platform-shuts-down) (17 March 2026).
- ScopeLift, [“Goodbye Tally, Hello Cactus”](https://scopelift.co/blog/tally-is-now-cactus) (platform continuation).
- OpenZeppelin, [Governor documentation](https://docs.openzeppelin.com/contracts/5.x/governance).
- Tally / Cactus, [tally.xyz](https://www.tally.xyz/).

## 1inch DAO (1INCH)

URL: https://caper.network/wiki/daos/dexs/1inch-dao
Updated: 2026-07-25

| Organization | 1inch DAO |
| --- | --- |
| Type | DEX aggregator & intent-settlement protocol |
| Token | 1INCH (governance + staking) |
| Chains | Ethereum + 10+ EVM networks (Aggregation / Limit Order / Fusion) |
| Governance | [1inch.eth Snapshot](https://snapshot.org/#/1inch.eth), weighted by Unicorn Power |
| Founded | 2019 (ETHGlobal New York hackathon) |
| Status | 🟢 Active |
| Website | [1inch.io](https://1inch.io) |

## Overview

The **1inch Network** is a decentralized-exchange _aggregator_: rather than running a single [automated market maker](/wiki/daos/dexs), it routes each trade across many liquidity sources to find the best execution. Its [Aggregation Protocol](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility) (the Pathfinder routing algorithm), a gas-efficient Limit Order Protocol, and the intent-based **Fusion** mode are governed by the **1inch DAO** through the [1inch.eth Snapshot space](https://snapshot.org/#/1inch.eth). This makes 1inch a distinct archetype in the DAO directory: where [Uniswap](/wiki/daos/dexs/uniswap-dao), [Curve](/wiki/daos/dexs/curve-dao), and [Balancer](/wiki/daos/dexs/balancer-dao) govern the pools that _hold_ liquidity, 1inch governs the layer that _routes across_ them, closer in shape to intent/solver DAOs like [CoW DAO](/wiki/daos/dexs/cow-dao) and the Solana aggregator [Jupiter](/wiki/daos/dexs/jupiter).

## Origins: a 60-hour hackathon

1inch began at the [ETHGlobal New York hackathon in May 2019](https://gitcoin.co/case-studies/1inch-from-hackathon-to-decentralized-exchange-powerhouse), where [Sergej Kunz](https://1inch.com/blog/post/meet-1inch-team-sergej-kunz) (now CEO) and [Anton Bukov](https://1inch.com/blog/post/meet-1inch-team-anton-bukov-co-founder-and-cto) (now CTO) – competing as the "CryptoManiacs" team – built a working aggregator prototype over roughly 60 hours. The protocol has since routed [over $450 billion](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility) in cumulative volume across more than ten EVM networks.

## The 1INCH token

The [1INCH governance and utility token](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility) launched on **25 December 2020** with a maximum supply of **1.5 billion**. On **6 April 2022** the token's mint function was permanently burned, fixing the cap so no further 1INCH can ever be created. The token is distributed across community airdrops, liquidity incentives, the team, investors, and a long-term treasury.

## Unicorn Power: staking with decay

Raw 1INCH balances do not vote. To gain governance weight a holder deposits 1INCH into a time-locked staking contract and receives **st1INCH** and **Unicorn Power (UP)** – [the unit of influence in the 1inch DAO](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility). The UP granted scales with both the amount staked and the lock duration (up to two years), and it **decays over time** as the lock unwinds, so sustained influence requires an active, renewed commitment rather than a one-time purchase. On-chain governance parameters set a [proposal-submission threshold of 100,000 UP, a quorum of 10,000,000 UP, and a five-day voting window](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility) for standard proposals.

## Two independent delegations

1inch's most distinctive design is that Unicorn Power can be delegated down _two separate rails that operate independently_:

- **Governance delegation** – UP delegated to a [Snapshot delegate](https://snapshot.org/#/1inch.eth) who votes on protocol decisions on the holder's behalf, a form of [vote-lock](/wiki/daos/dexs/curve-dao) representation comparable to [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow) systems.
- **Economic delegation** – the [same UP delegated to a Fusion resolver](https://1inch.com/blog/post/staking-1inch-and-delegating-unicorn-power-a-source-of-rewards-127183a578d9): professional market makers who settle [Fusion](https://help.1inch.com/en/articles/6796085-what-is-1inch-fusion-and-how-does-it-work) orders through gasless Dutch auctions. Resolvers compete for delegated UP, and stakers earn a share of the resolvers' arbitrage profits.

The split means the token doubles as a governance right _and_ a yield-bearing stake in the network's market-making layer – a holder can lend their voice to a delegate and their economic weight to a resolver at the same time.

## What the DAO controls

Through Snapshot votes weighted by Unicorn Power, 1INCH stakers hold direct authority over [network governance, the DAO treasury, and the parameters of the Fusion Mode Settlement Contract](https://1inch.com/blog/post/1inch-token-pioneering-defi-governance-and-utility) – the contract that clears resolver-settled trades. Treasury management and the calibration of Fusion's fee and auction parameters are therefore live governance questions rather than founder prerogatives.

## How Caper approaches this

1inch shows a deliberate split between _governance weight_ (Unicorn Power for voting) and _economic delegation_ (Unicorn Power lent to resolvers for yield), with influence that decays unless a holder keeps re-locking. [Caper](/wiki/foundations/what-is-a-caper) folds those into a single canonical number: a member's vote weight is `(t · v) / (V · T)` – their token holdings _t_ multiplied by their accumulated voting history _v_, over the totals. Holdings are one factor, not the whole story, so a large bag alone cannot capture [control](/wiki/governance) without a matching record of showing up to vote. And where 1inch stakers must wait out a time-lock, Caper pairs weight with an [exit right](/wiki/markets): a member can always leave with their proportional share of the treasury rather than being locked in to a decision they lost.

## Aerodrome Finance

URL: https://caper.network/wiki/daos/dexs/aerodrome-finance
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Project** | Aerodrome Finance — Base's primary liquidity marketplace |
| **Model** | ve(3,3) DEX in the Solidly lineage (AMM + vote-escrow + gauge-directed emissions) |
| **Chain** | Base (Coinbase's Ethereum L2) |
| **Launched** | August 2023, by the team behind [Velodrome](https://velodrome.finance/) (now [Dromos Labs](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero)) |
| **Token** | AERO (ERC-20) → lock up to four years for **veAERO**, a transferable voting NFT |
| **Emissions control** | Weekly gauge voting; voters take 100% of trading fees and incentives from the pools they back |
| **2026 turn** | Merging with Velodrome into a cross-chain DEX, "Aero" — announced, not yet launched as of 31 July 2026 |
| **On Caper** | Participation is earned and _soulbound_ — the opposite of a sellable vote-lock |
| **Related** | [Curve](/wiki/daos/dexs/curve-dao), [Convex](/wiki/daos/lending/convex-finance), [Balancer](/wiki/daos/dexs/balancer-dao), [Pendle](/wiki/daos/lending/pendle-finance), [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) |

**Aerodrome Finance** is the dominant decentralized exchange on [Base](https://www.base.org/), Coinbase's Ethereum layer-2, and one of the clearest live examples of the **ve(3,3)** governance model still running at scale. It launched in [August 2023](https://blockworks.com/insights/aerodrome-finance), built by the team behind Optimism's Velodrome, who had [re-engineered Solidly](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base) — Andre Cronje's original ve(3,3) design — into a "meta" DEX that stitches together the liquidity structures of Uniswap V2, Curve, Uniswap V3, and Convex's incentive model. Where most DAOs in this directory bolt governance onto a protocol, Aerodrome makes governance the protocol: who votes, and how, directly decides where the exchange's liquidity flows each week.

## The ve(3,3) engine: lock, vote, earn

Aerodrome's design is a tight loop. The AERO token is a reward emitted to liquidity providers, but its primary purpose is to be _locked_: lock AERO for up to four years and you receive **veAERO**, a voting NFT whose weight scales with how much you locked and for how long ([Blockworks](https://blockworks.com/insights/aerodrome-finance)). Each week — an **epoch** — veAERO holders vote on **gauges**, choosing which liquidity pools receive the following week's AERO emissions. A pool that wins 10% of the vote gets 10% of that epoch's emissions, deepening its liquidity ([CoinGecko](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base)).

The incentive that makes the loop turn is where the fees go. Aerodrome routes **100% of trading fees and 100% of external incentives** ("bribes") to the veAERO holders who voted for each pool, in proportion to their share of that pool's vote — not to passive LPs ([CoinGecko](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base)). A voter is therefore paid to direct emissions toward the pools that will generate the most fees, which is the same self-interested gauge dynamic that produced the [Curve Wars](/wiki/daos/dexs/curve-dao) and the [vlCVX vote markets](/wiki/daos/lending/convex-finance) — carried onto Base, one chain removed.

## A vote-lock you can sell

One design choice sets Aerodrome apart from Curve's original template, and it matters for governance. veCRV is _non-transferable_ — a permanent, illiquid commitment. veAERO is a **transferable NFT that can be sold on NFT marketplaces** ([CoinGecko](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base)). That makes the locked voting position itself a tradable asset: a buyer can acquire another holder's remaining lock — and its accrued voting power and fee stream — without ever locking their own capital for the term. It is a pragmatic fix for the illiquidity that made veCRV so sticky, but it also means **vote weight has a spot price**. Governance influence that can be bought outright, rather than only earned by locking, is exactly the [capital-priced control](/wiki/dao-governance/concepts/voting/token-weighted-voting) that [governance-capture post-mortems](/wiki/dao-governance/concepts/analysis/how-daos-fail) keep returning to.

## Slipstream and the meta-DEX

Aerodrome did not stay a Solidly clone. In 2024 it shipped **Slipstream**, a concentrated-liquidity module [closely derived from Uniswap V3](https://blockworks.com/insights/aerodrome-finance), layered on top of the ve(3,3) gauge system so that concentrated pools compete for emissions the same way constant-product pools do. Slipstream now [dominates the stack almost entirely](https://blockworks.com/insights/aerodrome-finance), with the original V2-style AMM reduced to a thin sliver of activity. The combination — Uniswap-style concentrated liquidity, Curve-style stable pools, and a vote-escrow incentive layer over all of it — is what Aerodrome means by a "meta" DEX ([CoinGecko](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base)).

## Scale on Base

The model made Aerodrome the center of gravity for Base liquidity. By a recent epoch it processed [roughly $2.84 billion in trading volume in a single week — about 57% of all DEX volume on Base](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base). Total value locked has swung with the market: Blockworks records a [peak near $880 million in December 2024](https://blockworks.com/insights/aerodrome-finance) and cumulative protocol fees since launch [above $322 million](https://blockworks.com/insights/aerodrome-finance), while at the time of the 2026 merger announcement The Defiant put Aerodrome at [$475.9 million in TVL](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero) — dwarfing Velodrome's ~$39 million on Optimism. As with every DAO in this directory, treat any single dollar figure as a moving, price-driven snapshot and read the live value from [DeFiLlama](https://defillama.com/protocol/aerodrome).

## 2026: the merger into Aero

Aerodrome's governance is now steering its biggest change. [Dromos Labs](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero) — the studio behind both DEXs, led by founder and CEO Alexander Cutler — is merging Aerodrome and Velodrome into a single cross-chain protocol called **Aero**, with a new AERO token replacing VELO and unifying liquidity [across every chain both currently run on, plus Ethereum mainnet and Circle's Arc](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero). The relaunch, targeted for [July 2026](https://phemex.com/news/article/aerodrome-finance-prepares-for-aero-launch-with-major-platform-upgrades-84689), ships an operating system Dromos calls METADEX03, whose headline pieces are [Slipstream V3 — which aims to recapture value normally lost to arbitrage bots — and MetaSwaps for cross-chain trading from one interface](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero), alongside a migration to [MEV-resistant pools](https://phemex.com/news/article/aerodrome-finance-prepares-for-aero-launch-with-major-platform-upgrades-84689) — a design goal that sits squarely inside the wider problem of [MEV and value extraction](/wiki/economics/mev-and-value-extraction). That target has slipped: as of 31 July 2026 Aero has not launched, and the project's own site commits only to arriving [“in 2026”](https://aero.xyz/).

That site is also the clearest statement so far of what the merged protocol will pay for, and it reads differently from the DEX it replaces. Aero promises a **“zero-leak economy”**: 100% of exchange revenue streamed to AERO stakers, no private token sales, and every party earning through participation — across a connected set now named as Base, Ethereum mainnet, Optimism, Arbitrum, Celo, Ink, Soneium, Unichain, Fraxtal and Tea ([aero.xyz](https://aero.xyz/)). The wording matters for governance: it describes holders who _stake_ AERO to coordinate where liquidity flows, not holders who lock it for up to four years into a transferable veAERO NFT, and it does not say whether the existing lock terms survive the migration. For anyone holding a veAERO position, that is the consequential unanswered question. Dromos has meanwhile begun trailing a further primitive, **Predictive Allocation**, billed as a new on-chain mechanism shipping live with Aero ([Aerodrome, 31 July 2026](https://x.com/AerodromeFi/status/2083283195144081461)).

It is a telling counterpoint to the wider [post-ve turn](/wiki/daos/lending/pendle-finance). Where Balancer deprecated veBAL and Pendle retired vePENDLE, Aerodrome is the ve(3,3) fork that kept the lock-vote-earn model, became its chain's dominant venue, and is now consolidating a second one under it — a live bet that the model's problem was fragmentation and value leakage, not vote-escrow itself.

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-caper) starts from the opposite premise about what should carry a vote. In the ve model, influence is bought with locked capital — lock more AERO, or lock it longer, and your veAERO weight rises — and because that veAERO position is itself transferable, voting power ends up with a spot price. On Caper, weight is the product of two factors, `w = (t · v) / (V · T)`: the governance stake a member holds _and_ the participation they have actually shown, the latter minted one non-transferable token per vote. Those participation tokens are [soulbound](/wiki/governance/voting) — indivisible, and never sold or lent — so a member's first vote counts for nothing and freshly-arrived or borrowed capital has almost nothing to grip. There is no lock to buy and no vote-NFT to trade: standing accrues only to members who keep showing up.

The same earned standing then sets each member's pro-rata claim on the treasury at [exit](/wiki/governance/execution), so **voice and exit are the same number**. A member who disagrees with the direction leaves with their fair share rather than quietly [abandoning](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) the organization — the outcome a rentable, sellable vote-lock cannot guarantee. Caper is a general DAO framework, not a DEX; the contrast is only in what governance is priced on: earned participation you cannot buy, versus locked capital you can.

## Sources

- CoinGecko, [What Is Aerodrome Finance? Ultimate Guide to Base's Principal DEX](https://www.coingecko.com/learn/what-is-aerodrome-finance-aero-base).
- Blockworks, [Aerodrome Finance: Data Dashboard Primer](https://blockworks.com/insights/aerodrome-finance).
- The Defiant, [Dromos Labs Merges Aerodrome and Velodrome into New DEX Aero](https://thedefiant.io/news/defi/dromos-labs-merges-aerodrome-and-velodrome-into-new-dex-aero).
- Phemex News, [Aerodrome Finance Upgrades for July 2026 Aero Launch](https://phemex.com/news/article/aerodrome-finance-prepares-for-aero-launch-with-major-platform-upgrades-84689).
- Aero, [aero.xyz](https://aero.xyz/) — the merged protocol's own pre-launch site (economics, connected chains, launch timing).
- [DeFiLlama — Aerodrome protocol (live TVL, fees, volume)](https://defillama.com/protocol/aerodrome).

## Balancer DAO

URL: https://caper.network/wiki/daos/dexs/balancer-dao
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Name** | Balancer DAO |
| **Type** | Protocol DAO (DeFi — programmable automated market maker / DEX, multi-chain) |
| **Governance token** | BAL — [100,000,000 max supply](https://docs.balancer.fi/concepts/governance/bal-token.html) (launched 20 June 2020) |
| **Governance model** | Was [vote-escrow](/wiki/dao-governance/concepts/treasury/dao-tokenomics) ([veBAL](https://docs.balancer.fi/concepts/governance/veBAL/), a [veCRV](/wiki/daos/dexs/curve-dao)-derived model, launched 28 March 2022); [reconfigured to raw-BAL 1-token-1-vote](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052) on [Snapshot](https://snapshot.org/#/balancer.eth) in Q2 2026 |
| **Products** | Balancer v2 / v3 AMM · weighted & boosted pools · the Vault architecture |
| **Notable for** | The 80/20 veBAL lock and gauge-vote-market; the [November 2025 $128M v2 exploit](https://research.checkpoint.com/2025/how-an-attacker-drained-128m-from-balancer-through-rounding-error-exploitation/); the 2026 wind-down of both Balancer Labs and the ve-model itself |
| **Primary sources** | [balancer.fi](https://balancer.fi/), [docs.balancer.fi](https://docs.balancer.fi/), [forum.balancer.fi](https://forum.balancer.fi/), [Snapshot (balancer.eth)](https://snapshot.org/#/balancer.eth), [github.com/balancer](https://github.com/balancer) |
| **Related** | [Curve DAO](/wiki/daos/dexs/curve-dao), [Aave DAO](/wiki/daos/lending/aave-dao), [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

**Balancer DAO** governs [Balancer](https://balancer.fi/), a decentralized exchange built as a _programmable_ automated market maker: instead of the fixed 50/50 pools of a Uniswap, Balancer pools can hold up to eight assets in arbitrary weights, which makes them double as self-rebalancing index funds. Its [Vault](https://docs.balancer.fi/concepts/vault/) architecture — one contract that holds all pool assets and nets transfers across them — became one of the most-forked designs in DeFi. But Balancer's real significance to DAO governance is its adoption, and eventual _abandonment_, of the [vote-escrow (ve) model](/wiki/daos/dexs/curve-dao): it is the clearest case study of a flagship protocol locking its token for governance, running that system for four years, and then unwinding it in the open. ([BAL token docs](https://docs.balancer.fi/concepts/governance/bal-token.html))

## veBAL — the 80/20 vote-escrow lock

BAL launched in June 2020 with a fixed [100M maximum supply](https://docs.balancer.fi/concepts/governance/bal-token.html), but liquid BAL never carried governance weight. In March 2022 Balancer adopted [the veModel](https://medium.com/balancer-protocol/unlocking-the-vemodel-f363d2d7bd91), a direct descendant of [Curve's veCRV](/wiki/daos/dexs/curve-dao), with one distinctive twist: you did not lock BAL itself. You locked an **80/20 BAL/WETH** [Balancer Pool Token (BPT)](https://docs.balancer.fi/concepts/governance/veBAL/) — a liquidity position that is itself 80% BAL — for up to **one year**, and received non-transferable **veBAL** whose weight scaled with lock length and decayed toward the unlock date. Locking the LP token rather than the bare asset meant governance participants were also providing protocol liquidity, not just idling tokens in an escrow.

veBAL bundled the same three rights the ve-model everywhere offers: a vote on protocol [proposals](/wiki/dao-governance/concepts/voting/proposal-lifecycle), a share of protocol fees, and — the load-bearing one — a weekly vote on **gauge weights** that decided how BAL emissions were split across pools. As with [Curve](/wiki/daos/dexs/curve-dao), that gauge vote created a market: [Aura Finance](https://aura.finance/) rose as an aggregation layer (Balancer's [Convex](/wiki/dao-governance/concepts/voting/token-weighted-voting)), accumulating veBAL and renting out its emission-steering power to projects that wanted deep liquidity. The [vote-market dynamic](/wiki/dao-governance/concepts/voting/token-weighted-voting) the Curve Wars made famous replayed on Balancer.

## November 2025 — the $128M v2 exploit

On **3 November 2025** Balancer suffered one of the largest DeFi exploits of the year: an attacker drained roughly **$128 million** from Balancer v2 pools across six chains — Ethereum, Base, Polygon, Arbitrum and others — [in under 30 minutes](https://research.checkpoint.com/2025/how-an-attacker-drained-128m-from-balancer-through-rounding-error-exploitation/). The bug was not a stolen key or a governance takeover but an **arithmetic precision error**: a rounding flaw in the Vault's `_upscaleArray` scaling logic, which — chained through dozens of tiny crafted `batchSwap` operations executed inside a contract constructor — let the attacker suppress [BPT](https://docs.balancer.fi/concepts/vault/) prices and repeatedly extract value. It is a textbook entry for the [DAO security and governance-attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) page: the DAO's votes worked fine; the loss came from a subtle invariant-math bug in audited, years-old code. ([Check Point Research analysis](https://research.checkpoint.com/2025/how-an-attacker-drained-128m-from-balancer-through-rounding-error-exploitation/))

## 2026 — Balancer Labs winds down, and so does veBAL

The exploit's fallout reshaped the whole project. In [March 2026](https://www.coindesk.com/tech/2026/03/24/balancer-labs-will-shut-down-as-corporate-entity-became-a-liability-after-usd110-million-exploit) the founding company, **Balancer Labs**, announced it was dissolving its corporate entity — a co-founder wrote that after the exploit the entity "became a liability" — while the protocol itself stayed live under DAO stewardship. That forced the DAO to confront a question every [maturing DAO](/wiki/dao-governance/concepts/analysis/how-daos-fail) eventually faces: is the emission-subsidised ve-machine still worth its overhead once the growth phase is over?

Its answer, ratified in Q2 2026, was to dismantle it:

- [BIP-919 (BAL Tokenomics Revamp)](https://forum.balancer.fi/t/bip-919-bal-tokenomics-revamp/7001) — end all new BAL emissions, lift the LP share of swap fees from 50% to 75%, and route 100% of protocol fees to the [DAO treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management). With no emissions left, the gauge system had nothing to steer.
- [BIP-920 (veBAL Compensation Airdrop)](https://forum.balancer.fi/t/bip-920-vebal-compensation-airdrop/7025) — a **500,000 USDC** airdrop to veBAL lockers, compensation for locked positions that would no longer earn incentives.
- [BIP-921 (1-BAL-1-vote)](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052) — replace the two veBAL Snapshot strategies with a seven-strategy stack counting **raw BAL** across every production chain: no lockup, no decay. Governance reverted to plain [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting).

The arc is the lesson. The ve-lock was adopted to bind control to long-term commitment; four years on, with emissions gone and the vote-market's overhead exposed, Balancer judged the lock no longer paid for itself and returned to the [one-token-one-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) model the lock was invented to escape.

Balancer was not alone. Months later [Pendle](/wiki/daos/lending/pendle-finance) retired its own **vePENDLE** gauge system for a liquid staking token (sPENDLE) plus algorithmic emissions — the same finding, that the ve-lock concentrated power in a rentable few while most holders sat out, reached independently by another of the model's biggest adopters.

## How Caper approaches this

Balancer's ve-experiment ran the full loop: lock the token to couple influence to commitment, watch an [aggregator](https://aura.finance/) tokenise and rent that locked power, then — once emissions stopped justifying the machinery — unwind the whole thing back to plutocratic [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting). A [caper](/wiki/foundations/what-is-a-caper) reaches for the same goal the lock was after — influence tied to genuine stake — but without a lock to tokenise or a gauge to fight over. Its [voting weight](/wiki/governance/voting) `(t·v)/(V·T)` combines the tokens a member _holds_ with the votes they have _earned_ through participation, so a large position alone cannot capture control and there is no locked receipt for a third party to aggregate and sell. There are also no emissions: a caper's tokens are minted along a [bonding curve](/wiki/markets/bonding-curve), not a weekly inflation vote, so there is no emission stream for a "war" to capture in the first place. And because that same earned weight is each member's [pro-rata exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on the treasury, control stays coupled to real economic exposure rather than to whoever locked the most this cycle. This is a design contrast, not a claim of superiority — the mechanics are on the [linked pages](/wiki/governance/voting) and verified against the caper contract source.

## References

- [Balancer docs — BAL token](https://docs.balancer.fi/concepts/governance/bal-token.html) and [veBAL](https://docs.balancer.fi/concepts/governance/veBAL/) (primary).
- Balancer Labs, [Unlocking the veModel](https://medium.com/balancer-protocol/unlocking-the-vemodel-f363d2d7bd91) — the 2022 veBAL launch rationale (primary).
- [BIP-919](https://forum.balancer.fi/t/bip-919-bal-tokenomics-revamp/7001), [BIP-920](https://forum.balancer.fi/t/bip-920-vebal-compensation-airdrop/7025), [BIP-921](https://forum.balancer.fi/t/bip-921-1-bal-1-vote-reconfiguration-for-balancer-eth-snapshot-space/7052) — the 2026 tokenomics revamp and veBAL deprecation, on the [Balancer governance forum](https://forum.balancer.fi/) (primary).
- Check Point Research, [How an attacker drained $128M from Balancer](https://research.checkpoint.com/2025/how-an-attacker-drained-128m-from-balancer-through-rounding-error-exploitation/) (November 2025).
- CoinDesk, [Balancer Labs to shut down after exploit](https://www.coindesk.com/tech/2026/03/24/balancer-labs-will-shut-down-as-corporate-entity-became-a-liability-after-usd110-million-exploit) (March 2026).

## CoW DAO

URL: https://caper.network/wiki/daos/dexs/cow-dao
Updated: 2026-07-31

|  |  |
| --- | --- |
| **Name** | CoW DAO |
| **Type** | Protocol DAO governing CoW Protocol — an intent-based, MEV-protecting trading protocol (Ethereum) |
| **Origin** | Incubated inside [GnosisDAO](/wiki/daos/networks/gnosisdao); spun out via [GIP-13 (Phase 2)](https://forum.gnosis.io/t/gip-13-phase-2-cowdao-and-cow-token/2735) with a [$23M funding round](https://www.theblock.co/linked/139692/cow-protocol-raises-23-million-and-spins-out-from-gnosis-dao) (January 2022) |
| **Token** | COW — 1,000,000,000 fixed supply, [≤3% max annual inflation](https://docs.cow.fi/governance/token), changeable only once per 365 days |
| **Treasury share** | 44.4% of COW held by the CoW DAO treasury; 10% to [GnosisDAO](/wiki/daos/networks/gnosisdao), 15% team, 10% [community airdrop](https://blog.cow.fi/cowdao-closes-a-23m-investment-round-9b841abcdbbe) |
| **Governance** | [CoWmunity forum](https://forum.cow.fi/) → CoW Improvement Proposals (CIPs) → gas-free [Snapshot](https://snapshot.org/#/cow.eth) vote |
| **Products** | [CoW Swap](https://cow.fi/) (intent-based batch-auction DEX), CoW AMM, MEV Blocker |
| **Contract** | [gnosis/cow-token](https://github.com/gnosis/cow-token) (COW / vCOW) |

**CoW DAO** is the community that governs [CoW Protocol](https://cow.fi/), a trading protocol built around _intents_ rather than direct swaps. It is one of the cleanest examples of [GnosisDAO](/wiki/daos/networks/gnosisdao)'s "on-chain holding company" pattern: CoW (originally "CowSwap") began as an internal Gnosis experiment, then graduated into a standalone project with its own token and treasury via [GIP-13 (Phase 2)](https://forum.gnosis.io/t/gip-13-phase-2-cowdao-and-cow-token/2735) and a [$23M round](https://www.theblock.co/linked/139692/cow-protocol-raises-23-million-and-spins-out-from-gnosis-dao) in January 2022. The name is a pun on _Coincidence of Wants_ — when two traders want opposite sides of the same trade, they can be matched directly against each other instead of both paying an AMM.

## Intents and batch auctions

Most DEXs execute one swap at a time against a liquidity pool, which exposes every trade to [MEV](https://ethereum.org/developers/docs/mev/) — front-running, sandwiching, and priority-gas auctions that quietly tax the trader. CoW Protocol restructures this. A user signs an _intent_ ("I want at least X of token B for my token A") rather than a transaction, and intents are collected into discrete **batch auctions**. Independent third parties called _solvers_ then compete to settle each batch: they net off any [coincidences of wants](https://docs.cow.fi/) peer-to-peer, route the remainder across on-chain liquidity, and the winning solver is the one that returns the most surplus to users. Every trade in a batch clears at the same [uniform price](https://docs.cow.fi/cow-protocol/concepts/introduction/fair-combinatorial-auction), which removes the ordering advantage MEV bots rely on. The protocol also ships [CoW AMM](https://cow.fi/cow-amm), a liquidity-provision design that protects LPs from loss-versus-rebalancing, and [MEV Blocker](https://mevblocker.io/), an RPC endpoint that shields ordinary wallets from sandwich attacks. The same intent-and-solver shape appears in the [1inch DAO](/wiki/daos/dexs/1inch-dao)'s Fusion mode, where competing resolvers settle gasless orders through Dutch auctions.

## Governance: COW, CIPs, and Snapshot

CoW DAO controls the protocol treasury — **44.4%** of the [one-billion fixed COW supply](https://docs.cow.fi/governance/token) — plus solver approvals, fee parameters, and grants. Governance follows the same optimistic pattern its parent [GnosisDAO](/wiki/daos/networks/gnosisdao) pioneered: ideas are debated as **CoW Improvement Proposals (CIPs)** on the [CoWmunity forum](https://forum.cow.fi/), then ratified by a gas-free [Snapshot](https://snapshot.org/#/cow.eth) vote — [off-chain signalling](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) that costs holders nothing. Team and investor allocations were issued as non-transferable **vCOW** that [vests linearly over four years](https://docs.cow.fi/governance/token) and converts 1:1 to COW, aligning insiders to the long term. Because 10% of supply sits with GnosisDAO, the two DAOs remain economically intertwined — a recurring feature of the [spun-out-subsidiary](/wiki/dao-governance/concepts/treasury/dao-treasury-management) model.

## The cow.fi domain hijack and CIP-86 (2026)

On **14 April 2026** CoW Protocol's domain registrar (Gandi) was [compromised via social engineering](https://ambcrypto.com/cow-dao-approves-voluntary-refunds-despite-no-protocol-breach-in-domain-hijack/), letting attackers hijack DNS for the `cow.fi` domain for roughly 4.5 hours and serve a phishing UI that drained wallets of an estimated ~$1.2M. The protocol's smart contracts were never breached — the failure was entirely at the Web2 edge. What happened next is the governance story worth studying: rather than disclaim responsibility for an off-chain attack, the DAO passed [CIP-86](https://forum.cow.fi/t/cip-86-discretionary-grants-program-for-victims-of-the-cow-fi-domain-hijacking/3431), a [discretionary grants program](https://crypto.news/cow-dao-approves-compensation-for-cow-fi-hijack-victims-claims-due-may-14/) reimbursing eligible phished users up to 100% of losses from the treasury. The DAO was explicit that the payments were voluntary "goodwill" grants, not an admission of legal liability — a deliberate framing that let a treasury-funded reimbursement pass [on Snapshot](https://www.cryptotimes.io/2026/05/12/cip-86-passed-cow-dao-begins-compensation-for-april-attack/) without setting a liability precedent. It is a clean example of a DAO treating its treasury as a stakeholder-protection backstop.

## How Caper approaches this

CoW DAO's CIP-86 vote is a reminder of what a treasury is _for_ — a shared pool that can be deployed to protect the people who make the protocol valuable. But reaching it required a bespoke proposal, a Snapshot quorum, and a discretionary grants process stood up after the fact. [Caper](/wiki/foundations/what-is-a-caper) bakes the members-first claim on the treasury into the protocol itself: every caper's `exit()` lets a member redeem a pro-rata slice of the treasury at any time, with no proposal or quorum, and that redemption share equals their exact [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — the influence you hold and the value you can walk away with are the same number. Where CoW DAO had to _vote_ its treasury into acting for members, Caper makes the members' standing claim a protocol default. (Caper does not attempt CoW's intent-based trade execution — the parallel is purely about treasury governance.)

## Curve DAO

URL: https://caper.network/wiki/daos/dexs/curve-dao
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Name** | Curve DAO |
| **Type** | Protocol DAO (DeFi — stablecoin exchange + lending) |
| **Governance token** | CRV, vote-escrowed as **veCRV** (non-transferable) |
| **Governance model** | [Vote-escrow](/wiki/dao-governance/concepts/treasury/dao-tokenomics): lock CRV up to 4 years for time-decaying voting power; Aragon-based DAO; weekly gauge-weight votes set CRV emissions |
| **Products** | StableSwap AMM · crvUSD stablecoin (2023) · LlamaLend lending |
| **Notable for** | Pioneered vote-escrow (ve) tokenomics; the **"Curve Wars"**; one of the longest-lived Aragon DAOs |
| **Primary sources** | [curve.finance](https://curve.finance/), [curve.readthedocs.io](https://curve.readthedocs.io/dao-vecrv.html), [gov.curve.fi](https://gov.curve.finance/), [curve-dao-contracts](https://github.com/curvefi/curve-dao-contracts) |
| **Related** | [Uniswap DAO](/wiki/daos/dexs/uniswap-dao), [Aave DAO](/wiki/daos/lending/aave-dao), [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) |

The **Curve DAO** governs [Curve Finance](https://curve.finance/), a decentralized exchange specialised in low-slippage swaps between like-priced assets (stablecoins, staked-ETH pairs) and, since 2023, an issuer of the **crvUSD** stablecoin. Curve matters to DAO governance out of all proportion to its size because of _how_ it is governed: it introduced **vote-escrowed tokenomics (veCRV)**, the design that most later DeFi protocols copied, and it became the arena for the **"Curve Wars"** — the clearest real-world demonstration of how token-based voting power becomes a market to be bought. ([Curve DAO docs](https://curve.readthedocs.io/dao-vecrv.html))

## veCRV — the vote-escrow model

Curve does not let you vote with liquid **CRV**. To gain governance power you must **lock** CRV in the [VotingEscrow](https://curve.readthedocs.io/dao-vecrv.html) contract for a fixed term of up to **four years**, receiving non-transferable **veCRV** in return. Voting power scales with lock length and **decays linearly** as the unlock date approaches, so influence must be continually renewed. Locking buys three things at once: governance votes, a share of protocol trading fees, and a **boost of up to 2.5×** on the CRV rewards your own liquidity positions earn.

The point of the lock is to _couple control to commitment_: a veCRV holder cannot vote and immediately sell, so voting weight is tied to a multi-year stake rather than to whoever happens to hold tokens at a snapshot. This is the ve model's answer to the [plutocracy and vote-renting problems](/wiki/dao-governance/concepts/voting/token-weighted-voting) of plain token voting, and it was influential enough that "ve-tokenomics" became a [category of its own](/wiki/dao-governance/concepts/voting/vote-escrow) across DeFi (see [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics)) — later protocols copied it directly — [Yearn's veYFI](/wiki/daos/lending/yearn-finance) and [Frax's veFXS](/wiki/daos/stablecoins/frax-finance) among them — and its most prominent fork, [Balancer's veBAL](/wiki/daos/dexs/balancer-dao), ran the same 80/20-lock playbook before [deprecating it entirely in 2026](/wiki/daos/dexs/balancer-dao). ([curve-dao-contracts](https://github.com/curvefi/curve-dao-contracts))

## Gauge weights and the Curve Wars

veCRV holders do more than pass proposals — each week they vote on **gauge weights**, which decide how Curve's ongoing **CRV emissions** are split across liquidity pools. Directing emissions to a pool deepens its liquidity, so any protocol that wants cheap, deep liquidity for its own token has a direct incentive to control veCRV. That incentive produced the **"Curve Wars."**

Rather than each protocol locking CRV itself, [Convex Finance](https://www.convexfinance.com/) emerged as an aggregation layer: deposit CRV with Convex, it locks the maximum term on your behalf and hands back a liquid receipt, and [Convex](/wiki/daos/lending/convex-finance) votes the accumulated veCRV as a bloc. Within months Convex controlled **more than half of all veCRV**, becoming the effective power broker of Curve governance. **It still is.** At Ethereum block 25,716,457 (9 August 2026) the Convex voter proxy held 419,428,844 veCRV of a 781,351,819 total — **53.68%** — while holding only 49.78% of the CRV actually locked in the escrow. The gap is decay: every other lock runs down toward its unlock date, and Convex's is re-locked to the four-year maximum, currently 25 July 2030. The full on-chain read, including the CVX mint reaching its final cliff, is on the [Convex Finance](/wiki/daos/lending/convex-finance) page. On top of that grew an open **bribe market** (Votium and others) where projects pay veCRV/vlCVX voters directly to steer emissions — turning voting power into a rentable yield. Major protocols ran their own strategies here too — [Frax](/wiki/daos/stablecoins/frax-finance) amassed one of the largest vlCVX positions to steer Curve emissions toward its own pools. The template also travelled: the Solidly ve(3,3) fork of this gauge-and-bribe design became the dominant DEX on the OP-stack chains, most prominently [Aerodrome](/wiki/daos/dexs/aerodrome-finance) on Base. The Curve Wars are the canonical case study for the lesson on the [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) page: even a lock-based system can have its votes bought, the leak just moves to a new place. ([Curve governance forum](https://gov.curve.finance/))

The amplification coefficient those votes sit alongside is not only an economic parameter. Curve's `ramp_A` moves it over a rate-limited window because the invariant a trade is priced against is solved by iteration rather than by formula – see [Numerical pricing in AMMs and bonding curves](/wiki/economics/numerical-pricing).

## crvUSD, and the 2023–2024 stress tests

In 2023 Curve launched **crvUSD**, an over-collateralized stablecoin with a novel "soft liquidation" mechanism (LLAMMA) that partially converts collateral instead of liquidating it all at once, plus the **LlamaLend** lending markets built on the same engine. The same period exposed Curve's risks in public:

- **July 2023 — the Vyper exploit.** A reentrancy-lock bug in specific versions of the [Vyper](https://vyper.readthedocs.io/) compiler (0.2.15, 0.2.16, 0.3.0) — not in Curve's own logic — let attackers drain several Curve pools for a cumulative **$60M+**. A large share was ultimately returned by white-hats and the attackers, but it was a systemic scare for the whole Vyper-based ecosystem. ([Halborn post-mortem](https://www.halborn.com/blog/post/explained-the-vyper-bug-hack-july-2023))
- **June 2024 — the founder-liquidation cascade.** Founder **Michael Egorov** had borrowed roughly **$95M** in stablecoins against about **$141M** of CRV spread across five lending venues. A ~24% CRV drop on 13 June triggered cascading liquidations that wiped out most of that collateral and briefly left ~$10M of bad debt in Curve's own LlamaLend market. Egorov repaid the bad debt within days, so no permanent loss was passed to depositors — but the episode is a standing lesson about founder over-leverage against a governance token. ([CoinDesk](https://www.coindesk.com/markets/2024/06/13/crv-slides-30-as-loans-tied-to-curves-founder-face-liquidation-risk))

## How Caper approaches this

Curve's veCRV set out to solve a real problem — transient token holders voting with no lasting stake — by forcing a **lock**. It worked, and then the lock itself became a tradable asset: Convex tokenised it and a bribe market rented it out, so control drifted back toward whoever could pay. A [caper](/wiki/foundations/what-is-a-caper) pursues the same goal — tying influence to genuine commitment — without a lock to tokenise. Its [voting weight](/wiki/governance/voting) combines the _stake_ a member holds with the _participation_ they have actually shown, so weight is _earned_ rather than rented, and a one-off borrowed position buys little say. There is also no gauge system and **no emissions to direct**: a caper's tokens come from a [bonding curve](/wiki/markets/bonding-curve), not a weekly inflation vote, so there is simply no emission stream for a "war" to capture. And because that same earned weight is also each member's [pro-rata exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), control stays coupled to real economic exposure — the property the lock was reaching for — with nothing to unbundle and sell. This is a design contrast, not a claim of superiority; the mechanics are on the linked pages and verified against the contract.

## References

- [Curve DAO: Voting Escrow (veCRV)](https://curve.readthedocs.io/dao-vecrv.html) — the canonical vote-escrow reference (primary).
- [curvefi/curve-dao-contracts](https://github.com/curvefi/curve-dao-contracts) — the DAO and gauge/escrow contracts (primary).
- [Curve governance forum](https://gov.curve.finance/) — proposals and gauge-weight discussion (primary).
- Halborn, [Explained: The Vyper Bug Hack (July 2023)](https://www.halborn.com/blog/post/explained-the-vyper-bug-hack-july-2023) — Curve reentrancy post-mortem.
- CoinDesk, [CRV slides as founder loans face liquidation](https://www.coindesk.com/markets/2024/06/13/crv-slides-30-as-loans-tied-to-curves-founder-face-liquidation-risk) (2024).

## dYdX

URL: https://caper.network/wiki/daos/dexs/dydx
Updated: 2026-07-26

|  |  |
| --- | --- |
| **Name** | dYdX |
| **Type** | Protocol DAO (decentralized perpetuals exchange) |
| **Governance token** | DYDX — native staking + governance token of the dYdX Chain (migrated from the Ethereum ERC-20 ethDYDX) |
| **Product** | An on-chain order-book perpetual-futures exchange |
| **Governance model** | On-chain via the Cosmos SDK [x/gov](https://github.com/cosmos/cosmos-sdk/tree/main/x/gov) module — proposals deposited, then voted by **staked DYDX**; validators vote on behalf of delegators who can override |
| **Architecture** | A standalone [CometBFT](https://cometbft.com/) / Cosmos SDK Layer 1 (the “dYdX Chain”) — genesis 26 Oct 2023 |
| **Notable for** | Abandoning a top Ethereum L2 to launch its own app-chain, moving governance from Aave-style contracts to validator-and-stake-weighted chain governance |

**dYdX** is a decentralized exchange for perpetual futures. Its distinguishing decision is architectural: rather than remain a smart-contract application on a shared chain, dYdX rebuilt itself as its _own_ sovereign blockchain — the **dYdX Chain**, a [Cosmos SDK](https://cosmos.network/) Layer 1 whose validator set runs a fully on-chain order book. That move reshaped its governance completely. Where the earlier Ethereum version borrowed [Aave’s](/wiki/daos/lending/aave-dao) on-chain-Governor-plus-timelock machinery, the app-chain governs itself the way Cosmos chains do: through the standard governance module, where voting power is **staked DYDX** and validators carry their delegators’ votes by default. dYdX is the clearest case study in the wiki of a DAO that changed its governance by changing the ground it stands on. Claims below link to dYdX’s own documentation and primary reporting. dYdX's order book also sets it apart from the other main perps design in the directory: [GMX](/wiki/daos/dexs/gmx) has traders take leverage against a shared liquidity pool rather than matching them against each other. A newer entrant, [Hyperliquid](/wiki/daos/dexs/hyperliquid), takes the same app-chain-perps route with its own L1 but a much lighter governance layer — a useful contrast to dYdX's full on-chain Cosmos governance.

## From an Ethereum L2 to a sovereign app-chain

dYdX v3 ran as an Ethereum Layer 2 built on [StarkEx](https://starkware.co/starkex/), with an off-chain order book and matching engine operated by the dYdX company and on-chain settlement via a validium. Governance lived in Ethereum contracts modeled on Aave: a Governor tracking proposals, multiple timelock executors (short- and long-delay), a Safety Module staking pool, and a Governance Strategy that counted voting power from `ethDYDX`, `wethDYDX`, and staked `stkDYDX`.

On **26 October 2023** the [dYdX Chain launched on mainnet](https://www.theblock.co/post/259658/dydx-chain-officially-launches-on-mainnet-as-standalone-cosmos-layer-1) as a standalone Cosmos SDK / CometBFT chain — a genesis block produced by an independent validator set, not a rollup posting to Ethereum. The order book itself now lives on-chain, replicated across validators. A community governance vote initiated a migration of the token: holders bridge the Ethereum `ethDYDX` ERC-20 to the chain’s native `DYDX` through a [one-way, permissionless, irreversible bridge](https://www.dydx.foundation/blog/dydx-token-mechanics) with no end date. The old Ethereum governance stack did not move across; the chain governs itself with Cosmos-native tooling.

## On-chain governance through the Cosmos gov module

The dYdX Chain uses the [standard Cosmos SDK `x/gov` module](https://docs.dydx.community/dydx/modules/governance), so its lifecycle mirrors other Cosmos chains rather than an Ethereum DAO:

- **Deposit period.** A proposal must attract a minimum deposit to reach a vote — a **2,000 DYDX** initial deposit is required to open it (the module’s initial-deposit ratio is 20% of the full minimum), within a **7-day** deposit window; anyone may top it up.
- **Voting period.** Once funded, a roughly **4-day** vote opens with four options — **Yes**, **No**, **NoWithVeto**, and **Abstain**.
- **Passage.** A proposal passes on a **33.4% quorum**, a **50%** Yes majority of non-abstaining votes, and fewer than **33.4% NoWithVeto**. Abstain counts toward quorum but not toward the majority.
- **Veto teeth.** If the NoWithVeto threshold is crossed, the proposal is rejected _and its deposit is burned_ — a built-in cost for spam or captured proposals. Deposits are not burned merely for failing to reach quorum.

Unlike an Ethereum Governor executing arbitrary calldata through a timelock, a passed dYdX proposal is applied by the chain’s own state-machine logic — parameter changes, software upgrades, and treasury spends handled as native governance actions. The fellow Cosmos AMM [Osmosis](/wiki/daos/dexs/osmosis) governs itself through the same module, making the two the canonical app-chain-DEX pair.

## Stake to vote: validator inheritance and delegator override

The defining feature of Cosmos-style governance is that _voting power is staked, not merely held_. On the dYdX Chain a holder’s vote weight equals the DYDX they have **actively staked**, one-for-one; unstaked or unbonding tokens carry no weight ([governance module docs](https://docs.dydx.community/dydx/modules/governance)). Because staking secures the chain, this fuses two roles the earlier Ethereum design kept separate: the token that pays for block security is the same token that votes.

Staking is delegated to validators, and that shapes participation. By default a **validator votes on behalf of everyone delegated to it**, and any delegator who does not cast their own vote _inherits_ the validator’s choice. A delegator who disagrees can **override** by voting directly with their own stake. The upshot is a plutocracy softened by delegation: default power pools in the validator set, but engaged delegators can always reclaim their weight. It is [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) with a staking gate and a delegation layer — Sybil-resistant and security-aligned, yet still power proportional to capital.

## What governance controls

Because dYdX _is_ the chain, its governance reaches further than a single application’s parameters. Passed proposals can authorize **software upgrades** to the chain binary, tune **module and market parameters** (fees, margin, listing new perpetual markets), and direct the **community treasury** that funds grants and ecosystem work. The [dYdX Foundation](https://www.dydx.foundation/) and the operations subDAO steward process and tooling, but the binding levers — what the chain runs and how it spends — sit with staked-DYDX voters. Governance here is not an overlay on a protocol; it is the protocol’s upgrade and treasury mechanism, expressed in the chain’s own consensus. For a different answer to the same problem, compare [Synthetix](/wiki/daos/dexs/synthetix), which governs through an elected Spartan Council rather than direct staked-token voting.

## How Caper approaches this

dYdX makes governance Sybil-resistant by tying it to _staked_ capital and delegating it to a validator set: your vote is your stake, and if you do nothing your validator votes for you. It is a coherent design for a chain that must also be secured — but the decisive factor is still DYDX bought on a market, and the default resting place of power is the validators. [Caper](/wiki/foundations/what-is-a-caper) folds a different quantity into the weight. A caper member’s vote weight is `(t·v)/(V·T)` — held tokens `t` times the member’s _earned_ [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) votes `v`, over supply `V` and circulation `T` — computed by the contract’s `compute_vote_weight` helper and reused verbatim by `exit()` to size a member’s treasury share, so the same metric that governs also settles the way out. The vote token is `DIVISIBILITY_NONE`, minted one per vote, and non-transferable (its depositor role is bound to the component’s own `global_caller` and its updater is `deny_all`), so `v` is an accumulated record of participation that cannot be delegated to a validator, staked for yield, or bought on a market. This is not a claim that holdings do not matter — `t` is a straight multiplier, so a bag still counts — but a large bag alone cannot capture control the way a whale accumulating staked DYDX can, because the second factor has to be earned one vote at a time. Caper also declines dYdX’s coupling of security and governance: there is no validator set to delegate to and no staking layer, only a flat membership voting a typed treasury.

## References

- [dYdX governance module documentation](https://docs.dydx.community/dydx/modules/governance) — deposit, voting, quorum, thresholds, and vote-weight rules.
- [dYdX Foundation — expanded utility of DYDX on the dYdX Chain](https://www.dydx.foundation/blog/dydx-token-mechanics) — the ethDYDX→DYDX one-way migration and staking.
- [The Block](https://www.theblock.co/post/259658/dydx-chain-officially-launches-on-mainnet-as-standalone-cosmos-layer-1) and [CoinDesk](https://www.coindesk.com/tech/2023/10/24/dydx-decentralized-crypto-exchange-open-sources-v4-code-for-upcoming-cosmos-chain) — the standalone Cosmos Layer 1 launch (26 Oct 2023).
- [Cosmos SDK x/gov module](https://github.com/cosmos/cosmos-sdk/tree/main/x/gov) — the underlying governance primitive (deposit/voting periods, NoWithVeto, delegator inheritance).

## GMX (GMX)

URL: https://caper.network/wiki/daos/dexs/gmx
Updated: 2026-07-22

|  |  |
| --- | --- |
| **Name** | GMX |
| **Type** | Protocol DAO (decentralized spot & perpetual-futures exchange) |
| **Governance token** | GMX — capped-supply staking + governance token (max [13.25 million](https://docs.gmx.io/docs/tokenomics/gmx-token)) |
| **Product** | On-chain leverage trading where traders take positions against a shared liquidity pool rather than an order book |
| **Chains** | [Arbitrum](https://blog.arbitrum.io/gmx-an-in-depth-look-at-arbitrums-leading-permissionless-exchange-for-on-chain-leverage-trading/) (2021) and Avalanche (2022) |
| **Governance model** | [Snapshot](https://snapshot.org/#/gmx.eth) signaling + on-chain execution via [Tally](https://www.tally.xyz/gov/gmx); voting power is GMX held/staked |
| **Notable for** | Popularizing “real yield” — paying stakers a share of trading fees in ETH/AVAX rather than in an inflationary emission — and the pooled-liquidity (“be the house”) perps model |

**GMX** is a decentralized exchange for spot swaps and perpetual futures, running on [Arbitrum and Avalanche](https://gmx.io/). Its defining design choice sits on the other side of the trade from a DAO like [dYdX](/wiki/daos/dexs/dydx): instead of matching buyers against sellers in an on-chain _order book_, and instead of minting _synthetic_ exposure the way [Synthetix](/wiki/daos/dexs/synthetix) does, GMX has traders take leverage directly against a shared pool of real assets. The liquidity providers who fund that pool are, collectively, the counterparty to every open position — they win when traders lose and lose when traders win, in exchange for the fees the venue generates. GMX governs the parameters of that arrangement: which markets exist, what they charge, and how the fees are split.

## The pooled-liquidity model: LPs are the house

A perps exchange needs someone to take the opposite side of every leveraged bet. Centralized venues use market makers; order-book DAOs like dYdX match traders against each other. GMX instead lets anyone become the counterparty by depositing into a communal pool. From launch in 2021 through mid-2025, that pool was a single multi-asset basket called **GLP** — depositors held a claim on a mix of blue-chip tokens and stablecoins, earned the venue's trading and borrow fees, and absorbed the aggregate profit or loss of all traders against the pool ([Arbitrum's own writeup](https://blog.arbitrum.io/gmx-an-in-depth-look-at-arbitrums-leading-permissionless-exchange-for-on-chain-leverage-trading/) covers the early design). Prices came from an oracle rather than a matching engine, which gave zero-slippage execution at the size the pool could support but made the pool's health dependent on the oracle being right.

## GMX V2 and isolated GM pools

In 2025 the protocol completed its migration to **GMX V2**, replacing the one-basket-backs-everything design with per-market **GM pools**. Each GM pool backs a single market and holds two assets: a _long token_ that backs long positions and a _short token_ that backs shorts — a [WETH–USDC market](https://docs.gmx.io/docs/providing-liquidity/), for example, uses WETH to back longs and USDC to back shorts. Isolating liquidity per market means a blow-up in one long-tail market can't drain the pool backing ETH or BTC, and it lets LPs choose exactly which risk they underwrite. Pricing uses [Chainlink low-latency oracles](https://docs.chain.link/data-streams) plus a price-impact mechanism that rewards trades which balance a pool's open interest and penalizes those that skew it. Per GMX's docs, GM liquidity providers earn the majority of fees — [63% on Arbitrum and Avalanche](https://docs.gmx.io/docs/providing-liquidity/) — with 10% routed to GMX stakers and the remainder to the protocol.

## “Real yield” and the GMX token

GMX is the protocol most associated with the **real-yield** thesis that swept DeFi in 2022–2023: the idea that a governance token should distribute _actual revenue_ in a hard asset, not print more of itself to simulate returns. Staked GMX historically earned three things — a share of protocol fees paid in [ETH or AVAX](https://docs.gmx.io/docs/tokenomics/gmx-token), escrowed GMX (**esGMX**) that vests into liquid GMX over time, and **Multiplier Points** that boost a long-term staker's fee share and reward holding over churn. The token supply is capped at a forecast maximum of 13.25 million, and minting beyond that cap requires a governance vote. That contrast — fees paid in ETH to a capped token, versus rewards paid in freshly-minted inflation — is the reason GMX became the reference point for “real” DeFi yield, and a useful comparison for how [Curve](/wiki/daos/dexs/curve-dao)-style emission models distribute value differently.

## What GMX governance controls

The GMX DAO decides the levers that determine whether the venue is profitable and safe: which markets get listed, the fee and borrow-rate parameters, oracle configuration, and how revenue is allocated between LPs, stakers, and the treasury. Signaling happens on [Snapshot](https://snapshot.org/#/gmx.eth), with binding actions executed on-chain through [Tally](https://www.tally.xyz/gov/gmx). A notable recent decision reworked the token's value accrual: rather than stream fees to stakers continuously, the DAO [approved routing 27% of protocol fees](https://docs.gmx.io/docs/tokenomics/gmx-token) into buying GMX back on the open market. Per the docs, those bought-back tokens accumulate in the treasury and staking-reward distribution is currently paused, set to resume once GMX reaches a target price — a governance choice to convert ongoing revenue into buy pressure and a treasury reserve instead of a running dividend.

## The July 2025 V1 exploit

On 9 July 2025, the legacy **GMX V1** GLP pool on Arbitrum was drained of roughly [$40–42 million](https://www.theblock.co/post/362164/gmx-token-surges-14-after-hacker-begins-returning-funds-from-40-million-exploit). The attack exploited a re-entrancy flaw that let the attacker mint GLP abnormally: by opening manipulated short positions they distorted the pool's recorded average short price and size, inflated the GLP token price, and redeemed at the inflated value. GMX halted V1 trading and GLP minting, and the team offered the attacker a [10% white-hat bounty](https://www.dlnews.com/articles/defi/gmx-offers-hacker-10-percent-bounty-after-42m-exploit/) to return the rest — which the exploiter [accepted and repaid](https://cointelegraph.com/news/gmx-exploiter-begins-returning-stolen-funds). The episode is the sharpest illustration of the pooled model's core trade-off: when LPs _are_ the counterparty, a pricing bug isn't a bad trade for one desk — it's a direct claim on the shared pool everyone funded. V2's isolated markets and stricter oracle handling are the structural response.

## How Caper approaches this

GMX ties governance power to a freely-tradeable, capped token: buy and stake more GMX and you earn a larger share of fees and a larger vote over the parameters that set those fees. It is transparent capital-weighting — whoever brings the most liquidity-underwriting capital carries the most weight. [Caper](/wiki/foundations/what-is-a-caper) weights a member's say differently. Governance weight is the canonical formula `w = (t · v) / (V · T)` — a member's held tokens `t` multiplied by the votes `v` they have actually cast, over total vote supply `V` and circulating tokens `T` (verified against `contracts/logic/src/lib.rs`). The vote count `v` is _earned_, minted one per vote as a non-transferable, indivisible proof-of-vote token you cannot buy or sell (verified in `contracts/core/src/caper_dao.rs`), and the same weight sets a member's [exit](/wiki/governance/execution) share of the treasury. Holdings still matter — `t` is a multiplier, so a member with no stake has no weight — but capital alone can't buy control the way stacking GMX can. The design goal is different: GMX optimizes for whoever underwrites the most risk, Caper for whoever has both skin in the game and a record of showing up. See [Trading](/wiki/markets/trading) and [Voting](/wiki/governance/voting) for the mechanics.

## References

- [GMX — official site](https://gmx.io/)
- [GMX Docs — GMX token, supply, staking & buyback](https://docs.gmx.io/docs/tokenomics/gmx-token)
- [GMX Docs — Providing liquidity (GM pools, fee split)](https://docs.gmx.io/docs/providing-liquidity/)
- [Arbitrum blog — GMX in depth](https://blog.arbitrum.io/gmx-an-in-depth-look-at-arbitrums-leading-permissionless-exchange-for-on-chain-leverage-trading/)
- [GMX governance — Snapshot](https://snapshot.org/#/gmx.eth) · [Tally](https://www.tally.xyz/gov/gmx)
- [The Block — July 2025 GMX V1 exploit & fund return](https://www.theblock.co/post/362164/gmx-token-surges-14-after-hacker-begins-returning-funds-from-40-million-exploit)
- [Cointelegraph — exploiter returns stolen funds](https://cointelegraph.com/news/gmx-exploiter-begins-returning-stolen-funds)

## Hyperliquid

URL: https://caper.network/wiki/daos/dexs/hyperliquid
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Organization** | Hyperliquid |
| **Type** | Perpetuals DEX on a purpose-built Layer 1 |
| **Status** | 🟢 Active |
| **Founded** | 2023; HYPE genesis distribution November 2024 |
| **Token** | HYPE — gas, staking, fee buybacks, governance |
| **Chain** | Hyperliquid L1 — HyperCore + HyperEVM, HyperBFT consensus |
| **Distinctive** | No-VC, fully-unlocked airdrop; Assistance Fund buyback |
| **Website** | [hyperliquid.xyz](https://hyperliquid.xyz) |
| **Related** | [dYdX](/wiki/daos/dexs/dydx), [GMX](/wiki/daos/dexs/gmx), [Jupiter](/wiki/daos/dexs/jupiter), [DAO directory](/wiki/daos) |

**Hyperliquid** is a decentralized perpetual-futures exchange that runs on its own high-performance Layer 1 blockchain. Like [dYdX](/wiki/daos/dexs/dydx), it belongs to the **app-chain perps** archetype — the whole exchange, order book included, lives on-chain rather than on a shared general-purpose network — but it is best known for two things beyond the technology: a token launch with _no venture-capital allocation_, and a fee mechanism that continuously buys its own token back out of trading revenue.

The protocol reached mainnet in 2023 and distributed its [HYPE](https://hyperliquid.gitbook.io/hyperliquid-docs/) token in November 2024. Its rise made it one of the most-watched cases in DeFi for a live debate this wiki covers throughout: where real power and value in a "community-owned" protocol actually sit.

## HyperCore and HyperEVM

Per the [official documentation](https://hyperliquid.gitbook.io/hyperliquid-docs/), Hyperliquid's state is split into two parts. **HyperCore** is the trading engine — an on-chain central-limit order book for perpetuals and spot with one-block finality, built to handle order flow at centralized-exchange speeds. **HyperEVM** wraps that liquidity in a fully Ethereum-compatible smart-contract layer, so builders can deploy apps that draw directly on HyperCore's markets. Both are secured by **HyperBFT**, a custom consensus algorithm the docs describe as "inspired by HotStuff and its successors."

The design goal is to remove the usual trade-off in on-chain trading: keep the performance and UX of an off-chain order book while settling everything transparently on a chain the community secures.

## The HYPE token and the Assistance Fund

HYPE has a fixed maximum supply of 1 billion tokens. Its launch is the part most often cited: roughly **31% of supply went to about 94,000 users** in the November 2024 genesis airdrop, fully unlocked, with **no allocation to venture investors** — an unusually community-weighted distribution for a protocol of its size.

The token does the ordinary L1 jobs — it pays gas on HyperEVM (with EIP-1559 fee burning), and validators stake it (with delegation) to secure HyperBFT consensus. Its signature feature is the **Assistance Fund**: a large share of protocol trading fees is routed into automated open-market purchases of HYPE. This turns exchange usage directly into buy pressure on the token — a protocol-level analogue of the buybacks [dYdX](/wiki/daos/dexs/dydx) and others adopted, but hard-wired into fee flow rather than voted on each period.

## Governance: powerful token, lighter DAO

Hyperliquid is a useful counter-example to the assumption that "on-chain protocol" means "full on-chain DAO." HYPE carries real influence — holders stake to secure the chain and can vote on **Hyperliquid Improvement Proposals (HIPs)** and on validator-level decisions — but day-to-day direction has stayed close to the core team and the Hyper Foundation, and the protocol has not (yet) devolved treasury and roadmap control to a token vote the way a mature [governance-model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) DAO does. Whether that is a bootstrapping phase on the way to [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) or a durable design choice is exactly the kind of [on-chain-vs-off-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) question the token's market value tends to gloss over.

### How Caper approaches this

Hyperliquid shows how much a community can rally around a fair-looking launch and a token that captures fees — and also how far "holding the token" can sit from "steering the organization." [Caper](/wiki/foundations/what-is-a-caper) is built around closing that gap. Two differences are concrete. First, value comes back to holders as a right, not a policy: instead of a discretionary buyback, every holder has an always-open [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — burn your stake, redeem a pro-rata slice of the treasury. Second, that slice is sized by the same canonical vote weight `(t·v)/(V·T)` that governs your votes, so the influence you hold and the value you can withdraw are measured identically — there is no gap between the two for a foundation to occupy.

## Jupiter (JUP DAO)

URL: https://caper.network/wiki/daos/dexs/jupiter
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Name** | Jupiter (JUP DAO) |
| **Type** | Protocol DAO (Solana DEX aggregator and launchpad) |
| **Governance token** | JUP — 10 billion total supply, launched 31 Jan 2024 |
| **Product** | Solana’s largest swap aggregator, plus perps, a launchpad, and related products |
| **Governance model** | Stake JUP to vote; [Active Staking Rewards](https://vote.jup.ag/) pay quarterly rewards to holders who actually vote. Voting was paused from June 2025 and **resumed in early 2026** under a narrowed remit |
| **Founder** | Pseudonymous, known as “Meow” |
| **Notable for** | One of the largest airdrops in Solana’s history, paying stakers to vote, and then **pausing its own DAO** in 2025 over a stated “breakdown in trust” — before restarting it in 2026 with Work Groups abolished |

**Jupiter** is the dominant swap aggregator on [Solana](https://solana.com/) and the issuer of the **JUP** governance token. Its governance story is unusually instructive because it runs to both extremes: Jupiter built one of the more thoughtful token-voting systems in the industry — it pays quarterly rewards to holders who actually vote rather than merely hold — and then, in June 2025, it **paused that governance entirely**, telling its own community that the current structure was not working and that trust had broken down. Few DAOs make the case against their own governance as plainly. This page covers how JUP governance is meant to work, the buyback program that now anchors the token, and the 2025 pause. Every claim links to Jupiter’s own documentation or primary reporting.

## Solana’s aggregator and one of its biggest airdrops

Jupiter routes trades across Solana’s liquidity venues to find the best execution, and by volume it is the chain’s leading aggregator. The JUP token launched on **31 January 2024** with a total supply of **10 billion**, distributed 40% to airdrops, 40% to the team and investors, 10% to a treasury, and 10% to a foundation ([Blockworks](https://blockworks.com/news/jupiter-airdrop-tokenomics)). The first airdrop sent roughly **1.35 billion JUP to nearly a million wallets** — one of the largest distributions in Solana’s history — and the project has continued the “Jupuary” airdrops in subsequent years ([The Block](https://www.theblock.co/post/272800/jupiter-jup-token-launch-date-memecoin-drop-planned)). The scale matters for governance: a token spread across a million wallets is exactly the setting in which [low turnout](/wiki/dao-governance/concepts/analysis/how-daos-fail) and [capital-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) become the central problem, and Jupiter’s design choices are a direct response to it.

## Active Staking Rewards: paying holders to actually vote

To vote in the Jupiter DAO you first **stake** JUP, which locks the token in the governance contract and grants voting power ([Jupiter documentation](https://docs.jup.ag/user-docs/more/dao/staking)). Staked holders who participate in votes then earn **Active Staking Rewards (ASR)**, distributed **each quarter** and weighted by how long the stake has been held. Crucially, ASR rewards _voting_, not mere holding: a staker who never votes forfeits the rewards, which is Jupiter’s answer to the [voter-apathy](/wiki/dao-governance/concepts/voting/voting-and-delegation) problem that hollows out most token DAOs. Unstaking triggers a mandatory **7-day cooldown** that “cannot be skipped or accelerated” — a deliberate guard so nobody can stake just before a distribution, claim, and unstake without any sustained commitment. The rewards pool has run at roughly **50 million JUP per quarter** ([vote.jup.ag](https://vote.jup.ag/)). It is one of the more coherent attempts in the industry to make participation, rather than balance, the thing that governance pays for.

## The Litterbox: turning protocol fees into buybacks

At its “Catstanbul” event on **26 January 2025**, founder Meow announced that Jupiter would direct **50% of protocol fee revenue** to buy JUP back from the open market, holding the repurchased tokens in a long-term reserve nicknamed the **“Litterbox”**; the other half funds growth and operations ([The Block](https://www.theblock.co/post/337071/jupiter-spikes-40-as-founder-says-50-of-fees-will-go-to-token-buybacks)). By late 2025 the Litterbox had accumulated on the order of **130 million JUP**, around 4% of circulating supply, and as part of a 2025 “Fresh Start” the DAO put the repurchased stack up for a burn vote ([Jupiter](https://x.com/JupiterExchange/status/1983973510918893730)). A fee-funded buyback places Jupiter in the same lineage as [protocol-owned-treasury](/wiki/daos/stablecoins/olympusdao) designs: value is meant to accrue to the token from real revenue rather than from emissions — the mirror image of the [inflationary reward](/wiki/dao-governance/concepts/treasury/dao-treasury-management) that funds ASR.

## When a DAO pauses itself

On **20 June 2025**, Jupiter did something few large DAOs have done: it **halted all DAO voting** until 2026, stating that “the current DAO structure isn’t working as intended” and citing a **breakdown in trust** between the DAO, holders, and team. Team member Kash Dhanda described the ecosystem as “stuck in a negative feedback loop” ([CoinDesk](https://www.coindesk.com/business/2025/06/20/solana-dex-jupiter-pauses-dao-votes-citing-breakdown-in-trust); [DL News](https://www.dlnews.com/articles/defi/solana-exchange-jupiter-pauses-dao-voting-until-2026/)). No new DAO-funded Work Groups would be created, though ASR continued at its 50-million-JUP-per-quarter rate so that stakers were not penalized for the pause. Jupiter framed the halt as a reset rather than a retreat — a “Fresh Start” to scale back a governance apparatus that had grown adversarial and rebuild it on simpler terms. It is a candid admission that token-holder governance, even with paid participation and one of Solana’s deepest communities, can become a net drain on a project rather than a source of legitimacy — the [failure modes](/wiki/dao-governance/concepts/analysis/how-daos-fail) playing out at one of the ecosystem’s most-watched DAOs.

## The restart, and what did not come back

Governance resumed in early 2026, but not as it was. Jupiter [disbanded every Work Group and narrowed the DAO's remit](https://solanafloor.com/news/jupiter-dao-announces-structural-overhaul-to-refocus-on-high-impact-governance) to proposals that touch tokenomics and treasury directly — revenue allocation, supply control, long-term token strategy. The everyday budgeting the old DAO spent most of its votes on is simply no longer a governance question. That is the reset in one line: fewer things are voted on, and the things that remain are the ones where a token vote is hardest to argue against.

The first real test came in February 2026 with **“Going Green”**, a proposal to drive net-new JUP emissions to zero for the rest of the year by [postponing the Jupuary airdrop, pausing team vesting and buying out the legacy Mercurial vesting](https://solanafloor.com/news/jupiter-weighs-plan-to-drive-jup-token-emissions-to-net-zero). Holders were given the status quo as the explicit alternative. Voting ran 17–21 February and [closed on 22 February with roughly 75% for Net Zero and 25% for continuing the airdrop](https://crypto-economy.com/jupiter-proposes-going-green-plan-to-achieve-zero-net-jup-emissions-in-2026/); [more than 81% of large-holder voting weight backed the same side](https://solanafloor.com/news/over-81-of-whale-voting-weight-backs-zero-emissions-in-jupiter-dao-vote). The 2026 Jupuary allocation was [cut from a planned 700 million JUP](https://coinmarketcap.com/top-stories/69dafdda3b10291756db57cd/) and the withheld tokens returned to Jupiter's community-controlled multisig.

It is worth being precise about what that vote demonstrates, because it cuts both ways. A DAO that had declared its own governance broken came back and used a token vote to cancel a payout to its own token holders — the outcome a purely rent-seeking electorate is supposed to be incapable of reaching. But the whale-weight figure tracking the headline result so closely is the older problem restated: a 75% result that is also an 81% large-holder result tells you less about the electorate than it looks like it does. The narrowing is what changed; the [capital-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) basis of the vote did not.

## How Caper approaches this

Jupiter’s trajectory is the strongest possible argument for the problem [Caper](/wiki/foundations/what-is-a-caper) is built around. Jupiter did more than most to make governance work — it _paid_ holders to vote through ASR — and still concluded that its DAO had become a liability worth pausing. Two structural facts drove that outcome: participation had to be subsidized with fresh emissions because it was extrinsic to the vote, and a JUP-weighted vote is still a vote bought on a market, so influence tracked capital rather than commitment. Caper folds a different quantity into the weight. A caper member’s vote weight is `(t·v)/(V·T)` — held tokens `t` times the member’s _earned_ [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) votes `v`, over supply `V` and circulation `T` — computed by the contract’s `compute_vote_weight` helper and reused verbatim by `exit()` to size a member’s treasury share, so the same metric that governs also settles the way out. The vote token is `DIVISIBILITY_NONE`, minted one per vote, and non-transferable (its depositor role is bound to the component’s own `global_caller` and its updater is `deny_all`), so `v` is an accumulated record of participation that cannot be bought, borrowed, or farmed for a reward — and a member’s first vote counts for nothing, so freshly-arrived capital carries little weight. Participation does not need a quarterly subsidy because it _is_ the weight, and there is no separate ASR emission to fund. This is not a claim that holdings do not matter — `t` is a straight multiplier, so a bag still counts — but a large bag alone cannot capture control, because the second factor has to be earned one vote at a time. And because that earned standing also sets each member’s claim on the treasury at [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), a member who loses trust can leave with their fair share rather than force the whole DAO to pause; voice and exit are the same number.

## References

- [Jupiter DAO governance portal](https://vote.jup.ag/) — staking, voting, and Active Staking Rewards.
- [Jupiter documentation — Staking](https://docs.jup.ag/user-docs/more/dao/staking) — the 7-day unstake cooldown and quarterly time-weighted ASR.
- [Blockworks](https://blockworks.com/news/jupiter-airdrop-tokenomics) and [The Block](https://www.theblock.co/post/272800/jupiter-jup-token-launch-date-memecoin-drop-planned) — the 31 Jan 2024 launch, 10 billion supply, and airdrop allocation.
- [The Block](https://www.theblock.co/post/337071/jupiter-spikes-40-as-founder-says-50-of-fees-will-go-to-token-buybacks) — the 26 Jan 2025 announcement that 50% of fees fund JUP buybacks (the “Litterbox”).
- [CoinDesk](https://www.coindesk.com/business/2025/06/20/solana-dex-jupiter-pauses-dao-votes-citing-breakdown-in-trust) and [DL News](https://www.dlnews.com/articles/defi/solana-exchange-jupiter-pauses-dao-voting-until-2026/) — the 20 June 2025 pause of DAO voting until 2026.

## Osmosis (OSMO)

URL: https://caper.network/wiki/daos/dexs/osmosis
Updated: 2026-07-28

| Project | Osmosis |
| --- | --- |
| Token | OSMO (staking, governance & fees) |
| Type | Sovereign app-chain AMM DEX (Cosmos) |
| Chain | Own [Cosmos SDK](https://cosmos.network/) chain; [IBC](https://www.ibcprotocol.dev/)-connected |
| Consensus | CometBFT (Tendermint) proof-of-stake |
| Launched | Mainnet 19 June 2021 |
| Founders | Sunny Aggarwal, Josh Lee, Dev Ojha (Osmosis Labs) |
| Max supply | 1,000,000,000 OSMO (asymptotic) |
| Governance | On-chain, [Cosmos SDK gov module](https://docs.cosmos.network/sdk/latest/modules/gov/README); OSMO stakers vote |
| Status | 🟢 Active |
| Website | [osmosis.zone](https://osmosis.zone/) |

**Osmosis** is the largest [automated market maker](/wiki/daos/dexs/uniswap-dao) in the [Cosmos](https://cosmos.network/) ecosystem — but, unlike an AMM that ships as a set of contracts on someone else's chain, Osmosis is its _own_ [sovereign proof-of-stake blockchain](https://docs.osmosis.zone/) built with the Cosmos SDK. That is the defining fact about its governance: because the exchange _is_ the chain, OSMO stakers don't just vote on a treasury or a fee switch, they vote on the protocol's own consensus rules, module parameters, and code upgrades directly on-chain. It sits alongside [dYdX](/wiki/daos/dexs/dydx) as one of the two canonical examples of the **app-chain DEX** — a trading venue that governs itself as a base layer rather than as a smart contract.

## A fair-launch genesis

Osmosis is one of DeFi's cleaner examples of a launch with **no public or venture pre-sale of the genesis supply**. The initial 100 million OSMO was [split evenly](https://medium.com/osmosis/osmo-token-distribution-ae27ea2bb4db): 50% "Fairdropped" to [ATOM](/wiki/daos/dexs/uniswap-dao) stakers and 50% to a strategic reserve for development, liquidity, and the community. The airdrop was snapshotted during the Cosmos Hub Stargate upgrade on 18 February 2021, weighted by the _square root_ of each address's ATOM balance (with a 2.5× multiplier for staked ATOM) — a deliberately Sybil-dampening, [quadratic-flavoured](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) distribution rather than a linear one. Mainnet went live on 19 June 2021; the protocol's **$21M raise led by Paradigm came later, in October 2021**, after the token was already trading and governing.

## The AMM: supercharged liquidity and superfluid staking

Osmosis has iterated its market design further than most AMMs. In July 2023 it shipped [Supercharged Liquidity](https://docs.osmosis.zone/overview/educate/getting-started/) — its name for concentrated liquidity, letting LPs place capital in chosen price ranges the way [Uniswap v3](/wiki/daos/dexs/uniswap-dao) does. It also pioneered **Superfluid Staking**, which lets bonded OSMO in an eligible pool simultaneously secure the chain and provide trading liquidity, so the same token earns staking rewards _and_ LP fees instead of forcing a choice between the two. Pool creation is permissionless — anyone can spin up a supercharged pool without a governance vote — while the incentives that flow to pools remain a [governance-tuned](https://docs.osmosis.zone/learn/osmo/) parameter.

## ProtoRev: MEV that accrues to the DAO

Osmosis's most distinctive economic feature is [ProtoRev](https://docs.osmosis.zone/learn/features/protorev/), an in-protocol arbitrage module live since March 2023. When a user's swap knocks a pool out of line with the rest of the market, ProtoRev detects the resulting cyclic arbitrage and **executes it atomically in the same transaction** — capturing the value the protocol itself, rather than auctioning it to external MEV searchers. The proceeds go back to the network as governance directs: OSMO gains are [burned](https://docs.osmosis.zone/learn/osmo/) (reducing max supply), and non-OSMO proceeds route to the [community pool](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity). It is a rare working answer to a problem most DAOs simply leak on: turning an extractive externality into [protocol-owned revenue](https://docs.osmosis.zone/learn/features/protorev/).

## OSMO tokenomics and "the Thirdening"

OSMO is capped at a [maximum 1 billion](https://docs.osmosis.zone/learn/osmo/) tokens, approached asymptotically through a declining emission schedule Osmosis calls **the Thirdening**: each reduction period the annual issuance is multiplied by two-thirds — a one-third cut. New OSMO is [split by governance-set proportions](https://medium.com/osmosis/osmo-token-distribution-ae27ea2bb4db) across staking rewards, developer vesting, liquidity-mining incentives, and the community pool. On top of emissions, a default 0.1% [taker fee](https://docs.osmosis.zone/learn/osmo/) routes 25% to the community pool and 75% to OSMO buybacks, while OSMO-denominated taker fees are 30% to stakers and 70% burned — a deflationary counterweight the DAO controls directly. OSMO's three jobs are the classic [app-chain trio](/wiki/dao-governance/concepts/treasury/dao-tokenomics): stake to secure, pay gas, and govern.

## On-chain governance

Because Osmosis is a Cosmos SDK chain, its governance runs through the standard [gov module](https://docs.cosmos.network/sdk/latest/modules/gov/README) that the [Cosmos Hub](/wiki/daos/networks/cosmos-hub) pioneered: a proposal takes a minimum OSMO deposit to enter voting, then staked OSMO votes over a fixed voting period with the four Cosmos options — **Yes, No, Abstain, and NoWithVeto**. As with all Cosmos chains, [validators vote on behalf of their delegators](/wiki/dao-governance/concepts/voting/voting-and-delegation) by default, and a delegator can override their validator by casting their own vote. A NoWithVeto supermajority doesn't just defeat a proposal — it burns the deposit, a built-in spam-and-griefing brake. This is [fully on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) in its purest form: passed proposals can change chain parameters, upgrade the binary, and move community-pool funds without any off-chain multisig standing between the vote and execution — the [coin-voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) model taken to the base layer.

## 2026: the COSMOSIS merger debate

Osmosis's on-chain governance was tested in the open in 2026 by **COSMOSIS** — a proposal, first posted to the [Cosmos Hub forum](https://forum.cosmos.network/t/proposal-draft-acquisition-and-merger-of-osmosis-into-the-cosmos-hub-aka-cosmosis/16717) on 11 March 2026, to acquire and fold Osmosis into the Cosmos Hub, converting circulating OSMO into ATOM at a fixed rate and unifying the two chains' liquidity, security, and governance. Cosmos Hub governance **narrowly rejected it in April 2026** — a tight vote in which the community judged the buyout price too high — and OSMO later [spiked ~185%](https://crypto.news/osmosis-surges-185-as-cosmosis-merger-debate-returns/) in May on speculation the debate would return. It is a live case study in what it means for a DEX to be a sovereign chain: its future was decided not by a founding team or a board, but by two token-holder electorates voting against each other on-chain.

## How Caper approaches this

Osmosis shows the appeal of fully on-chain governance — no multisig between the vote and the code — but also its ceiling: voting power is _stake-weighted coin voting_, where a large passive OSMO balance carries proportional weight whether or not its holder ever engages. [Caper](/wiki/foundations/what-is-a-caper) keeps the on-chain settlement and adds a participation term. A member's [vote weight](/wiki/governance/voting) is the canonical `(t · v) / (V · T)`: holdings _t_ multiplied by that member's realized voting activity _v_, normalized by total supply and total votes. A big bag alone can't capture control — it has to be a bag that actually shows up. Osmosis and Caper agree that governance belongs on-chain; they differ on whether tokens or _engaged_ tokens should steer it.

## References

- [Osmosis Docs](https://docs.osmosis.zone/) — protocol overview, features, and OSMO
- [The OSMO Token](https://docs.osmosis.zone/learn/osmo/) — supply cap, Thirdening, taker fees, burns
- [ProtoRev](https://docs.osmosis.zone/learn/features/protorev/) — in-protocol MEV capture
- [OSMO Token Distribution](https://medium.com/osmosis/osmo-token-distribution-ae27ea2bb4db) (Osmosis Labs) — genesis split and Fairdrop
- [Cosmos SDK — x/gov module](https://docs.cosmos.network/sdk/latest/modules/gov/README) — on-chain governance mechanics
- [COSMOSIS merger proposal](https://forum.cosmos.network/t/proposal-draft-acquisition-and-merger-of-osmosis-into-the-cosmos-hub-aka-cosmosis/16717) — Cosmos Hub governance forum

## PancakeSwap (CAKE)

URL: https://caper.network/wiki/daos/dexs/pancakeswap
Updated: 2026-08-06

| Project | PancakeSwap |
| --- | --- |
| Token | CAKE (governance + utility) |
| Category | Decentralized exchange (AMM) DAO |
| Chains | Multichain (BNB Chain-led); ~12 networks |
| Governance | Off-chain, CAKE-balance-weighted voting on [Snapshot (cakevote.eth)](https://snapshot.org/#/cakevote.eth); [forum](https://forum.pancakeswap.finance/) discussion; multisig execution |
| CAKE supply | Hard-capped at 400M (cut from 450M, Jan 2026); net-deflationary since 2023 |
| Founded | 2020 |
| Website | [pancakeswap.finance](https://pancakeswap.finance/) |

**PancakeSwap** is the DAO behind one of DeFi's highest-volume decentralized exchanges and the flagship trading venue of [BNB Chain](https://www.bnbchain.org/). Launched in 2020 as an automated market maker (AMM), it has grown into a multi-product platform — spot swaps, perpetual futures, a [price-prediction](https://docs.pancakeswap.finance/products/prediction) market, lotteries, and token launchpads — spanning roughly a dozen chains, with the large majority of its liquidity still on BNB Chain ([DefiLlama](https://defillama.com/protocol/pancakeswap)). Its [CAKE](https://docs.pancakeswap.finance/protocol/cake-tokenomics) token carries both fee utility and governance rights.

What makes PancakeSwap a distinct entry in this directory is not its size but its governance _reversal_. Where [Curve](/wiki/daos/dexs/curve-dao) and [Aerodrome](/wiki/daos/dexs/aerodrome-finance) doubled down on [vote-escrow (ve) tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) — locking tokens for gauge-directed emissions — PancakeSwap adopted the same model and then dismantled it, using CAKE-weighted votes to strip out veCAKE, cap its own supply, and turn the token deflationary. It is a rare, well-documented case of a DAO governing its way _out_ of an incentive design.

## How CAKE governs

PancakeSwap decisions are made through off-chain [governance](https://docs.pancakeswap.finance/protocol/voting): any holder can vote on proposals in the [cakevote.eth](https://snapshot.org/#/cakevote.eth) space on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), with voting power set by a snapshot of their CAKE balance at the block the proposal is posted — a textbook case of [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting). Discussion happens first on the [governance forum](https://forum.pancakeswap.finance/); approved proposals are then carried out by the core team and its multisig.

By proposal count, PancakeSwap is among the most active DAOs on Snapshot. That activity is not always frictionless: its earlier ve-model made voting power itself a market. Ahead of a 2024 proposal, roughly half of all CAKE voting power was reported to have been accumulated by a single participating entity, an episode that underscored how [vote markets and concentration](/wiki/dao-governance/concepts/voting/vote-markets) shadow token-weighted governance ([Protos](https://protos.com/pancakeswap-wars-half-of-cake-voting-power-snapped-up-before-new-proposal/)).

## Tokenomics 3.0: retiring vote-escrow

In April 2025 PancakeSwap implemented [CAKE Tokenomics 3.0](https://forum.pancakeswap.finance/t/cake-tokenomics-proposal-3-0-true-ownership-simplified-governance-and-sustainable-growth/1237), retiring veCAKE, gauge voting, CAKE staking, and revenue-sharing in favor of what it framed as "true ownership" — holding CAKE, rather than locking it, became the basis for exposure. Daily emissions were cut sharply, from roughly 40,000 CAKE per day to about 22,250 ([ChainPlay](https://chainplay.gg/blog/pancakeswap-launches-cake-3-with-major-governance-overhaul/)), with the remaining emissions redirected toward high-volume, real-use pools.

The move was contentious precisely because ve-locking is the dominant DEX-governance template. PancakeSwap had itself only [launched veCAKE in late 2023](https://www.theblock.co/post/263974/pancakeswap-proposes-launching-vecake-system); retiring it barely a year later made the protocol a live test of whether stripping vote-escrow simplifies governance or surrenders the emission-steering that [liquidity-directing](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) DAOs prize.

## A deflationary token, decided by vote

PancakeSwap runs a [buy-back-and-burn](https://dune.com/pancakeswap/PancakeSwap-CAKE-Tokenomics) engine funded from protocol revenue — a share of spot trading fees (15–23%), 20% of perpetual-trading profits, 100% of launchpad fees, 3% of each prediction round, and 20% of CAKE played in lotteries ([CAKE Tokenomics docs](https://docs.pancakeswap.finance/protocol/cake-tokenomics)). Combined with the reduced emissions, this has kept CAKE net-deflationary for over 30 consecutive months.

Governance has repeatedly tightened the ceiling. After capping a once-uncapped supply, holders voted in [2023](https://cryptopotato.com/pancakeswaps-new-proposal-aims-to-cap-cake-supply-at-750-million/) to fix a maximum, and in January 2026 a Snapshot vote — over 1.66 million votes, effectively unanimous — cut the hard cap again from 450M to 400M CAKE ([AMBCrypto](https://ambcrypto.com/pancakeswap-tightens-cake-supply-ceiling-following-tokenomics-overhaul/)). The reforms locked in explicit targets: at least ~4% annual net deflation and a ~20% reduction in total supply by 2030 ([CryptoNinjas](https://www.cryptoninjas.net/news/pancakeswap-3-0-tokenomics-proposes-20-cake-supply-cut-by-2030/)). Few DAOs have used their vote so directly to reprice their own float.

## Products and scale

The exchange spans classic v2 and concentrated-liquidity v3 AMMs plus [PancakeSwap Infinity](https://docs.pancakeswap.finance/), a modular, hooks-based architecture launched in 2025. Around this sit perpetual futures, the prediction market, lotteries, and [IFO](https://docs.pancakeswap.finance/products/ifo-initial-farm-offering) token launches. By TVL it holds roughly $2B, distributed across about a dozen chains but concentrated on BNB Chain ([DefiLlama](https://defillama.com/protocol/pancakeswap)). Reported quarterly trading volume has reached record highs, and the protocol has cited an all-time peak above 11 million users ([The Defiant](https://thedefiant.io/news/defi/pancakeswap-posts-record-usd749-billion-in-q3-trading-volumes)).

That reach is why its governance choices matter beyond BNB Chain: PancakeSwap is large enough that its abandonment of vote-escrow is a data point every [DEX DAO](/wiki/daos/dexs/uniswap-dao) weighing the same design now has to reckon with.

## How Caper approaches this

PancakeSwap shows off-chain governance producing real outcomes — capping supply, cutting emissions — but the vote is a _signal_: a Snapshot tally that a core team and multisig then act on. The decision and its execution are separated, and holders have to trust that the second step follows the first.

A [caper](/wiki/foundations/what-is-a-caper) closes that gap by making the vote itself the executor. Proposals run on-chain, and a passed proposal moves the treasury directly through [on-chain execution](/wiki/governance/execution) — payouts, investments, and governance actions settle from the vote, not from a human interpreting it afterward. And a holder who dislikes where a caper is heading does not have to win a supply vote to get out: they can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) at any time for a treasury share sized by their canonical vote weight rather than by token balance alone. The lever PancakeSwap holders reach for through repeated Snapshot campaigns — reshaping the token's economics — is, in a caper, the default state of the machinery.

## SushiSwap (SUSHI DAO)

URL: https://caper.network/wiki/daos/dexs/sushiswap-dao
Updated: 2026-07-18

| Name | SushiSwap (Sushi) |
| --- | --- |
| Type | Protocol DAO – decentralized exchange / AMM |
| Governance token | SUSHI (staked as xSUSHI) |
| Launched | August 2020, as a fork of [Uniswap](https://uniswap.org) |
| Governance | Off-chain [Snapshot](https://snapshot.org) voting + on-chain multisig execution; an elected "Head Chef" |
| Status | 🟢 Active |
| Links | [sushi.com](https://www.sushi.com) · [forum](https://forum.sushi.com) · [docs](https://docs.sushi.com) |

**SushiSwap** is a multi-chain decentralized exchange (DEX) governed by the holders of its **SUSHI** token. It is one of the most-studied DAOs in DeFi – less for its technology, which began as a near-verbatim clone of [Uniswap](/wiki/daos/dexs/uniswap-dao), than for the string of governance crises it has worked through: an anonymous founder who controlled the treasury, a funding shortfall that forced the DAO to switch off holder rewards, an SEC subpoena, and a 2024 restructuring that critics read as a nominally-decentralized protocol handing its treasury back to insiders. For a wiki about how DAOs succeed and fail, Sushi is a case study in most of the ways the governance layer comes under strain.

## Origins: the vampire attack

SushiSwap launched in August 2020 as a fork of Uniswap V2's contracts, adding the one thing Uniswap then lacked: a governance-and-reward token. Its go-to-market was the canonical _[vampire attack](https://finematics.com/vampire-attack-sushiswap-explained/)_ – it paid SUSHI emissions to users who deposited their Uniswap LP tokens into SushiSwap, then migrated that liquidity, [on the order of a billion dollars](https://thedefiant.io/news/defi/sushiswaps-vampire-scheme-hours-away-and-with-1-3b-at-stake), across to its own pools. It remains the textbook example of bootstrapping a protocol by draining a competitor's liquidity with token incentives.

The protocol was built by a pseudonymous developer known only as **Chef Nomi**. Days after the migration, Chef Nomi [sold the entire development-fund allocation](https://finematics.com/vampire-attack-sushiswap-explained/) – roughly 10% of emissions, about $14 million in ETH, a pool the founder unilaterally controlled – and the SUSHI price collapsed. After a community backlash the founder returned the funds and handed control to others, notably co-founder **0xMaki**. The episode is the archetypal DAO custody failure: a single anonymous key holding money the "community" believed was theirs.

## Governance structure

SUSHI is the governance token; staking it mints **xSUSHI**, which historically carried both a [share of protocol fees and voting weight](https://www.sushi.com/blog/breaking-down-the-sushi-tokenomics). Day-to-day decisions run through off-chain [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) polls debated on the [Sushi forum](https://forum.sushi.com), with execution carried out by a core multisig – the same [off-chain-vote / trusted-execution split](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) most large DAOs use.

The protocol is nominally led by an elected **Head Chef**. In a Snapshot election that closed on 3 October 2022, [Jared Grey won the role with roughly 83% of the vote](https://www.coindesk.com/business/2022/10/03/sushiswap-community-votes-in-head-chef-to-oversee-decentralized-crypto-exchange) – over 11 million SUSHI – after months of leadership turmoil. Electing a de-facto CEO is itself a telling move for a "decentralized" exchange, and the tension between that role and token-holder control runs through everything that followed.

## The treasury runway crisis and Kanpai

By late 2022 the DAO's finances were a live problem: Grey warned holders the treasury had [roughly 1.5 years of runway](https://www.coindesk.com/tech/2023/01/24/defi-protocol-sushi-passes-two-governance-votes-to-strengthen-treasury) at the prevailing burn rate. The DAO's lever for this is **Kanpai** – a switch that diverts a share of xSUSHI fee revenue to the treasury instead of to stakers. Across December 2022 and January 2023 votes it was cranked from 10% [to 100%](https://www.coindesk.com/tech/2023/01/24/defi-protocol-sushi-passes-two-governance-votes-to-strengthen-treasury), cutting off xSUSHI holder rewards for a year to refill the war chest.

A later fees-to-treasury vote passed, but The Block described the outcome bluntly as [“a fight between whales”](https://www.theblock.co/post/196213/sushi-dao-votes-to-send-all-fees-to-treasury-but-it-was-a-fight-between-whales) – a handful of large holders decided it. That is the recurring failure mode of [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), and a core input into [how DAO treasuries actually get managed](/wiki/dao-governance/concepts/treasury/dao-treasury-management) under pressure.

## Regulatory pressure

In March 2023 the U.S. SEC served SushiSwap and Head Chef Jared Grey with a [subpoena](https://decrypt.co/124133/sushiswap-dao-subpoena-sec-legal-defense-fund). Grey proposed a DAO-funded [legal defense fund](https://blockworks.co/news/sushiswap-served-by-sec) – $3 million in USDT, with a further $1 million contingency – drawn straight from the treasury. It surfaced an uncomfortable question that most token-governed protocols eventually face: should a "decentralized" DAO's holders collectively bankroll the legal defense of its de-facto leadership, and do they have any real say if the whales vote yes?

## Sushi Labs and the recentralization debate

Through 2024 Sushi restructured. A new operating entity, **Sushi Labs**, was created to run product and operations, [governed by non-transferable shares](https://www.theblock.co/post/178658/sushiswap-weighs-new-dao-structure-that-uses-non-transferable-shares) rather than open token votes, and the DAO [moved tens of millions in treasury assets under its control](https://invezz.com/news/2024/04/10/sushiswap-sushi-dao-treasury-proposal-passes-amid-wallets-creation-controversy/). Supporters framed it as an escape from governance paralysis; critics saw a protocol that markets itself as community-owned handing its treasury and its decisions to an insider entity – the [progressive-decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) arc running in reverse.

Operationally the protocol kept shipping: Grey has said Sushi reached profitability in 2024 and is building out a multi-product line, including the Blade AMM and an integration with the Katana DeFi chain. Whether that product momentum is worth the governance concessions is exactly the trade the wiki tracks in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## How Caper approaches this

Two of SushiSwap's recurring problems – an insider entity controlling the treasury, and holders whose only recourse when they disagree is to sell into a thin market – are the exact conditions a [Caper](/wiki/foundations/what-is-a-caper) is built around. In a Caper the treasury is not held at a foundation's or a labs entity's discretion: any holder can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) and redeem their share of it directly from the contract ([the exit right](https://caper.network/blog/the-exit-right)), so control cannot quietly migrate away from the people who funded it. And [vote weight](/wiki/governance/voting) blends holdings with participation rather than letting a few large wallets settle every question. It is an outcome-level answer to the same failure modes Sushi has spent years patching by governance vote.

## See also

- [Uniswap DAO](/wiki/daos/dexs/uniswap-dao) – the DEX SushiSwap forked, and the target of its vampire attack.
- [Curve DAO](/wiki/daos/dexs/curve-dao) – the other AMM whose token-weighted governance is dominated by large holders.
- [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) · [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) · [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting)

## Synthetix (SNX)

URL: https://caper.network/wiki/daos/dexs/synthetix
Updated: 2026-07-21

|  |  |
| --- | --- |
| **Name** | Synthetix |
| **Type** | Protocol DAO (on-chain derivatives / synthetic-asset liquidity layer) |
| **Governance token** | SNX — staked to back protocol liquidity and to elect the councils that govern the protocol |
| **Product** | A liquidity layer for perpetual futures and synthetic assets; SNX stakers historically minted the sUSD stablecoin against staked collateral |
| **Governance model** | **Elected representative councils.** SNX stakers do not vote on every parameter — they elect a 7-seat [Spartan Council](https://www.synthetix.io/governance) that executes changes via a 4/7 multisig |
| **Founded** | 2018 (launched as Havven; rebranded Synthetix) |
| **Status** | 🟢 Active |
| **Notable for** | Being DeFi’s canonical _elected-council_ DAO — regular on-chain elections choose a small signing body, rather than putting every proposal to a direct token vote |

**Synthetix** is one of DeFi’s oldest and longest-running DAOs, and its most distinctive contribution to governance design is organizational rather than financial: instead of asking every token holder to vote on every change, it asks them to _elect a small council_. That council — the [Spartan Council](https://www.synthetix.io/governance) — holds the keys and executes upgrades and treasury spends through a multisig. Synthetix is therefore the reference example of **representative** DAO governance, sitting between direct token voting ([Aave](/wiki/daos/lending/aave-dao), Compound) and validator-weighted chain governance ([dYdX](/wiki/daos/dexs/dydx)).

The protocol began in 2018 as Havven before rebranding to Synthetix. For most of its life the core mechanic was _pooled-collateral synthetic assets_: SNX holders staked their tokens as collateral and minted the sUSD stablecoin, and the staked SNX backed a shared pool of on-chain synthetic assets. In 2025–2026 the DAO voted to retire that model, launching a perpetual-futures exchange on Ethereum mainnet in December 2025 and moving toward exchange-driven revenue.

## The Spartan Council: elected, not direct

Synthetix is governed by the **Spartan Council**, a body of **7 seats**. Each election cycle, **4 of the 7 seats** are elected by SNX stakers; the remaining seats comprise **3 advisory seats** (continuity and external perspective) and **1 treasury seat** that is a required signer of all treasury transactions. Any governance proposal or treasury movement needs **4 of 7 signatures** to execute, per the [January 2026 elections announcement](https://blog.synthetix.io/synthetix-elections-january-2026/).

Historically the model ran _multiple_ councils with separated remits — a **Treasury Council** managing the treasury and funding the other bodies, and an **Ambassador Council** advocating for Synthetix across the wider Ethereum/DeFi ecosystem (see the community-maintained [guide to Synthetix governance](https://medium.com/@SynthetixGrants/a-community-guide-to-synthetix-governance-80dbaa072499)). This deliberate split of powers into elected, separately-accountable councils is what makes Synthetix distinct from a single token-house.

Elected members receive a monthly stipend from the treasury (2,000 SNX per member per the [January 2026 post](https://blog.synthetix.io/synthetix-elections-january-2026/)) — governance work is a paid, term-limited role rather than volunteer labor.

## Elections and the 420 pool

Councils are re-elected on a fixed **6-month cadence, every January and July**. The [January 2026 election](https://blog.synthetix.io/synthetix-elections-january-2026/) ran a 5-day voting window (26–30 January) on a Snapshot vote open to SNX stakers. Crucially, voting eligibility is tied to staking: only SNX staked in the **420 pool** before voting opens can be voted with. Staking, liquidity provision, and the right to elect the council are bound together in the same act.

Fixed-term elections are the accountability mechanism that a representative model needs. Because the whole council turns over on a predictable schedule, stakers who dislike the direction do not have to wait for a specific proposal — they replace the decision-makers at the next epoch.

## The SIP process

Protocol changes move through **Synthetix Improvement Proposals (SIPs)**, with treasury spends handled as **Synthetix Treasury Proposals (STPs)**. A change starts as a written SIP in the public [SIP repository](https://sips.synthetix.io/), is reviewed and refined in the open, and is then put to the Spartan Council; a 4/7 council vote authorizes execution. The written-proposal-then-council-vote pipeline gives the elected body a concrete, auditable mandate for each action rather than a blanket authority.

Two recent SIPs show how far a council mandate can reach:

- [SIP-420 (“the 420 Pool”)](https://sips.synthetix.io/sips/sip-420/), implemented January 2025, replaced individual SNX staking with a **protocol-owned debt pool** — a form of _delegated staking_. Stakers move their debt positions (not their collateral) into a single pooled contract over a 12-month transition; the pool runs at a **200% issuance ratio** versus a punitive **1000%** for solo stakers, and early exits carry a penalty that decays linearly from 100% to 50% over the transition.
- [SIP-423](https://sips.synthetix.io/sips/sip-423/) voted to **retire sUSD** and pay holders in vested SNX, alongside SNX and sUSD buybacks aimed at restoring the peg — a wholesale change to the protocol’s economic model, ratified through the same council pipeline ([Crypto Briefing](https://cryptobriefing.com/synthetix-retires-susd-snx-conversion/)).

## Why the elected-council model matters for DAOs

Direct token voting has two chronic failure modes: [voter apathy](/wiki/dao-governance/concepts/fundamentals/governance-minimization) (most holders never vote, so a small active minority decides everything) and whale dominance (one large bag can carry a proposal). Synthetix’s answer is to _separate the electorate from the executive_: holders vote rarely — only to choose a council — and a small, named, term-limited body does the day-to-day governing under a multisig. This buys execution speed and clear accountability, at the cost of concentrating power between elections and introducing council-capture and low-turnout risks of its own.

It is a genuinely different point in the design space from the [vote-escrow](/wiki/daos/dexs/curve-dao) and [futarchy](/wiki/dao-governance/concepts/voting/futarchy) approaches, and worth studying precisely because it has run real elections, on a fixed cadence, for years.

## How Caper approaches this

Caper does not use an elected council. Governance weight is **direct and continuous**: a member’s weight on any decision is a smooth function of both the tokens they hold and the votes they have earned — in the contract, `compute_vote_weight = (held × votes) / (supply × circulation)` — so there is no representative layer to elect or capture, and a large bag alone cannot capture control without earned votes. Proposals are typed at execution (a spend, an investment, or an executive action) rather than filtered through a standing council.

Where Synthetix uses _periodic elections_ as its accountability mechanism, Caper uses the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): if you dislike the direction, you redeem at a formula-fixed price instead of waiting for the next election to vote a council out. See [what is a caper](/wiki/foundations/what-is-a-caper), [proposals](/wiki/governance/proposals), and [raising funds](/wiki/markets/raising-funds).

## References

- [Synthetix — Governance](https://www.synthetix.io/governance) (Spartan Council, 4/7 signing)
- [Synthetix Elections, January 2026](https://blog.synthetix.io/synthetix-elections-january-2026/) (seat structure, cadence, 420-pool voting, stipend)
- [SIP-420: the 420 Pool / protocol-owned debt](https://sips.synthetix.io/sips/sip-420/)
- [SIP-423: sUSD retirement & staking reform](https://sips.synthetix.io/sips/sip-423/)
- [Synthetix Improvement Proposals (SIP) repository](https://sips.synthetix.io/)
- [A Community Guide to Synthetix Governance](https://medium.com/@SynthetixGrants/a-community-guide-to-synthetix-governance-80dbaa072499) (Treasury & Ambassador councils)

## THORChain (RUNE)

URL: https://caper.network/wiki/daos/dexs/thorchain
Updated: 2026-07-24

| Project | THORChain |
| --- | --- |
| Token | RUNE (settlement, bond & incentive asset); TCY (revenue-share, non-governance) |
| Category | Cross-chain native-asset DEX / node-operated protocol |
| Chains | Own Cosmos-SDK L1 settling native BTC, ETH, BNB, SOL, DOGE, and more — no wrapped or bridged assets |
| Governance | Node-operator-only via the [Mimir](https://docs.thorchain.org/network-security-governance) parameter-voting system (no token-holder vote); ADRs for larger changes |
| RUNE supply | ~425M total (net-deflationary via fee burn); ~350M circulating, ~75M reserve |
| Founded | 2018 (multichain mainnet 2021) |
| Website | [thorchain.org](https://thorchain.org) |

**THORChain** is a decentralized cross-chain liquidity protocol that lets users swap [native assets](https://docs.thorchain.org/) — real BTC for real ETH, ETH for native SOL — without wrapping, bridging, or trusting a custodian. It is not an app on someone else's chain: THORChain runs its own [Cosmos-SDK](https://cosmos.network/) Layer-1 whose validators (THORNodes) watch external chains, hold assets in threshold-signed vaults, and settle every trade through pools paired against its native token, [RUNE](https://docs.thorchain.org/tokenomics-rune-tcy). That architecture makes it a structurally distinct entry in the DEX directory alongside the on-chain AMMs ([Curve](/wiki/daos/dexs/curve-dao), [Uniswap](/wiki/daos/dexs/uniswap-dao)) and aggregators ([Jupiter](/wiki/daos/dexs/jupiter)): its governance and its treasury risk both live at the _node-operator_ layer, not in a token vote.

## Native cross-chain swaps

Every asset THORChain supports sits in a **Continuous Liquidity Pool** paired against RUNE — a BTC–RUNE pool, an ETH–RUNE pool, and so on. A BTC→ETH swap is really two hops through RUNE (BTC→RUNE→ETH), which is why RUNE is described as the network's [settlement asset](https://docs.thorchain.org/tokenomics-rune-tcy): it is present in every pool and every trade, giving the token constant, activity-driven demand rather than a purely speculative one.

Custody is handled by a **Threshold Signature Scheme (TSS)**. No THORNode ever holds a complete vault key; each holds a fragment, and only a supermajority (≈⅔) of nodes combining fragments can sign an outbound transaction. Vaults are [regularly churned](https://docs.thorchain.org/network-security-governance) — active nodes rotate in and out on a cycle — so no fixed group can capture the network or its funds. This is the same reason THORChain has no admin multisig that can move user assets: there is no full key to hold.

## Governance: Mimir, not a token vote

THORChain's governance is unusual and worth stating plainly: **RUNE is not a governance token, and TCY explicitly confers no voting rights.** Protocol decisions are made by active THORNode operators through [Mimir](https://docs.thorchain.org/network-security-governance), a system for voting network parameters directly.

- **Operational parameters** — quick, low-stakes settings — activate on a small number of node votes (typically 3+), and can be flipped: 4 nodes overturn, 5 re-activate, and so on.
- **Economic parameters** — anything touching the money — require **supermajority consensus (~⅔ of validators)**, the same threshold that guards the vaults.

To become a validator at all, an operator must **bond RUNE as collateral** — currently over 300,000 RUNE per node. Misbehaviour is slashed against that bond, so the right to vote is bought with capital genuinely at risk. Larger architectural changes go through **Architecture Decision Records (ADRs)** debated by node operators and contributors. The result is a governance body that is fast and Sybil-resistant, but also small, technical, and closed to ordinary token holders — a deliberate trade-off very different from the balance-weighted [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow) models used elsewhere in the directory.

## RUNE tokenomics & the Incentive Pendulum

RUNE has [no vesting schedules or locked allocations](https://docs.thorchain.org/tokenomics-rune-tcy) — the full supply is released, and a portion of fees is burned, so circulating supply trends down over time (~425M total, ~350M circulating, ~75M reserve). Rewards to nodes and liquidity providers come from [real fee revenue](https://docs.thorchain.org/tokenomics-rune-tcy) (on the order of $50,000–$100,000/day), not new emissions.

Security is anchored by a target ratio: total **bonded RUNE ≈ 2× the value of all non-RUNE assets in the pools**. If liquidity outgrows security the network becomes attackable; if bonded RUNE dwarfs liquidity it is capital-inefficient. The **[Incentive Pendulum](https://docs.thorchain.org/network-security-governance)** continuously re-weights rewards between nodes and LPs to steer the system back toward that 2:1 target — an automatic economic governor sitting under the human Mimir votes.

## The ThorFi debt crisis and TCY

THORChain is also one of DeFi's most instructive case studies in [governance under stress](/wiki/dao-governance/concepts/analysis/how-daos-fail). Its lending and savers products (“ThorFi”) accrued liabilities the protocol could not cover — roughly **$200M+ of RUNE-denominated debt**. In early 2025 node operators **paused the network** and voted on a restructuring rather than papering over the hole by inflating RUNE.

The resolution was a debt-to-equity conversion: a new token, **TCY (THORChain Yield)**, was issued at **1 TCY per $1 of debt** (fixed supply 210M), turning creditors into revenue-share holders instead of writing them to zero. TCY holders receive [10% of all network revenue](https://docs.thorchain.org/tokenomics-rune-tcy) paid in RUNE, with a RUNE/TCY pool for liquidity. Crucially, TCY was designed as a pure income instrument — it [does not grant governance rights](https://docs.thorchain.org/tokenomics-rune-tcy). Creditors got a claim on cash flow; the votes stayed with the bonded nodes.

## 2026 exploit and the governance response

On **15 May 2026** a newly-churned node operator exploited a vulnerability in the [GG20 signature scheme](https://blog.thorchain.org/thorchain-exploit-report-1) and drained roughly **$10.7M from one of five vaults**. The response is a clean illustration of how a node-operated protocol governs an emergency: automatic solvency checks halted signing and trading within minutes without human intervention, then operators coordinated over Discord — stacking manual pauses and casting formal Mimir votes — to bring the whole network to a controlled halt within about two hours. The other four vaults were untouched, and the network absorbed the loss from protocol-owned reserves rather than minting fresh RUNE. Recovery of the lost funds was routed to community governance via [ADR-028](https://blog.thorchain.org/thorchain-exploit-report-1). Trading resumed after a multi-week pause once patched.

## How Caper approaches this

THORChain draws a hard line most DAOs blur: the people who provide the capital (RUNE bonders) hold the votes, while the people owed money (TCY holders) get a cash-flow claim and _no say at all_. It is clean, but it means an ordinary holder's only real lever if they disagree with the operators is to sell into the open market.

[Caper](/wiki/foundations/what-is-a-caper) keeps holdings and voice on the same instrument, and adds a second lever THORChain's TCY holders never had — a canonical **[exit right](/blog/the-exit-right)**. A caper's token holders both [vote](/wiki/governance/voting) and, if they reject where the treasury is heading, can redeem their share of the reserve. Voting power is the canonical weight `w = (t·v)/(V·T)` — a holder's tokens times their own votes over total votes and circulating supply — so influence tracks both stake and participation, verified against the contract's `compute_vote_weight`. The point isn't that THORChain's model is wrong for a cross-chain settlement layer; it's that when a treasury restructures, giving holders a governed _exit_ rather than only a revenue token changes who bears the downside.

## References

- [THORChain Docs — Network Security and Governance (Mimir, bonding, TSS, churn, Incentive Pendulum)](https://docs.thorchain.org/network-security-governance)
- [THORChain Docs — Tokenomics of RUNE and TCY](https://docs.thorchain.org/tokenomics-rune-tcy)
- [THORChain Blog — Exploit Report #1 (15 May 2026)](https://blog.thorchain.org/thorchain-exploit-report-1)
- [THORChain — official site](https://thorchain.org)

## Uniswap DAO

URL: https://caper.network/wiki/daos/dexs/uniswap-dao
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Name** | Uniswap DAO |
| **Type** | Protocol DAO (decentralized exchange) |
| **Governance token** | UNI (airdropped September 2020) — [0x1f98…F984](https://eth.blockscout.com/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain voting via Governor Bravo + delegation |
| **Governor** | [GovernorBravoDelegator 0x408E…24C3](https://eth.blockscout.com/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3) → [Timelock 0x1a9C…35BC](https://eth.blockscout.com/address/0x1a9C8182C09F50C8318d769245beA52c32BE35BC) |
| **Quorum** | 40,000,000 UNI — a compile-time constant, not a percentage |
| **Proposal threshold** | 1,000,000 UNI; voting delay 13,140 blocks, voting period 40,320 blocks |
| **Total supply** | 1,000,000,000 UNI, unchanged since genesis (no token has ever been minted or destroyed) |
| **Treasury** | 267,247,996.31 UNI held by the Timelock at Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z) |
| **Notable for** | Largest governance-token holder base; the multi-year "fee switch" debate, resolved by the 2025 UNIfication vote |
| **Primary sources** | [gov.uniswap.org](https://gov.uniswap.org/), [docs.uniswap.org](https://docs.uniswap.org/), [Agora voting portal](https://vote.uniswapfoundation.org/), [the Governor on-chain](https://eth.blockscout.com/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Curve DAO](/wiki/daos/dexs/curve-dao), [Compound DAO](/wiki/daos/lending/compound-dao), [ENS DAO](/wiki/daos/infrastructure/ens-dao) |

The **Uniswap DAO** governs [Uniswap](https://uniswap.org/), the largest decentralized exchange (DEX) on Ethereum and one of the most-used protocols in DeFi. Control over the protocol's parameters, its treasury, and its on-chain fee mechanism rests with holders of the **UNI** governance token, who decide by [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain vote. With one of the largest token-holder bases of any [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), Uniswap governance is widely treated as the archetypal protocol DAO.

Uniswap is also one of the few DAOs whose whole record is legible from the chain: the ballots, the quorum rule, the treasury, the fee switch and the burn are all on Ethereum mainnet and all readable without an API key. The sections below distinguish what the governance record actually shows from what it is usually reported to show. Every number is read at Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z) or taken from deployed, verified source.

## Origins and the UNI airdrop

UNI launched in September 2020 with a retroactive airdrop of 400 tokens to every address that had ever used the protocol — an early, widely-copied template for distributing governance power to users rather than selling it (see [airdrops and token distribution](/wiki/economics/airdrops-and-token-distribution)). The token conferred the right to govern the Uniswap protocol, its governance-controlled treasury, and a community fund, with day-to-day stewardship of grants and ecosystem work delegated over time to the Uniswap Foundation. ([Uniswap governance overview](https://docs.uniswap.org/concepts/governance/overview))

## The fee switch debate

For years Uniswap's defining governance question was the **"fee switch"**: the protocol earned no revenue for the DAO because trading fees went entirely to liquidity providers, while UNI conferred votes but no claim on cash flow. Whether — and how — to divert a fraction of fees to the protocol and its token holders was debated repeatedly on the [governance forum](https://gov.uniswap.org/), entangled with the legal risk that turning UNI into a value-accruing asset might strengthen the case that it is a security. The general pattern is covered on [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual).

## UNIfication (2025–2026)

The debate was resolved by the **UNIfication** proposal, which passed on 25 December 2025 — the most consequential vote in the protocol's history. It activates a protocol fee that routes a portion of trading fees into a contract (the "token jar") and lets anyone burn UNI to withdraw an equivalent value (via a "fire pit" burn mechanism), and it executed a retroactive burn of 100,000,000 UNI — about $590 million at the time — approximating what would have accrued had the fee been live since launch. The package also wound down the Uniswap Foundation, moving most of its staff and responsibilities to Uniswap Labs. ([DL News](https://www.dlnews.com/articles/defi/uniswap-dao-to-activate-fee-switch-and-burn-100m-uni-tokens/); [The Defiant](https://thedefiant.io/news/defi/uniswap-passes-unification-fee-switch-proposal))

In early 2026 the DAO carried the fee switch beyond Ethereum. A follow-up package — whose final on-chain votes closed on 4 March 2026 — activated protocol fees across **eight additional chains** (Arbitrum, Base, OP Mainnet, Celo, Soneium, X Layer, World Chain and Zora) from 8 March, routing a share of fees into the same burn mechanism. It also introduced a tier-based fee adapter that automates collection across all Uniswap v3 pools, removing the need for a separate governance vote per pool, for an estimated ~$27 million in additional annualized revenue. By July 2026 protocol fees were live on ten chains beyond mainnet and the mechanism had recorded a single-day high of 186,000 UNI burned; the rollout is tracked on [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual). ([The Block](https://www.theblock.co/post/390456/uniswap-governance-considers-activating-protocol-fees-on-all-v3-pools-expanding-to-eight-additional-chains); [DL News](https://www.dlnews.com/articles/defi/uniswap-price-soars-as-dao-votes-to-flip-fee-switch-on-l2s/))

## What the chain records about UNIfication

UNIfication is **proposal 93** on the Governor. Read straight out of the Governor's `proposals(93)` struct, the record is:

|  |  |
| --- | --- |
| **Voting opened** | block 24,051,216 — 2025-12-20T03:47:23Z |
| **Voting closed** | block 24,091,536 — 2025-12-25T18:49:11Z |
| **For** | 125,342,016.81 UNI |
| **Against** | 742.50 UNI |
| **Abstain** | 1,500,006.69 UNI |
| **Timelock eta** | 1766867543 — 2025-12-27T20:32:23Z |
| **Executed** | [0x091f0083…143d2c1e](https://eth.blockscout.com/tx/0x091f0083242a777d55821c1189e568d6d033d9da501b75087dc736fa143d2c1e), block 24,106,378, 2025-12-27T20:33:11Z |

The tallies circulated in the press are accurate to the token. What the reporting leaves out is the shape of them. The most consequential decision in the protocol's history drew **742.50 UNI of opposition** against 125,342,016.81 in favour — a ratio of about **168,812 to 1** — and 1,500,006.69 UNI that showed up specifically to abstain, more than two thousand times the entire "against" side. Total participation was 126,842,766 UNI: 12.7% of supply, on the vote that redirected the protocol's revenue and dissolved its foundation.

Execution landed **48 seconds** after the [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) eta, in a transaction sent by an ordinary address — anyone may call `execute` once the delay has run, and someone was waiting for it.

## The burn is a transfer, not a reduction in supply

UNI's `totalSupply()` at Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z) is **1,000,000,000.000000000000000000** — exactly the figure minted at deployment in September 2020, to the wei. The 100 million UNI that UNIfication "burned" did not leave that number, because **the UNI contract has no burn function**. Its full external surface is `transfer`, `transferFrom`, `approve`, `permit`, `delegate`, `mint`, `setMinter` and the views; there is no `burn` and no `burnFrom` ([verified source](https://eth.blockscout.com/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984)).

So the burn is a transfer. In the execution transaction the Timelock emitted `Transfer(0x1a9C…35BC → 0x000…dEaD, 100000000000000000000000000)` — 100,000,000 UNI to an address whose private key nobody has and which was never generated from one. The address's UNI balance moved from 49,576.62 to 100,049,576.62 in that single step, which is how the figure can be stated exactly rather than as "roughly 100 million".

The fire pit has kept running since. At Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z) the [burn address](https://eth.blockscout.com/address/0x000000000000000000000000000000000000dEaD) holds **108,347,579.97 UNI** — a further **8,298,003.35 UNI** sent there in the seven and a half months since execution, by holders exchanging tokens for a share of the fee jar. That is **10.83% of all UNI** parked at an address that cannot spend, delegate or vote it, while every "percent of supply" statistic about Uniswap still divides by the unchanged 1,000,000,000.

This is not an accounting quibble unique to Uniswap; it is the normal state of "burns" on tokens that were not written with a burn path, and it is worth checking before repeating a supply figure. What distinguishes Uniswap is scale: the tenth of the supply at the dead address is larger than the entire circulating supply of most DAOs in this directory.

## The mint key is held by the contract that lit the fire pit

UNI can never be destroyed, but it can be created. The token's `mint()` is live, and reading its four state variables at Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z) gives the whole rule:

|  |  |
| --- | --- |
| **`minter()`** | [0x1a9C8182…2BE35BC](https://eth.blockscout.com/address/0x1a9C8182C09F50C8318d769245beA52c32BE35BC) — the governance Timelock |
| **`mintingAllowedAfter()`** | 1704067200 — 2024-01-01T00:00:00Z |
| **`mintCap()`** | 2 (percent of total supply, per mint) |
| **`minimumTimeBetweenMints()`** | 31,536,000 seconds — one year |

Two of these deserve care. First, `minter()` returns the same address as the Governor's `timelock()`: **the contract that executed the burn is the contract that holds the mint key**. The route that removed 100 million UNI from circulation and the route that could issue 20 million more per year are the same governance process, differing only in which proposal passes.

Second, `mintingAllowedAfter` is **1 January 2024**, set as a constructor argument at deployment and never advanced since — and it can only advance by being minted against, because `mint()` sets it to `block.timestamp + minimumTimeBetweenMints` on every call. That it still reads as a date two and a half years past is therefore proof of a negative: **no UNI has ever been minted**, which the unchanged supply independently confirms. The commonly-repeated "four-year mint lock" expired earlier than usually stated, and has been open ever since without being used.

Put the two mechanics together and UNI's supply is one-directional. `mint()` raises `totalSupply`; nothing lowers it. The 108,347,579.97 UNI at the burn address is about **5.4 years** of mint headroom at the 2%-a-year cap — which is not a prediction that governance will re-issue it, but it is the reason "deflationary" is the wrong word for what UNIfication built. Uniswap's holders did not remove the ability to inflate; they voted to move a tenth of the float somewhere unspendable while leaving the issuance switch where it was.

## The burn quietly raised the bar for every future vote

Governor Bravo's quorum is not a percentage. It is a compile-time constant in the deployed [implementation](https://eth.blockscout.com/address/0x53a328F4086d7C0F1Fa19e594c9b842125263026?tab=contract):

`uint public constant quorumVotes = 40000000e18; // 40,000,000 = 4% of Uni`

The comment was true when it was written and is still arithmetically true, because total supply never moves. But 40,000,000 UNI is only 4% of a supply that includes the 108,347,579.97 UNI at the burn address, which cannot vote. Measured against the **891,652,420.03 UNI that can**, the quorum is now **4.486%** — and every fire-pit burn nudges it higher, with no vote taken and no parameter changed. A mechanism designed to return value to holders is also, as a side effect, slowly tightening the [quorum](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) that those holders must clear to govern.

The margin is not theoretical. Proposal 71 closed with 39,102,815.18 UNI in favour against 2,509,749 opposed and failed anyway, **897,184.82 UNI short** of the constant. Four proposals in the Governor's history have failed and all four failed the same way, which is the subject of the next section.

## Ninety-two proposals, and none of them was voted down

The Governor's `proposalCount()` is 100 and its `initialProposalId` is 8, so ids 9–100 — **92 proposals** — are its own record (ids 1–8 belong to the predecessor Governor Alpha). Reading all 92 structs directly gives a census rather than an impression:

|  |  |
| --- | --- |
| **Executed** | 72 |
| **Cancelled** | 16 |
| **Failed at the ballot** | 4 — ids 49, 71, 88, 91 |
| **Defeated by opposition** | 0 |

In all four failures the "for" side beat the "against" side by a wide margin and the proposal died on turnout: id 49 (21,774,717 for / 250,123 against), id 71 (39,102,815 / 2,509,749), id 88 (24,653,700 / 3,024) and id 91 (23,286,362 / 55,016). **No proposal in the Governor's history has ever ended with more UNI against it than for it.** The binding constraint on Uniswap governance has never been disagreement; it has been [getting anyone to show up](/wiki/dao-governance/concepts/analysis/voter-apathy).

Among the 72 that passed, the median "against" total is **159.77 UNI** — roughly two thousand dollars' worth of opposition on the median successful governance action at a multi-billion-dollar protocol. Fifteen of the 72 drew less than 1 UNI against; 41 drew less than 1,000. The single largest opposition ever recorded is proposal 31, with 28,466,755.23 against and 55,880,027.76 for. The most recent, proposal 100 (executed July 2026), drew 1,274,746.48 against 46,604,582.79 for — the first seven-figure opposition in over a year, and a fee-parameter vote rather than a spending one.

This is the empirical shape of [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) at scale, and it is easy to misread in both directions. It is not evidence that proposals are rubber-stamped: the filtering happens earlier, on the [forum](https://gov.uniswap.org/) and in the temperature checks, so contested ideas mostly never reach an on-chain ballot (see [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle)). But it does mean the on-chain vote is close to a ratification step, and that the number worth watching is turnout against a fixed quorum, not the for/against split.

## The other half of the same transaction: the growth budget on-chain

The execution transaction that burned 100 million UNI carried a second token event that received little coverage: an `Approval` of **40,000,000 UNI** from the Timelock to [0xCa046A83…dAc9e1D2](https://eth.blockscout.com/address/0xCa046A83EDB78F74aE338bb5A291bF6FdAc9e1D2?tab=contract), a contract whose verified source names it `UNIVesting` — "a vesting contract that releases UNI tokens quarterly to a designated recipient". This is the on-chain form of the **20 million UNI annual growth budget** that UNIfication created alongside the burn: five million a quarter, four quarters a year, with two years of it approved up front. The proposal's deflationary headline and its issuance commitment were authorised in the same transaction (see [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual)).

Its terms are in the source and its state is readable at Ethereum mainnet block 25,717,629 (2026-08-09T13:09:47Z):

|  |  |
| --- | --- |
| **`quarterlyVestingAmount`** | 5,000,000 UNI |
| **First unlock** | `FIRST_UNLOCK_TIMESTAMP` = 1767225600 — 2026-01-01T00:00:00Z |
| **`lastUnlockTimestamp`** | 1782864000 — 2026-07-01T00:00:00Z |
| **`quartersPassed`** | 0 (nothing currently claimable) |
| **Remaining allowance** | 25,000,000 UNI of the original 40,000,000 |
| **`owner`** | the Timelock — i.e. governance |
| **`recipient`** | 0xaBa63748…029d926f, an externally-owned account carrying no public label |

The three quarterly tranches due on 1 January, 1 April and 1 July 2026 have all been drawn: **15,000,000 UNI has moved**, and 13,999,999.04 of it is still sitting at the recipient address. Five more tranches remain within the current approval. Against the 108,347,579.97 UNI at the burn address, the budget is small — but it runs in the opposite direction, on a schedule, without a further vote.

Two design details are worth noting for anyone reading DAO [vesting](/wiki/economics/token-unlocks-and-vesting) contracts. `withdraw()` is callable by anyone, not just the recipient, which is a convenience rather than a control. And `updateRecipient()` is callable by **the owner or the recipient**, so the beneficiary can reassign the stream to another address without a governance vote — the DAO controls the size of the drip and the allowance behind it, but not, on its own, who ends up receiving it.

## Why it matters

UNIfication marks a broader 2025–2026 shift across DeFi from pure governance tokens toward **value-accruing** ones — tying token worth directly to protocol revenue. It also illustrates a recurring tension in large DAOs: a foundation and a closely-associated development company (here, Uniswap Labs) end up holding much of the operational and governance weight, raising the same centralization questions that play out across the [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) landscape.

The on-chain record sharpens that reading. A vote with 742 UNI against it moved a tenth of the supply to an unspendable address, opened a 40 million UNI stream to one account, and left the mint key exactly where it was — while quietly raising the turnout every future proposal must clear. None of that is hidden; all of it is one `eth_call` away. It is simply not what the headline number describes.

## How Caper approaches this

Uniswap had to retrofit value accrual onto a token that originally carried none, and could only reach a burn by transferring tokens somewhere unreachable. A [caper](/wiki/foundations/what-is-a-caper) settles both questions at construction rather than by vote. Its governance token is minted once, in full, with **no mint role and no burn role** — the supply is fixed at creation and, per the contract's own comment, "even a fully-malicious future logic can never mint or burn the governance token". There is no mint key to leave lying open and no need for a dead address, because there is nothing to reduce.

Caper does take Uniswap's escrow route in one place, and names it as such: tokens migrated from an origin token are deposited into a vault with deliberately no withdrawal primitive — a functional burn, described in the source as exactly that rather than as a supply reduction. The one thing a caper genuinely burns is the ballot: vote tokens are destroyed when a member exits, with the burn role restricted to the immortal state component. And funding flows through an on-chain [bonding curve](/wiki/markets/bonding-curve) into a shared treasury from day one, so a member's economic claim is realized at [exit](/wiki/governance/execution) rather than depending on a later vote to switch revenue on. The mechanics are described neutrally on those Caper pages.

## See also

- [Curve DAO](/wiki/daos/dexs/curve-dao) — the other archetype of DEX governance, where influence is priced in lock duration rather than raw balance.
- [Convex Finance](/wiki/daos/lending/convex-finance) — what happens when a third party accumulates a governance majority in someone else's DAO.
- [SushiSwap (SUSHI DAO)](/wiki/daos/dexs/sushiswap-dao) — forked Uniswap V2 in 2020 and drained its liquidity in the original [vampire attack](https://finematics.com/vampire-attack-sushiswap-explained/).
- [Compound DAO](/wiki/daos/lending/compound-dao) — origin of the Governor Bravo contract Uniswap runs.
- [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) · [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) · [Fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual)

## References

- [Governor Bravo (0x408E…24C3)](https://eth.blockscout.com/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3) and its [implementation source](https://eth.blockscout.com/address/0x53a328F4086d7C0F1Fa19e594c9b842125263026?tab=contract) — proposal structs, `quorumVotes`, `initialProposalId`.
- [UNI token (0x1f98…F984)](https://eth.blockscout.com/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984) — verified source for `mint()`, `totalSupply` and the absent burn path.
- [Execution of proposal 93](https://eth.blockscout.com/tx/0x091f0083242a777d55821c1189e568d6d033d9da501b75087dc736fa143d2c1e) — the 100,000,000 UNI transfer and the 40,000,000 UNI approval, in one transaction.
- [UNIVesting (0xCa04…e1D2)](https://eth.blockscout.com/address/0xCa046A83EDB78F74aE338bb5A291bF6FdAc9e1D2?tab=contract) — verified source and live state of the quarterly stream.
- [Uniswap Governance Forum](https://gov.uniswap.org/) — where proposals originate.
- [Uniswap docs: Governance](https://docs.uniswap.org/concepts/governance/overview).
- [DL News](https://www.dlnews.com/articles/defi/uniswap-dao-to-activate-fee-switch-and-burn-100m-uni-tokens/) — Uniswap DAO to activate the fee switch and burn 100M UNI.
- [The Defiant](https://thedefiant.io/news/defi/uniswap-passes-unification-fee-switch-proposal) — Uniswap passes the UNIfication fee-switch proposal.

## Aragon DAO (ANT)

URL: https://caper.network/wiki/daos/infrastructure/aragon-dao
Updated: 2026-07-29

| Organisation | Aragon DAO / Aragon Association (AA), a Swiss non-profit association |
| --- | --- |
| Token | ANT (Aragon Network Token) — no longer has a role in the project |
| Founded | 2017 ICO, raising [$25 million](https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/) |
| Peak treasury | 86,343 ETH deployed for redemption (reported at the time as ~$155m) |
| Status | **Dissolved.** Redemption closed 2 November 2024; 87% of ANT redeemed |
| Archetype | The DAO framework whose own DAO could not survive its own governance |
| Successor | Aragon Foundation + Aragon OSx (product), no token governance |
| Related | [Aragon (the framework)](/wiki/dao-governance/tooling/frameworks/aragon) · [Rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) · [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) · [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) |

**Aragon DAO** was the on-chain organisation attached to [Aragon](/wiki/dao-governance/tooling/frameworks/aragon), one of the oldest and most influential [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) frameworks — the software that underpinned early on-chain governance for protocols including [Curve](/wiki/daos/dexs/curve-dao) and [Lido](/wiki/daos/staking/lido-dao). Its own governance did not survive. In May 2023 the Aragon Association halted a treasury transfer its token holders had already voted for, describing the holders demanding it as raiders. In November 2023 the Association announced its own liquidation, and on 2 November 2024 ANT holders redeemed the treasury for ETH and the token was retired.

The case is worth studying precisely because Aragon was not a careless project. It was the organisation that built the tooling everyone else governed with, and it still hit the same wall: **when a treasury is worth more than the token that claims it, governance stops being about direction and becomes a claim on assets.** This page records the sequence from primary sources, including the statements of both sides, because the disagreement over what happened is itself the substance.

## The framework and its own organisation

Aragon raised [$25 million](https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/) in a 2017 ICO. The proceeds were held not by a DAO but by the **Aragon Association**, a Swiss non-profit whose board of committee members managed the treasury. As Aragon later put it, since 2017 the treasury had been [held and managed by the Aragon Association](https://blog.aragon.org/the-future-of-aragon-treasury-slated-to-move-into-the-hands-of-ant-token-holders/), with the move on-chain still pending.

This is an ordinary shape — a legal entity holds the money while the protocol decentralizes around it, the pattern described on [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) and [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures). The difficulty is that the ETH raised in 2017 appreciated enormously through two bull markets. By 2023 the treasury was reported at roughly [$200 million](https://www.coindesk.com/business/2023/05/09/aragon-cancels-planned-community-control-of-200m-treasury-amid-battle-with-activist-investors), and the entity holding it was a small board, not the token holders.

## June 2022: the treasury is promised to ANT holders

On **17 June 2022**, ANT holders [voted to move the treasury](https://blog.aragon.org/the-future-of-aragon-treasury-slated-to-move-into-the-hands-of-ant-token-holders/) from the Aragon Association into a Delegated ANT Voting DAO, with a soft deadline of 30 November 2022. Aragon's own announcement framed this as the culmination of the project's arc: the treasury would [move on-chain to be directly governed by ANT Holders](https://blog.aragon.org/the-future-of-aragon-treasury-slated-to-move-into-the-hands-of-ant-token-holders/).

The transfer did not happen on that schedule. Installments were slated to run between November 2022 and February 2023, conditional on a structure deemed safe to deploy. By the time of the dispute, the Association had moved [300,000 USDC](https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/) to the Aragon DAO — a rounding error against a nine-figure treasury.

The gap between the vote and the transfer is the whole story. For roughly a year, ANT carried a governance promise the token could not yet enforce.

## May 2023: the halt, and the word "attack"

The transition began on 2 May 2023. Within days the Aragon Association stopped it and repurposed the Aragon DAO into a grants program. Its [public statement](https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/) described a coordinated **"Risk Free Value (RFV) Raiders"** group, self-described as the **"Vultures of Crypto"**, connected to the earlier dissolution of Rook DAO. In Aragon's account, "in the months leading up to this attack, Arca and the other RFV Raiders were actively stockpiling ANT", and "in the days following the attack, the Raiders began rapidly wrapping their tokens enabling them to reach a majority vote in the Aragon DAO". The Association grounded the halt in duty: "The Aragon Association has the responsibility to allocate Aragon's treasury for its stated social non-profit purpose."

The asset manager named, **Arca**, published its [own account](https://www.ar.ca/blog/dao-dilemmas-unraveling-aragons-governance-controversy) and rejected the framing outright, calling the attack characterisation **"outright false"**. Its position was that "we are token holders (of tokens we bought off the open market), and we want to use" them for governance — and that staking to participate was exactly what Aragon had repeatedly asked holders in Discord to do. Arca noted that before it arrived, wrapped ANT was overwhelmingly held by team-connected addresses. It said it had asked Aragon to continue buybacks it had done before, and denied seeking leadership changes. Its charge was that the Association had overridden a token holder vote by unilateral decision.

_The wiki does not adjudicate the label._ Both facts are undisputed and they sit together uncomfortably: Arca bought a governance token on the open market and voted it, which is what the token was for; and the Association concluded that the resulting majority would liquidate the treasury rather than fund the mission, and used off-chain control to stop it. Whether that is an **attack** or an **exit** depends entirely on whether ANT was ever really a claim on the treasury — a question the token's design left open and no vote could settle. See [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) for where this sits among genuine exploits.

## The RFV mechanic

"Risk-free value" is a term inherited from the [OlympusDAO](/wiki/daos/stablecoins/olympusdao) era: the portion of a treasury that is liquid and durable enough to be treated as a floor under the token. The RFV trade needs only one condition — **a token trading below the per-token value of the treasury it governs.**

When that gap opens, buying the token and forcing a distribution is not vandalism but arithmetic. Any holder acting in their own interest should do it, and the more credible a DAO's promise that holders control the treasury, the more reliably the trade works. This is the trap Aragon walked into: it spent years telling the market that ANT would govern the treasury, which is precisely what made ANT worth buying for people who wanted the treasury rather than the mission.

A DAO facing this has two real options. It can **block the exit**, which is what the Association did, at the cost of conceding that holder control was never binding. Or it can **make exit a formal right** priced in from the start, the [rage-quit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) design pioneered by [MolochDAO](/wiki/daos/public-goods/molochdao), where any member can burn their shares for a pro-rata slice at any time. A DAO with rage-quit cannot be raided for its treasury, because the treasury was never locked in the first place — there is no discount to arbitrage. Aragon had the second option available in the ecosystem it helped build, and had not adopted it for itself.

## November 2023: dissolution

On **2 November 2023** the Aragon Association announced its [full liquidation and dissolution](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/). The reasoning was unusually blunt for a project statement: "the shaky foundations underlying the current structure cannot be fixed and have been holding back the project for too long. **Neither the AA nor ANT are currently suited to govern the project.** A fresh start is needed."

The terms: **86,343 ETH** deployed to a redemption contract, ANT redeemable at a fixed **0.0025376 ETH / ANT** until **2 November 2024, 23:59 UTC** ([redemption portal](https://ant.aragon.org/); reported by [The Block](https://www.theblock.co/post/261179/aragon-association-to-dissolve-itself-provide-liquidity-for-ant-redemption) at the time as roughly $155m). An Aragon Shield Foundation retained **$11m** to "cover outstanding obligations after the AA's dissolution and mitigate against regulatory uncertainty". IP, infrastructure and runway went to a new product-focused structure to continue Aragon OSx.

Read plainly, the dissolution granted the raiders' actual demand — the treasury was returned to token holders in ETH — while denying them the DAO. The disagreement was never about whether ANT holders should get the money. It was about whether they should get it _and_ the steering wheel.

## November 2024: the numbers

Aragon's [final redemption report](https://blog.aragon.org/ant-redemption-initiative-report/) records the outcome:

- **87% of ANT redeemed.**
- **2,670 total redemptions** across ANTv1, ANTv2 and ANJ holders.
- **75,093.99 ETH** redeemed by token holders.
- **11,249.01 ETH** remaining, committed to the new Aragon Foundation — a disposition Aragon attributes to Swiss tax authority requirements, not choice.

Two things stand out. First, **87% took the money** — when a governance token was finally made into a clean claim on assets, the overwhelming majority of it preferred the assets. Second, that 87% moved through only **2,670 redemptions**. A treasury a decade in the making, and the entire holder base that turned up to collect it fits in a mid-sized conference room. Both numbers are difficult to reconcile with the idea that ANT represented a broad community of governors, and they are strong evidence for the pattern described in [DAO metrics and analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics): token holder counts are not participant counts.

ANT no longer has a role in the Aragon project. The software survived its organisation: Aragon OSx development continues under a foundation, funded by the remainder, governed by no token.

## Why it matters

Aragon is the reference case for several failure modes catalogued on [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail), and it is unusually instructive because the organisation involved was the industry's own governance vendor.

- **A vote is not a transfer.** The June 2022 vote passed and the money did not move. Governance that terminates in a human decision to comply is a request, not a mechanism — the distinction drawn on [on-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance).
- **Progressive decentralization has a reverse gear.** Decentralization deferred until the moment it costs something is the moment it gets withdrawn. Aragon is the cleanest instance of that reversal actually being executed.
- **An unpriced treasury claim invites a raid.** Where holders have no formal exit, the discount between market cap and treasury is a standing bounty, and it will eventually be collected by someone whose interest in the mission is zero.
- **The framework does not govern the framework's owner.** Aragon's software gave other DAOs on-chain permissions; the ETH sat with a Swiss board the software could not reach. A DAO is only as on-chain as its assets.

## How Caper approaches this

Caper's answer to the Aragon situation is structural rather than procedural, and it runs in two directions. Both are in the contract, not in policy.

**Exit cannot be halted.** In a caper, leaving is a method a member calls directly, not a proposal, a negotiation, or a transfer someone has to agree to perform. A member redeems their share of the treasury themselves, and there is no committee positioned between the decision and the money — which is exactly the position the Aragon Association occupied for the year between the vote and the halt. There is no equivalent of a board pausing the transfer, because there is no transfer to pause.

**The treasury claim is not purchasable on its own.** The Aragon raid needed one precondition: a claim on the treasury that could be bought outright on the open market. In a caper, a member's share of the treasury is the same weight that determines their voting power, and that weight combines what they hold with a record of votes they actually cast — recorded in a [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) token that cannot be transferred between holders. Buying the float does not transfer anyone's participation record along with it. A holder who never votes has no treasury share to redeem at all.

Two honest qualifications. Holdings still matter — they are a real factor in the weight, so this is not a design where a large position counts for nothing; it is one where a large position _alone_ cannot capture the treasury. And Caper's exit is not the pro-rata NAV claim that [rage-quit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) gives Moloch members: it deliberately pays out on participation as well as stake, which is a different trade-off with its own costs for the passive holder. Aragon's holders got a clean pro-rata claim in the end — after eighteen months of dispute, and only because the organisation dissolved to give it to them.

Further reading: [What is a caper](/wiki/foundations/what-is-a-caper) · [Voting](/wiki/governance/voting) · [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting)

## References

- [Aragon — The Future of Aragon: Treasury to Transfer into a Delegated Voting DAO](https://blog.aragon.org/the-future-of-aragon-treasury-slated-to-move-into-the-hands-of-ant-token-holders/) (June 2022)
- [Aragon Association Takes Action to Safeguard the Mission of the Aragon Project](https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/) (9 May 2023)
- [Arca — DAO Dilemmas: Unraveling Aragon's Governance Controversy](https://www.ar.ca/blog/dao-dilemmas-unraveling-aragons-governance-controversy) (May 2023)
- [CoinDesk — Aragon Cancels Planned Community Control of $200M Treasury Amid Battle With Activist Investors](https://www.coindesk.com/business/2023/05/09/aragon-cancels-planned-community-control-of-200m-treasury-amid-battle-with-activist-investors) (9 May 2023)
- [Aragon — A New Chapter for the Aragon Project](https://blog.aragon.org/a-new-chapter-for-the-aragon-project/) (2 November 2023)
- [The Block — Aragon Association to dissolve itself, provide liquidity for ANT redemption](https://www.theblock.co/post/261179/aragon-association-to-dissolve-itself-provide-liquidity-for-ant-redemption) (2 November 2023)
- [Aragon — ANT Redemption Initiative Report](https://blog.aragon.org/ant-redemption-initiative-report/) (final outcomes, November 2024)
- [ANT Redemption Portal](https://ant.aragon.org/)

## ENS DAO

URL: https://caper.network/wiki/daos/infrastructure/ens-dao
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Name** | ENS DAO |
| **Type** | Protocol DAO (naming / identity) |
| **Governs** | The Ethereum Name Service (.eth names and identity) |
| **Protocol roadmap** | [ENSv2](https://ens.domains/ensv2) — deploying on Ethereum mainnet after the [Feb-2026 Namechain L2 cancellation](https://www.coindesk.com/tech/2026/02/06/ethereum-s-ens-identity-system-scraps-planned-rollup-amid-vitalik-s-warning-about-layer-2-networks) |
| **Governance token** | ENS (airdropped November 2021) |
| **Structure** | Working groups + a Cayman-based [ENS Foundation](https://docs.ens.domains/dao/foundation/); an endowment managed by Karpatkey |
| **Treasury** | Roughly $350 million including ENS tokens (~$88M excluding them), July 2026 |
| **Primary sources** | [discuss.ens.domains](https://discuss.ens.domains/), [docs.ens.domains](https://docs.ens.domains/) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Uniswap](/wiki/daos/dexs/uniswap-dao) |

The **ENS DAO** governs the [Ethereum Name Service](https://ens.domains/), the dominant naming and identity layer for Ethereum, which maps human-readable _.eth_ names to wallet addresses and other records. Since a November 2021 airdrop of the **ENS** token, the protocol's treasury, working groups, and parameters have been governed on-chain by token holders and their delegates. ENS governance is frequently cited as a benchmark — and, in 2026, as a cautionary tale about [voting-power concentration](/wiki/dao-governance/concepts/fundamentals/dao-governance-models).

## Structure

The DAO funds work through **working groups** (such as Public Goods and Ecosystem) and holds an **endowment** managed by the asset manager Karpatkey to give it a self-sustaining runway. Its legal interface is the **ENS Foundation**, a Cayman Islands nonprofit that provides limited liability and lets the DAO contract with the real world; the Foundation's directors handle day-to-day operations while remaining removable by token-holder vote. ([ENS Foundation — ENS docs](https://docs.ens.domains/dao/foundation/))

## The 2026 governance battle

In June 2026 ENS became the year's most-discussed governance dispute, and the record of it is unusually complete: every step ran through the DAO's own forum, Snapshot space, and governor contract.

On 19 June a proposal introduced by the delegate katherine.eth sought to transfer operational control, grants, and treasury management – the operational wallet, the DAO's ENS holdings, and the Karpatkey-managed endowment – to a five-seat ENS Foundation board. In parallel, the DAO was voting on whether to renew its [Security Council](/wiki/dao-governance/concepts/fundamentals/security-councils), the 4-of-8 multisig whose single power is to cancel a proposal already sitting in the timelock. The two questions were inseparable: a council empowered to cancel a passed proposal could, in principle, cancel that one.

The [advisory Snapshot vote](https://snapshot.box/#/s:ens.eth/proposal/0x9ed89cf79760eb92d220fee2da08896bf027317f394aab87863011f964e19453) on renewal (23–28 June, 73 voters) read as a clear pass: 1,274,195 ENS for to 85,204 against. It also carried 3,386,139 ENS abstaining – 71% of everything cast – of which 3,261,042 came from a single voter, ENS lead developer [nick.eth](https://api.ensdata.net/0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5), whose self-delegation that month was itself the subject of the dispute ([The Defiant](https://thedefiant.io/news/defi/ens-dao-delegates-governance-attack-johnson-self-delegates)).

The binding vote went the other way. Read from the [ENS Governor](https://etherscan.io/address/0x323A76393544d5ecca80cd6ef2A560C6a395b7E3), the executable that would have granted the renewed council its cancel role opened at block 25,424,114 (29 June 2026, 15:07 UTC) and closed at block 25,469,932 (6 July 2026, 00:34 UTC), and it was [defeated](https://www.tally.xyz/gov/ens/proposal/45402179622316441394139979097514597399865468312011562941203078514615705423505) 3,859,981 ENS against to 1,137,702 for. The DAO's advisory instrument and its binding one had pointed in opposite directions.

The replacement was tabled while that vote was still running, not after it. On 30 June katherine.eth posted a [framework for a new council](https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219): eight members, the threshold for any cancellation raised from 4-of-8 to 5-of-8, a tighter written mandate, a public pledge each nominee must affirm, a removal mechanism for members who act outside it, and an Appointment Agreement with the ENS Foundation drafted by counsel – with the scope of authority deliberately unchanged, “cancellation of timelocked proposals, nothing more”. Nominations were open to anyone and closed on 6 July. Eight of fifteen candidates were elected in a [Copeland-method vote](https://snapshot.box/#/s:ens.eth/proposal/0x3e7acd4a47b246382bf9a3aeb71d0fd1562d38dbb9f7b7760445cf9731229b9d) (7–12 July, 50 voters), and the [executable seating them](https://discuss.ens.domains/t/executable-establishing-a-new-security-council/22272) passed 4,228,716 to 94,526.

As of 8 August 2026 the outcome is verifiable on-chain: the new [council contract](https://etherscan.io/address/0x2acBf518b3759f6e1fA163294eda55bF1d0ae051) holds `PROPOSER_ROLE` on the [DAO timelock](https://etherscan.io/address/0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7), its owner [Safe](https://etherscan.io/address/0x7101B78638e34444F0a5AdE9e1149fbEeC029931) reports a threshold of 5 over 8 owners, and the term runs to 16 July 2028, when the same expiry logic fires again. ENS did not lose its veto and did not simply renew it; it made the body re-argue its mandate in public and wrote the answer down.

## Why it matters

The episode is a textbook live case study in **plutocracy and capture**. One delegate, Lefteris Karapetsas, wrote that Johnson had "delegated ~50% of the voting supply to himself, essentially becoming the DAO," and Security Council member Brantly Millegan called the Foundation proposal "the equivalent of treasury capture by ENS Labs." It crystallizes the core problem of [token-weighted voting](/wiki/dao-governance/concepts/fundamentals/dao-governance-models): when one party can marshal a majority of active votes, the decentralized form offers little protection for everyone else — the same dynamic documented across large DAOs in 2026. ([EtherWorld](https://www.etherworld.co/ens-dao-weighs-major-governance-shift-to-empower-ens-foundation/))

## ENSv2 and the scrapped Namechain L2

Beyond governance, 2026 also reset ENS's technical roadmap. **ENSv2** — a [ground-up rewrite of the ENS contracts and architecture](https://ens.domains/ensv2) for better usability, flexibility, and developer tooling — was originally meant to live on **Namechain**, a dedicated ENS Layer-2 that ENS Labs and the [Linea Association agreed to build](https://linea.build/blog/ens-labs-and-linea-association-to-build-namechain) in December 2024. On [5 February 2026](https://www.coindesk.com/tech/2026/02/06/ethereum-s-ens-identity-system-scraps-planned-rollup-amid-vitalik-s-warning-about-layer-2-networks) ENS Labs scrapped the L2 entirely and moved ENSv2 to **Ethereum mainnet**. Nick Johnson's framing: "the landscape has changed between when we first decided to pursue an L2" — the base layer had scaled enough (ENS reports [~99% lower registration gas costs over the prior year](https://www.theblock.co/post/388932/ens-labs-scraps-namechain-l2-shifts-ensv2-fully-ethereum-mainnet) alongside Ethereum's 2025 gas-limit rise) to make a separate rollup's cost savings no longer worth its complexity, echoing Vitalik Buterin's renewed emphasis on scaling L1 itself. ENS Labs says roughly [80% of development effort](https://www.theblock.co/post/388932/ens-labs-scraps-namechain-l2-shifts-ensv2-fully-ethereum-mainnet) can now go to ENSv2's core features rather than maintaining custom chain infrastructure. It is a notable case of a DAO-governed protocol reversing a flagship architectural bet as the surrounding ecosystem shifted under it.

## How Caper approaches this

ENS shows what happens when a dominant voter can override a DAO and minority members have no clean way out. A [caper](/wiki/foundations/what-is-a-caper) responds with two design choices described on its governance pages: voting weight that grows with demonstrated [participation](/wiki/governance/voting), not stake alone, so influence is harder to simply buy or delegate to oneself; and a built-in [exit](/wiki/governance/execution) right that lets any member redeem a treasury share sized by that same participation-weighted vote weight rather than be locked in under a controlling party. Those mechanics are stated neutrally on the linked Caper pages.

## References

- [ENS DAO Governance Forum](https://discuss.ens.domains/).
- [ENS docs: The ENS Foundation](https://docs.ens.domains/dao/foundation/).
- [The Defiant](https://thedefiant.io/news/defi/ens-dao-delegates-governance-attack-johnson-self-delegates) — ENS delegates call the Foundation proposal a governance attack as Johnson self-delegates.
- [Cryptopolitan](https://www.cryptopolitan.com/ens-dao-governance-reform-proposal-drama/) — ENS DAO governance reform proposal drama.
- [EP 6.45 — Renewal of the Security Council](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145), the renewal thread carrying the mandate argument in full.
- [Establishing a new Security Council](https://discuss.ens.domains/t/executable-establishing-a-new-security-council/22272) — the executable, with the deployed contract and Safe addresses.

## Kleros (PNK)

URL: https://caper.network/wiki/daos/infrastructure/kleros
Updated: 2026-08-06

|  |  |
| --- | --- |
| **What it is** | A [decentralized arbitration protocol](https://docs.kleros.io/court/overview): a blockchain "court" that resolves subjective disputes smart contracts cannot, by drawing anonymous jurors and paying them to reach a [Schelling point](/wiki/economics/schelling-points) on the honest answer. |
| **Token** | PNK (pinakion) — jurors stake it to be drawn; holders govern the protocol. Total supply [915,528,222 PNK](https://docs.kleros.io/concepts/pnk-token), changeable only by DAO vote. |
| **Governance** | PNK holders → Kleros Improvement Proposals (KIPs) → [Snapshot](https://snapshot.org/#/kleros.eth) vote → the [Governor contract](https://blog.kleros.io/governor-explainer/) auto-enforces the change on-chain. |
| **Founded** | 2017 (Coopérative Kleros, France) by [Federico Ast and Clément Lesaege](https://medium.com/kleros/kleros-a-decentralized-justice-protocol-for-the-internet-38d596a6300d); court live 2018. |
| **Archetype** | Dispute-resolution-as-a-DAO. Distinct from [UMA](/wiki/daos/infrastructure/uma)'s optimistic oracle: Kleros is a standing _court_ whose security is a staked-juror Schelling game, not an assert-and-dispute bond. |

**Kleros** is a decentralized [arbitration protocol](https://docs.kleros.io/court/overview) — a "court" that resolves the subjective disputes smart contracts cannot decide on their own: was a freelance deliverable actually delivered, is a token listing legitimate, did an insured event really occur. Its name and design borrow from the Athenian [kleroterion](/wiki/economics/schelling-points), the stone machine that selected citizen jurors by lot. Where a price-feed oracle like [Chainlink](https://chain.link/) reports objective data, Kleros adjudicates _judgment calls_ — and it does so as a DAO, where the same token that pays jurors also governs the protocol.

## The court: stake PNK, get drawn by lot

Anyone can become a juror by staking [PNK (pinakion)](https://docs.kleros.io/concepts/pnk-token) in a court. When a dispute arrives, the protocol draws jurors at random from the staked pool, **weighted by stake**: the more PNK you stake, the higher your probability of being drawn for any given case (buying a controlling share of the vote therefore costs progressively more as PNK grows scarce). Drawn jurors review the evidence submitted by both parties and vote on the ruling — typically _Yes_, _No_, or [Refuse to Arbitrate](https://docs.kleros.io/court/overview) — often through a commit-and-reveal scheme that hides each vote until all are cast, so jurors cannot simply copy one another.

## Coherence: making honesty the focal point

Kleros never tells a juror what is "true." Instead it pays jurors to converge on what they expect _other honest jurors_ to pick — a [Schelling-point](https://kleros.io/static/whitepaper.pdf) game drawn straight from [coordination theory](/wiki/economics/schelling-points). After a ruling, jurors who voted **coherently** (with the majority) collect the [arbitration fees](https://docs.kleros.io/concepts/tokenomics) plus PNK redistributed from the jurors who voted **incoherently**; incoherent jurors forfeit a portion of their staked PNK. A juror who votes randomly, or is bribed to vote against the evident truth, is more likely to land in the minority and lose money — so the profit-maximising move is to read the evidence and vote the honest answer. This is the same "vote for what you think others will honestly vote" logic that secures [UMA](/wiki/daos/infrastructure/uma)'s DVM, implemented as a persistent, subcourt-structured jury rather than a single dispute round.

## The court tree and appeals

Courts form a [tree](https://docs.kleros.io/court/overview): a **General Court** at the root, with specialized **subcourts** beneath it (e.g. curated-list, oracle, or commerce disputes), each with its own parameters, stake requirements, and juror pool. A dispute can be **appealed**: each appeal round draws a larger jury — roughly twice the previous size plus one — and both sides (or third-party [crowdfunders](https://docs.kleros.io/court/appeals), who are rewarded if their side wins) must fund the higher juror fees. Because winning an appeal requires corrupting an ever-larger, freshly-drawn jury, the cost of buying a wrong outcome rises with each round, while an honest litigant can always escalate. If the protocol itself were ever 51%-attacked, PNK's [final backstop](https://docs.kleros.io/concepts/pnk-token) is a governance fork that removes the attacker's stake — a recourse an external token could not provide.

## PNK as a governance token, and the wider stack

PNK's second job is governance. Holders propose [Kleros Improvement Proposals (KIPs)](https://forum.kleros.io/t/kip-69-parameter-updates-april-2024/1086), debate them on the [forum](https://forum.kleros.io/), and vote via [Snapshot](https://snapshot.org/#/kleros.eth); approved parameter changes are executed on-chain by the [Governor contract](https://blog.kleros.io/governor-explainer/), so the DAO can add courts, retune stakes and fees, or alter the very token supply. On top of the court sit Kleros's products — [Escrow](https://docs.kleros.io/products/escrow) (arbitrated P2P payments), [Curate](https://docs.kleros.io/products/curate) (token-curated registries whose entries are policed by the court), [Proof of Humanity](https://proofofhumanity.id/) (a sybil-resistant registry of real people), and a general-purpose [arbitrable-transaction oracle](https://docs.kleros.io/developers/overview) that any dApp or DAO can plug into for a credibly-neutral verdict.

## How Caper approaches this

Kleros exists because collectives constantly face questions that no vote can settle honestly on its own — "did this actually happen?", "is this claim legitimate?" — and someone must adjudicate them without a trusted middleman. [Caper](/wiki/foundations/what-is-a-caper) does not run a court, and it would be dishonest to pretend it arbitrates disputes. Its answer to the deeper problem Kleros targets — _what do you do when the group reaches a decision you consider illegitimate?_ — is not adjudication but [exit](https://caper.network/blog/the-exit-right). A caper member who believes the DAO is being run against their interests can redeem their proportional slice of the treasury and leave, because a member's [vote weight](/wiki/governance/voting-mechanisms) is the _same_ canonical share that governs their [exit](/wiki/foundations/what-is-a-caper) payout. Kleros makes defection costly by paying jurors to converge on the truth; Caper makes capture costly by guaranteeing that anyone outvoted can always walk away with their fair share intact. Both are Schelling-point designs — one coordinates jurors on an honest verdict, the other coordinates members on a proportional, non-dilutable claim.

## References

- Clément Lesaege, Federico Ast & William George, [Kleros Short Paper](https://kleros.io/static/whitepaper.pdf) — the Schelling-point juror model, appeals, and coherence incentives.
- Clément Lesaege, William George & Federico Ast, [Kleros Long Paper (Yellow Paper)](https://kleros.io/static/yellowpaper.pdf) — full cryptoeconomic specification.
- Kleros docs, [PNK Token](https://docs.kleros.io/concepts/pnk-token) — 915,528,222 total supply, matching the mainnet contract's on-chain `totalSupply` (the 764,626,704 figure still printed on the docs' [Tokenomics](https://docs.kleros.io/concepts/tokenomics) page is stale); juror-staking and governance roles, 51%-attack resistance.
- Kleros docs, [Court](https://docs.kleros.io/court/overview) — drawing, evidence, Yes/No/Refuse-to-Arbitrate voting, and the court tree.
- Kleros docs, [Appeals](https://docs.kleros.io/court/appeals) — appeal-fee crowdfunding and the asymmetric 2× / 1× funding rule that decides an unanswered appeal by default.
- Kleros blog, [Governor Explainer](https://blog.kleros.io/governor-explainer/); [KIP-69 Parameter Updates (Apr 2024)](https://forum.kleros.io/t/kip-69-parameter-updates-april-2024/1086) — on-chain governance via KIPs and Snapshot.

## SafeDAO

URL: https://caper.network/wiki/daos/infrastructure/safe-dao
Updated: 2026-07-19

|  |  |
| --- | --- |
| **Name** | SafeDAO (governance of [Safe](https://safe.global/), formerly Gnosis Safe) |
| **Type** | Token-holder DAO stewarding the Safe smart-account protocol and its ecosystem |
| **Origin** | Spun out of [GnosisDAO](/wiki/daos/networks/gnosisdao) in 2022; SAFE governance token [announced September 2022](https://www.coindesk.com/business/2022/09/28/digital-asset-manager-safe-to-offer-governance-token-for-safedao) |
| **Token** | SAFE — [1,000,000,000 fixed supply](https://safefoundation.org/token); one token, one vote (delegable) |
| **Transferability** | Non-transferable from launch; unpaused [in April 2024](https://www.theblock.co/post/290077/safe-token-trades-at-2-8-billion-fdv-after-becoming-transferable) after a near-unanimous SafeDAO vote |
| **Governance** | Safe Enhancement Proposals (SEPs) on the [forum](https://forum.safe.global/) → [Snapshot](https://snapshot.org/#/safe.eth) vote; stewarded by the [Safe Ecosystem Foundation](https://safefoundation.org/) |
| **Scale** | Safe accounts custody ~$41.7B of user assets across 63M+ deployed accounts ([Safe Foundation, mid-2026](https://safefoundation.org/token)) — see the live source for current values |
| **Site** | [gov.safe.global](https://gov.safe.global/) · [forum](https://forum.safe.global/) · [Snapshot](https://snapshot.org/#/safe.eth) |
| **Related** | [Safe (multisig)](/wiki/dao-governance/tooling/treasury/safe), [GnosisDAO](/wiki/daos/networks/gnosisdao), [On- vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) |

**SafeDAO** is the token-holder collective that governs [Safe](https://safe.global/) — the smart-contract wallet standard that has become the default custody layer for the DAO world. It is worth separating two things that share a name: the [Safe smart account](/wiki/dao-governance/tooling/treasury/safe) is the _product_ (an _m_-of-_n_ multisig that holds most DAO treasuries), while **SafeDAO** is the _governance organization_ that steers that product's roadmap, treasury, and grants. Safe began life inside Gnosis as the Gnosis Multisig (2017) and Gnosis Safe (2018), then [spun out in 2022](https://www.coindesk.com/business/2022/09/28/digital-asset-manager-safe-to-offer-governance-token-for-safedao) as an independent project with its own **SAFE** token and DAO — one of the more consequential graduations from [GnosisDAO](/wiki/daos/networks/gnosisdao)'s portfolio of [spun-out products](/wiki/dao-governance/concepts/fundamentals/types-of-daos).

## The SAFE token and the transferability saga

SAFE has a [fixed supply of 1,000,000,000 tokens](https://safefoundation.org/token) and grants [one-token-one-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) governance power over SafeDAO, with [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) so non-holders and passive holders can hand their weight to active delegates. Unusually, SAFE launched **non-transferable**: the token was distributed (including a claim to GnosisDAO and Safe users) but frozen, so no market could form until the DAO itself voted to unpause it. That milestone-gated design made "should SAFE be transferable yet?" one of SafeDAO's defining early governance questions — an initial [community initiative (SEP #2)](https://safefoundation.org/blog/safe-token-transferability) deliberately _delayed_ transferability behind governance-maturity milestones. Transfers were finally [unpaused in April 2024](https://www.theblock.co/post/290077/safe-token-trades-at-2-8-billion-fdv-after-becoming-transferable) after a near-unanimous Snapshot vote, at which point SAFE traded around a ~$2.8B fully-diluted valuation. The episode is a clean case study in a DAO controlling the economic life of its own governance token by vote rather than by decree.

## How SafeDAO governs

SafeDAO runs a structured [proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle). Changes are drafted as **Safe Enhancement Proposals (SEPs)** on the [Safe community forum](https://forum.safe.global/), discussed, then moved to a gas-free [Snapshot](https://snapshot.org/#/safe.eth) vote — the same [off-chain signalling](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) pattern its parent GnosisDAO pioneered, with execution carried out from Safe multisigs. Landmark proposals built the machine itself: the [Governance Framework (SEP #7)](https://forum.safe.global/t/sep-7-governance-framework/3711) set the rules of the road, the [Safe Grants Program (SEP #6)](https://forum.safe.global/t/sep-6-safe-grants-program-sgp/3213) funds ecosystem work, and an ongoing [Outcomes-Based Resource Allocation (OBRA)](https://forum.safe.global/t/sep-32-obra-continuation-of-governance-accessibility-and-participation-enhancement-at-safedao-stablelab/5381) track pays delegates and working groups against measurable results. Day-to-day stewardship — legal wrapper, operations, treasury execution — sits with the [Safe Ecosystem Foundation](https://safefoundation.org/), which reported [over $10M in annualized revenue in 2025](https://www.theblock.co/post/396147/non-custodial-wallet-safe-security-safenet-tokens) and is extending SAFE's utility beyond pure governance into securing its network.

## Why it matters: governing the vault the rest of the industry uses

SafeDAO is unusual because the thing it governs sits underneath almost everyone else. Safe smart accounts custody on the order of [$41.7B of user assets across 63M+ deployed accounts](https://safefoundation.org/token) (a figure that moves with the market — check the live source), and Safe has processed over $1 trillion in lifetime value. Those are _users'_ funds held in individual multisigs, not SafeDAO's own treasury — but the protocol's parameters, module standards ([Zodiac](https://www.zodiac.wiki/), [guards, and the SafeSnap execution path](https://docs.safe.global/home/what-is-safe)), and upgrade path are exactly what SafeDAO decides. That makes it a high-stakes example of [governance-as-critical-infrastructure](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): a large share of the DAO industry's [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) — including [GnosisDAO](/wiki/daos/networks/gnosisdao)'s own — are secured by a standard whose direction is set by SAFE-holder vote. It also anchors a lineage of [governance tooling](/wiki/dao-governance/tooling/dao-tooling-overview) the wider ecosystem runs on, from [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) signalling to Zodiac execution modules. The pattern reaches the top of the stack: [The Graph](/wiki/daos/infrastructure/the-graph)’s protocol authority is itself a 6-of-10 Safe multisig.

## How Caper approaches this

SafeDAO's architecture keeps three things in separate boxes: the **assets** live in a Safe multisig, **governance** happens off-chain on Snapshot, and the **SAFE token** that confers voting power is a distinct instrument from the funds a Safe secures. That separation is flexible and battle-tested, but it means custody, voting, and value are wired together by convention and by execution modules rather than by construction. [Caper](/wiki/foundations/what-is-a-caper) collapses the boxes. In a caper, the treasury _is_ the governance component: proposals, votes, and payouts all run through the same on-chain [DaoTreasury](/wiki/governance/voting), and a member's weight comes from tokens they cannot simply buy on a market — governance tokens combined with soulbound, earned participation. Most tellingly, a member's `exit()` redemption share equals their canonical vote weight `(t·v)/(V·T)`, computed by the _same_ function that sets their voting power: influence and cash-out claim are one number, not two assets to reconcile. Where SafeDAO must coordinate a multisig, a Snapshot space, and a separately-priced token, Caper makes governance and the value behind it inseparable at the protocol layer.

## The Graph

URL: https://caper.network/wiki/daos/infrastructure/the-graph
Updated: 2026-07-23

|  |  |
| --- | --- |
| **Name** | The Graph |
| **Type** | Decentralized blockchain-data indexing protocol & DAO |
| **Founded** | 2018 ([The Graph](https://en.wikipedia.org/wiki/The_Graph)) — Yaniv Tal, Brandon Ramirez, Jannis Pohlmann; mainnet December 2020 |
| **Governance token** | [GRT](https://thegraph.com/docs/en/resources/tokenomics/) — ERC-20; core protocol on [Arbitrum One](https://arbitrum.io/) since 2023 |
| **Governance** | [The Graph Council](https://thegraph.com/governance/) — 6-of-10 multisig, five stakeholder groups, ratifies [GIPs](https://github.com/graphprotocol/graph-improvement-proposals) |
| **Core developers** | Edge & Node, StreamingFast, Semiotic, Pinax, GraphOps — stewarded by [The Graph Foundation](https://thegraph.foundation/) |
| **Network (early 2026)** | 1.27T+ queries served, 75,000+ projects, 50+ Indexers, 60+ networks ([docs](https://thegraph.com/docs/en/about/)) |

**The Graph** is the indexing and query layer that lets applications read blockchain data without running their own infrastructure. Developers publish a _subgraph_ — an open API that defines how to extract, transform, and serve on-chain events — and anyone can query it in GraphQL. By early 2026 the network had served over [1.27 trillion queries to more than 75,000 projects](https://thegraph.com/docs/en/about/) across 60+ networks, alongside newer products for real-time streaming ([Substreams](https://thegraph.com/docs/en/substreams/overview/)) and enterprise SQL access (Amp). What makes it interesting as a _DAO_ is not the technology but who controls it: a work-token economy of Indexers, Delegators, and Curators, governed by a small elected Council rather than by direct token vote.

## The GRT work token: Indexers, Delegators, Curators

GRT is a **work token** — it is put to work securing and directing the network, not held passively for governance. Three roles stake or signal it ([docs](https://thegraph.com/docs/en/resources/roles/)):

- **Indexers** stake GRT as collateral, run node infrastructure, and serve queries; they earn indexing rewards (protocol issuance) and a share of query fees. Misbehaviour is slashable.
- **Delegators** delegate GRT to Indexers without running any infrastructure, taking a cut of the Indexer's rewards in exchange for lending stake and reputation.
- **Curators** [signal on subgraphs](https://thegraph.com/docs/en/resources/roles/curating/) they judge worth indexing, earning a slice of that subgraph's future query fees — the network's decentralized answer to "which data is worth serving."

This division of labour is the point: no single party both funds, secures, and directs the network. It also means governance power and economic power are deliberately separated — a Delegator with a large bag has no more say over the protocol than a small one.

## Curation is a bonding-curve market

Curation is where The Graph quietly runs one of DeFi's larger live **bonding-curve** experiments. When a Curator signals on a subgraph, GRT is deposited into a per-subgraph reserve and the Curator mints [Graph Curation Shares (GCS)](https://thegraph.com/docs/en/resources/roles/curating/) — ERC-20 shares that can only be minted or burned against that curve, never traded peer-to-peer. Being earlier to signal mints shares more cheaply, so early, correct curation is rewarded; the design uses a _nested_ curve (an inner curve per subgraph deployment, an outer curve at the [GNS / subgraph level](https://forum.thegraph.com/t/gip-0025-principal-protected-bonding-curves/3162)). A **1% tax** is charged on initial signalling and **0.5%** on auto-migration to a new version, and Curators collectively earn **10% of the query fees** a subgraph generates, pro-rata to shares.

The mechanism is itself under governance. [GIP-0025](https://forum.thegraph.com/t/gip-0025-principal-protected-bonding-curves/3162) introduced principal-protected curves, and [GIP-0058](https://forum.thegraph.com/t/gip-0058-replacing-bonding-curves-with-indexing-fees/4425) proposes replacing bonding curves with direct indexing fees — a reminder that even a market primitive is a governed parameter here.

## The Graph Council: governance by delegated multisig

The Graph's defining governance choice is that **GRT holders do not vote on-chain to change the protocol**. Authority sits with [The Graph Council](https://thegraph.com/governance/), a **6-of-10 Gnosis Safe multisig** that [balances five stakeholder groups](https://thegraph.com/blog/introducing-the-graph-council/) — Indexers, token holders, technical/research experts, backers, and the initial team. The Council ratifies protocol upgrades, sets economic parameters, and administers the community treasury.

Proposals move through the [Graph Improvement Proposal (GIP)](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0001-gip-process.md) process: an author drafts a GIP, the community debates it on the [governance forum](https://forum.thegraph.com/), and the Council votes to accept or reject. In February 2024 the Council added a six-member [Technical Advisory Board](https://thegraph.com/blog/) to shepherd research and the core roadmap. The result is a _representative_ DAO — deliberately fast and expert-led, but one where a token holder's leverage is voice in a forum, not a vote that settles on its own.

## From hosted service to a decentralized network

For years most applications used The Graph's centrally-run _hosted service_ rather than the token-incentivised network. That changed in 2024: the [hosted service was retired in June 2024](https://en.wikipedia.org/wiki/The_Graph), forcing all traffic onto the decentralized network, and the Foundation ran a **Sunrise Upgrade Program** (allocating up to 4 million GRT) to migrate projects across. In parallel the core protocol contracts moved to [Arbitrum One](https://arbitrum.io/) for cheaper staking, delegation, and reward flows. The migration is the clearest test of the whole design — the subsidised training wheels came off and the fee market had to stand on its own.

## Where power actually sits

The Council model buys speed and technical competence at the cost of a familiar DAO tension: the people who fund the network (Delegators, token buyers) are not the people who decide it. Supporters argue that protocol-parameter design is genuinely specialist work that a broad token vote handles badly, and that the five-group balance and public GIP process keep the Council accountable. Critics note that "accountable via forum" is weaker than "bound by vote," and that a 6-of-10 multisig is a concentrated point of trust for a network this large. Both readings are fair; The Graph is the reference case for asking a DAO the blunt question — _when a decision is made, whose signature actually settles it?_

## How Caper approaches this

The Graph shows a bonding curve doing one job — pricing _attention_, where early Curators who signal correctly are rewarded. [Caper](/wiki/foundations/what-is-a-caper) points the same primitive at a different one: pricing a project's own token at launch. Its [bonding curve](/wiki/markets/bonding-curve) follows an increasing schedule, so the earliest backers of a caper pay the lowest price and later demand pays more — funding a venture directly from the curve rather than signalling on someone else's data.

On governance, Caper takes the opposite stance to the Council: there is no delegated multisig that ratifies decisions on holders' behalf. Every proposal is settled by [on-chain vote weight](/wiki/governance/voting) — the product of a member's token holdings and their accrued, non-transferable proof-of-vote, so participation and not just size decides the outcome, and the same weight governs a member's [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) from the treasury. Where The Graph optimises for expert speed through representation, Caper optimises for members keeping the final say themselves.

## References

- [The Graph — About / network overview (docs)](https://thegraph.com/docs/en/about/)
- [Indexers, Delegators, Curators — network roles (docs)](https://thegraph.com/docs/en/resources/roles/)
- [Curating & Graph Curation Shares (docs)](https://thegraph.com/docs/en/resources/roles/curating/)
- [The Graph governance & the Council](https://thegraph.com/governance/)
- [Graph Improvement Proposals (GIP repository)](https://github.com/graphprotocol/graph-improvement-proposals)
- [GIP-0025 — Principal-Protected Bonding Curves](https://forum.thegraph.com/t/gip-0025-principal-protected-bonding-curves/3162) · [GIP-0058 — Replacing Bonding Curves with Indexing Fees](https://forum.thegraph.com/t/gip-0058-replacing-bonding-curves-with-indexing-fees/4425)
- [The Graph — Wikipedia (founding, hosted-service sunset)](https://en.wikipedia.org/wiki/The_Graph)

## UMA (Optimistic Oracle & the DVM)

URL: https://caper.network/wiki/daos/infrastructure/uma
Updated: 2026-07-29

|  |  |
| --- | --- |
| **What it is** | An [optimistic oracle](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work) — a protocol that reports arbitrary facts on-chain by assuming a proposed answer is true unless someone disputes it, with a token-holder vote as the court of last resort |
| **Category** | Oracle · dispute resolution · optimistic governance |
| **Token** | UMA (ERC-20) — staked in the **DVM** to vote on disputes and earn emissions |
| **Governance archetype** | The **token-vote-as-oracle**: instead of governing a treasury, UMA holders vote to _adjudicate disputed truth_ — a Schelling-point court of last resort |
| **Built by** | [Risk Labs](https://risklabs.foundation/) (UMA — "Universal Market Access"); Optimistic Oracle live since 2020 |
| **Primary sources** | [uma.xyz](https://uma.xyz/) · [docs.uma.xyz](https://docs.uma.xyz/) |

**UMA** is best known as an oracle, but its structure makes it one of the most instructive governance designs in the industry: the oracle _is_ a DAO. Where a price-feed oracle like [Chainlink](https://chain.link/) pushes data from trusted nodes, UMA answers questions the opposite way — it assumes a proposed answer is correct and only convenes a vote when someone objects. That escalation vote, the [Data Verification Mechanism (DVM)](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work), is a token-holder governance process whose sole job is to decide _what is true_. It is the clearest live example of a distinct DAO archetype: not governance _over_ a protocol, but governance _as_ the protocol's source of truth — a decentralised court of last resort.

## The Optimistic Oracle: assert first, dispute if wrong

UMA's [Optimistic Oracle](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work) reports data through economic incentives rather than continuous consensus. A **proposer** asserts an answer and posts a refundable bond; anyone may act as a **disputer** and challenge it within a _liveness_ (challenge) window by posting their own bond. If no one disputes before the window closes, the answer finalises and the proposer reclaims their bond plus a reward — hence _optimistic_. Each proposal can be disputed only once, and a dispute is the only thing that triggers a vote. Per UMA's own figures, roughly **99.8% of requests resolve with no vote at all**: the bond-and-challenge game settles almost everything, so the expensive human-judgement layer is invoked only on the genuinely contested tail. This is the same "assert, bond, wait, escalate" pattern behind [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac)'s [Reality.eth](https://reality.eth.limo/) module — UMA is the alternative oracle underneath it.

## The DVM: governance as a court of last resort

When a proposal _is_ disputed, the question escalates to the **DVM**, a [Schelling-point](/wiki/economics/schelling-points) mechanism where UMA stakers vote for the answer they expect other honest voters to converge on — the one most defensible against on-chain reality. Voting runs a **commit-reveal** cycle documented in UMA's [voter guide](https://docs.uma.xyz/using-uma/voting-walkthrough): a **24-hour commit phase** of encrypted votes, then a **24-hour reveal phase**. Hiding votes until the reveal stops lazy voters from copying the crowd and stops dishonest voters from coordinating on a wrong result. A question resolves once **65% of staked UMA** agree on an outcome.

The DVM 2.0 staking design ties the vote to real skin in the game. Staked UMA earns a prorated share of protocol emissions at **0.18 UMA per second**; each vote that lands against the resolved majority — or a vote a staker simply skips — is penalised **0.1% of their staked balance**, and those slashed tokens are redistributed to the voters who got it right. Unstaking triggers a **7-day cooldown** during which tokens neither earn nor vote. That cooldown is the linchpin of UMA's security argument: to corrupt the oracle an attacker must hold enough stake to swing the 65% threshold, but a captured oracle would crater the UMA price over the week it takes to exit — so the _cost of corruption_ is designed to exceed the _profit from corruption_ for any economically significant dispute.

## oSnap and the Optimistic Governor: optimistic execution of DAO votes

UMA productised its oracle for governance through the **Optimistic Governor**, a [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) module, and the [oSnap](https://docs.uma.xyz/resources/osnap) front-end built with [Snapshot](/wiki/dao-governance/tooling/voting/snapshot). The idea mirrors Zodiac's Reality Module but swaps in UMA's oracle: a DAO attaches transaction payloads to a Snapshot proposal, and once the off-chain vote passes, anyone can _assert_ on-chain that it passed, backed by a bond. Unless a disputer challenges within the liveness window — escalating to the DVM — the transactions become executable directly from the DAO's [Safe](/wiki/dao-governance/tooling/treasury/safe) treasury, with **no executing multisig in the loop**. It is the same trust-minimising move as UMA's core oracle, applied to a treasury: replace a trusted human signer with a bonded assertion anyone can contest.

_Freshness (2025–26):_ UMA [deprecated oSnap support on 15 December 2025](https://docs.uma.xyz/resources/osnap) — after that date the module can no longer execute transactions from a DAO's Safe treasury. The optimistic-execution _pattern_ persists (Zodiac's Reality Module still offers it via Reality.eth), but UMA's own governance-execution product has wound down, leaving the **Optimistic Oracle and the DVM** as its enduring contribution.

## How Caper approaches this

UMA exists because most on-chain governance has to reach _outside_ the chain — "did this Snapshot vote pass?", "what was this asset's price?" — and someone must assert that answer and be disputable. [Caper](/wiki/foundations/what-is-a-caper) sidesteps that layer for its own governance entirely. A caper's proposals are **typed and self-contained** — `PAYOUT`, `INVEST`, and `VOTE` — and are executed permissionlessly against the contract's own on-chain state (the `execute_proposal_*` methods, e.g. `execute_proposal_payout` at `caper_dao.rs:1220`, are public with no privileged caller). There is no off-chain claim to assert and therefore no optimistic-oracle-and-dispute court to run.

The deeper contrast is in _who_ adjudicates. UMA turns disputed truth into a vote weighted by a separate pool of _staked, tradeable_ UMA. Caper weights governance by `w = (t·v) / (V·T)` (`compute_vote_weight`, `caper_dao.rs:745–758`), where `v` is a member's holding of a **soulbound, non-transferable proof-of-vote token** — `DIVISIBILITY_NONE` with metadata literally "Soulbound proof-of-vote token" (`:508`, `:519`), its depositor role locked to `global_caller(component)` so it can never be moved between wallets (`:539`), minted one-per-vote. That same weight sets a member's treasury share on `exit()`, which reuses the identical helper and then burns the tokens (`:1486`, `:1495`). The decisive governance factor is therefore _earned by participating_, not bought or staked — but this is not "bagless": holdings `t` are a multiplicative term, so stake still counts. The honest concession is that UMA answers arbitrary real-world questions Caper does not try to — the comparison is only about governing the DAO itself, where Caper keeps the surface minimal and the influence un-buyable.

## References

- UMA, [How does UMA's oracle work?](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work) — Optimistic Oracle, the DVM, the 65% resolution threshold, and the cost-of-corruption security model.
- UMA, [Voting walkthrough](https://docs.uma.xyz/using-uma/voting-walkthrough) — commit-reveal timing, the 0.18 UMA/s emission rate, the 0.1% slash, and the 7-day unstaking cooldown.
- UMA, [oSnap](https://docs.uma.xyz/resources/osnap) — the Optimistic Governor / Snapshot execution flow and the 15 December 2025 deprecation notice.
- Related: [Zodiac & the Reality Module](/wiki/dao-governance/tooling/frameworks/zodiac) · [The DAO tooling stack](/wiki/dao-governance/tooling/dao-tooling-overview) · [EigenLayer](/wiki/daos/staking/eigenlayer) (intersubjective token-vote adjudication) · [Caper: on-chain execution](/wiki/governance/execution).

## Wormhole (W)

URL: https://caper.network/wiki/daos/infrastructure/wormhole
Updated: 2026-07-28

|  |  |
| --- | --- |
| **What it is** | A generic [cross-chain messaging protocol](https://wormhole.com/) — a layer that carries verified messages between blockchains, so an app on one chain can act on events from another. The well-known token bridge is one application built on top of it. |
| **Category** | Interoperability · cross-chain messaging · oracle |
| **Token** | W (ERC-20, [natively multichain](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and)) — staked and delegated for governance across Ethereum, Base, Solana, Arbitrum, and Optimism |
| **Governance archetype** | The **cross-chain-native DAO**: via [MultiGov](https://wormhole.com/docs/products/multigov/overview/), W holders create, vote on, and execute proposals from _any_ supported chain — no single hub to bridge into |
| **Security model** | A [Guardian network](https://wormhole.com/docs/protocol/infrastructure/guardians/) of 19 validators observes and attests events; a two-thirds signature quorum forms the verified message every chain trusts |
| **Incubated by** | Jump Crypto (2021); now stewarded by the Wormhole Foundation |

## Overview

Most DAOs in this directory govern a protocol that lives on one chain. [ENS](/wiki/daos/infrastructure/ens-dao) is Ethereum. [Optimism](/wiki/daos/networks/optimism-collective) is one rollup. Wormhole is the exception: it is the plumbing _between_ chains, and it is governed by a DAO whose voting is itself spread across chains. That makes it the clearest example of the **cross-chain-native** governance archetype.

Wormhole is a [generic message-passing protocol](https://wormhole.com/). An application emits a message on a source chain; Wormhole's validators attest to it; a contract on the destination chain accepts the attested message and acts on it. Token transfers are the most visible use, but the same rails carry governance votes, oracle prices, and arbitrary contract calls across more than 30 connected networks. The protocol was incubated by Jump Crypto in 2021 and is now stewarded by the Wormhole Foundation.

Because the value it moves is other protocols' value, Wormhole belongs alongside the other primitives in this section — [UMA](/wiki/daos/infrastructure/uma), [Safe](/wiki/dao-governance/tooling/treasury/safe), [Aragon](/wiki/daos/infrastructure/aragon-dao) — as [infrastructure other protocols build on](/wiki/dao-governance/concepts/fundamentals/types-of-daos).

## The Guardian network

Wormhole does not verify messages with a light client or a fraud proof. It verifies them with a fixed set of validators called [Guardians](https://wormhole.com/docs/protocol/infrastructure/guardians/) — currently 19 established node operators. Each Guardian independently observes an emitted message and signs it. When two-thirds of them sign, the signatures bundle into a [Verified Action Approval (VAA)](https://wormhole.com/docs/protocol/infrastructure/vaas/) — the credential that any destination chain accepts as proof the event really happened.

This is a deliberately simple trust model, and its honesty is a design choice worth being clear about: the whole system is only as trustworthy as those 19 signers. Wormhole's roadmap has pushed toward hardening that assumption — a larger and more diverse Guardian set, staking, and light-client verification for some routes — but at its core the network still asks users to trust that a supermajority of Guardians will not collude or be compromised.

## The February 2022 exploit

What happens when the verification layer fails is not hypothetical. On 2 February 2022, an attacker exploited a [deprecated signature-verification function](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) on the Solana–Ethereum token bridge to forge the appearance of a valid deposit, minting [120,000 wrapped ETH (~$325M)](https://www.theblock.co/post/132909/wormhole-replenishes-its-blockchain-bridge-after-325-million-exploit) out of nothing. The bug was not in the Guardians' honesty — it was in a contract that let the attacker bypass their check entirely.

Jump Crypto, which incubated the protocol, [replaced the 120,000 ETH within about a day](https://www.theblock.co/post/132909/wormhole-replenishes-its-blockchain-bridge-after-325-million-exploit) to keep the bridge solvent, and in February 2023 recovered roughly [$225M from the attacker in a counter-exploit](https://blockworks.com/news/jump-crypto-wormhole-hack-recovery). The episode is a standing entry in the catalogue of [how these systems fail](/wiki/dao-governance/concepts/analysis/how-daos-fail): a cross-chain protocol's real attack surface is the message-verification layer, not the token contract, and a well-capitalised backstop can paper over a loss but not the trust question underneath it.

## The W token

W launched on [3 April 2024](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) as a natively multichain token, minted directly on several chains rather than bridged from one home. Total supply is [capped at 10 billion](https://decrypt.co/216450/wormhole-airdrop-w-tokenomics-unlock-schedule-eligibility), with about 1.8 billion circulating at genesis and roughly 82% initially locked on a four-year release schedule.

The [genesis allocation](https://wormhole.com/blog/w-airdrop-explained) splits the supply across community (17%), the ecosystem and growth fund (31%), the foundation treasury (23.3%), core contributors (12%), strategic network partners (11.6%), and Guardian node operators (5.1%). The launch airdrop distributed 6.75% (about 674.8M W) to more than 400,000 wallets, weighted toward addresses that had actually used Wormhole-connected apps.

## MultiGov: governing from any chain

W's defining feature is not its distribution — it is _where_ you can vote with it. In late 2024 Wormhole, [Tally, and ScopeLift shipped MultiGov](https://wormhole.com/blog/wormhole-tally-and-scopelift-announce-multigov-the-first-ever-multichain), billed as the first multichain governance system, and the Wormhole DAO became its first adopter.

MultiGov uses a [hub-and-spoke design](https://wormhole.com/docs/products/multigov/concepts/architecture/). One chain is the hub, where a `HubGovernor` contract creates proposals, tallies votes, and executes outcomes through a [timelock](/wiki/dao-governance/concepts/voting/governance-timelocks). Every other supported chain is a spoke: a `SpokeVoteAggregator` collects local votes and forwards them to the hub over Wormhole messaging, where a `HubVotePool` folds them into the tally. A holder on Solana or Base votes with tokens that never leave their chain, and the outcome propagates back out to spoke executors. It is [on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) stretched across chains instead of pinned to one.

The pattern generalises beyond Wormhole — MultiGov is offered as reusable [governance tooling](/wiki/dao-governance/tooling/dao-tooling-overview) for any multichain DAO, in the same family as the single-chain frameworks [spl-governance](/wiki/dao-governance/tooling/frameworks/spl-governance) and Aragon. It also inherits their hard question: the votes themselves now ride the Guardian-attested rails, so the [delegation and vote-counting](/wiki/dao-governance/concepts/voting/voting-and-delegation) logic is only as final as the message layer carrying it.

## What the DAO governs

The Wormhole DAO steers the protocol's parameters, treasury, and the direction of its cross-chain standards, while day-to-day operation of the Guardian network and core development sit with node operators and the foundation. As with [most infrastructure DAOs](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups), the elected surface is narrower than the protocol's full footprint: token holders set policy, but they do not personally re-sign every VAA. The archetype it fills here is specific — a DAO whose _subject_ spans every connected chain and whose _voting_ does too, distinct from the single-chain adjudication of [Kleros](/wiki/dao-governance/tooling/voting/kleros) or the single-registry scope of ENS.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) is single-ledger by construction: it lives entirely on Radix, with no cross-chain messaging and no external validator set carrying its votes. So the honest comparison is not feature-for-feature — Caper simply does not do what Wormhole does. The useful contrast is about _who sits between a member and their vote_.

In MultiGov, a vote cast on a spoke chain is only final once a supermajority of Guardians attests the message carrying it to the hub. In a caper there is no such layer: a member's [vote weight](/wiki/dao-governance/concepts/voting/voting-and-delegation) is computed on-ledger from balances they already hold. The contract combines governance tokens held with earned, non-transferable vote tokens — verified in `compute_vote_weight` (`contracts/logic/src/lib.rs`), where the held balance enters as a multiplier, so a large bag alone cannot capture control without earned votes. And an outvoted member is not stuck arguing with the majority: `exit` (`contracts/logic/src/lib.rs`) lets them withdraw a treasury share equal to that same canonical vote weight, redeeming both their vote and governance tokens. Nothing has to be relayed or attested for either to settle.

## References

- [Wormhole Docs — MultiGov overview](https://wormhole.com/docs/products/multigov/overview/)
- [Wormhole Docs — MultiGov hub-and-spoke architecture](https://wormhole.com/docs/products/multigov/concepts/architecture/)
- [Wormhole / Tally / ScopeLift — announcing MultiGov](https://wormhole.com/blog/wormhole-tally-and-scopelift-announce-multigov-the-first-ever-multichain)
- [Wormhole — the W airdrop explained (allocation)](https://wormhole.com/blog/w-airdrop-explained)
- [Wormhole — W token, one year on](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and)
- [The Block — Wormhole replenishes bridge after $325M exploit](https://www.theblock.co/post/132909/wormhole-replenishes-its-blockchain-bridge-after-325-million-exploit)
- [Halborn — explaining the February 2022 Wormhole hack](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022)

## PleasrDAO

URL: https://caper.network/wiki/daos/investment/pleasrdao
Updated: 2026-08-03

| Organization | **PleasrDAO** — a collector DAO that acquires and collectively stewards culturally significant digital and physical artifacts |
| --- | --- |
| Category | Collector / cultural-asset DAO (non-DeFi) |
| Founded | March–April 2021, organized on Twitter to buy a single NFT |
| Members | A few dozen artists, collectors and crypto investors, coordinating purchases by on-chain vote |
| Notable holdings | pplpleasr's Uniswap V3 "x*y=k" NFT; Edward Snowden's _Stay Free_; the original Doge meme NFT; Wu-Tang Clan's _Once Upon a Time in Shaolin_ |
| Fractionalized token | **$DOG** — shares in the Doge NFT sold to the public |
| Backers | a16z-led governance-token round, December 2021 (a16z stake <5%) |
| Website | [pleasr.org](https://pleasr.org/) |
| Status | 🟢 Active |

**PleasrDAO** is a [collector DAO](/wiki/daos/investment/the-lao) — a group that pools money on-chain to buy things, then owns and stewards them together. Where a [venture DAO](/wiki/daos/investment/the-lao) buys equity and tokens for returns, PleasrDAO buys _cultural artifacts_: a viral meme, a whistleblower's artwork, a one-of-one album. It began in [March 2021](https://thedefiant.io/i-thought-i-was-living-in-a-simulation-the-story-behind-the-500k-uniswap-nft) when a handful of people coordinated on Twitter to buy a single NFT, and it kept going — turning "a few strangers chipping in for an internet artifact" into a recurring pattern of [collective ownership of digital culture](https://pleasr.org/). It is the clearest example of the **collector-DAO** archetype, distinct from the failed one-shot crowdfund of [ConstitutionDAO](/wiki/daos/social/constitutiondao) and the creative treasury of [Nouns](/wiki/daos/social/nouns-dao).

## The collector-DAO thesis: own the artifact together

The collector DAO answers a simple question: _what if the buyer of a trophy asset were a crowd instead of a whale?_ A single billionaire can buy a Wu-Tang album and lock it in a vault. A DAO can buy the same album, then argue in public about how to steward it, who gets to hear it, and whether to fractionalize the upside. The asset becomes a shared commons rather than private property.

That reframes three things every DAO has to handle:

- **Acquisition.** Members contribute capital to a pooled treasury and vote on what to buy — the same "guild bank" pattern [MolochDAO](/wiki/daos/public-goods/molochdao) pioneered, pointed at cultural assets instead of startups.
- **Stewardship.** Once you own a culturally loaded object, custody, display, and legal restrictions become governance questions — not one owner's whim.
- **Ownership of the upside.** A trophy asset is illiquid and indivisible. PleasrDAO's signature move was to **fractionalize** it — mint fungible shares so anyone can own a slice and the value can trade.

## The trophies: from a Uniswap ad to a Wu-Tang album

PleasrDAO's holdings read like a timeline of 2021 crypto culture, each bought at public auction with a verifiable price:

- **pplpleasr's "x*y=k" (March 2021).** The DAO formed to buy the Taiwanese artist [pplpleasr's animated Uniswap V3 teaser](https://decrypt.co/63080/an-ad-for-uniswap-just-sold-for-525000-as-an-nft-heres-why) for ~$525,000 — she donated the proceeds to charity. The purchase _created_ the DAO; the name is a pun on "pleaser."
- **Edward Snowden's _Stay Free_ (April 16, 2021).** Bought for [2,224 ETH (~$5.4 million)](https://www.coindesk.com/markets/2021/04/16/nsa-whistleblower-edward-snowden-sells-nft-for-54m), with proceeds going to the [Freedom of the Press Foundation](https://freedom.press/) — roughly doubling the non-profit's budget overnight.
- **The Doge NFT (June 2021).** The original "doge" meme image, bought for [1,696.9 ETH (~$4 million)](https://techcrunch.com/2021/12/14/andreessen-horowitz-backs-nft-investor-group-behind-one-of-a-kind-wu-tang-clan-album-purchase/) and then fractionalized (below).
- **Wu-Tang Clan's _Once Upon a Time in Shaolin_ (2021).** The single-copy album, bought for [$4 million](https://en.wikipedia.org/wiki/Once_Upon_a_Time_in_Shaolin) from an entity that had itself bought it from the U.S. Department of Justice — the album was forfeited to the government after Martin Shkreli's 2018 securities-fraud conviction. Under the original terms the recording [cannot be commercially exploited until 2103](https://en.wikipedia.org/wiki/Once_Upon_a_Time_in_Shaolin).

In [December 2021](https://techcrunch.com/2021/12/14/andreessen-horowitz-backs-nft-investor-group-behind-one-of-a-kind-wu-tang-clan-album-purchase/) an a16z-led round bought governance tokens in the collective (a16z's stake reportedly under 5%), putting institutional capital behind what started as a group chat.

## Fractionalized ownership: the $DOG experiment

PleasrDAO's most-copied idea is **fractionalization**. Having bought the ~$4M Doge NFT, the DAO split it into billions of fungible [$DOG tokens](https://www.thearmchairtrader.com/pleasrdao-amber-group-nft-doge-huobi/) and sold them to the public — so the world's most famous meme became an asset anyone could own a sliver of, and its implied value could [trade to a nine-figure market cap](https://techcrunch.com/2021/12/14/andreessen-horowitz-backs-nft-investor-group-behind-one-of-a-kind-wu-tang-clan-album-purchase/). The Wu-Tang album got a gentler version: from [June 2024](https://en.wikipedia.org/wiki/Once_Upon_a_Time_in_Shaolin) PleasrDAO began selling $1 NFTs, each one accelerating the album's eventual public release by 88 seconds and granting the buyer a five-minute sampler.

Fractionalization solves the collector DAO's core tension — a trophy is _indivisible and illiquid_, but a crowd needs divisible, tradeable ownership. It also exposes a hard governance problem the wiki treats as a first-class topic: once ownership is a freely tradeable token, [exit and control](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) acquire a spot price. Whoever accumulates the shares can direct the asset — the market decides who "owns" the culture, and a well-funded buyer can simply purchase a controlling stake. That is precisely the pressure Caper's design is built to resist.

## How Caper approaches this

PleasrDAO shows the reach of a collector DAO — and the sharp edge of making ownership a _freely tradeable share_. Once the Doge NFT is 16.9 billion $DOG tokens, control has a market price: accumulate enough tokens and you steer the asset, no matter what you contributed or who you are. A trophy meant to be a shared commons can be quietly bought into a single pair of hands.

A [Caper](/wiki/foundations/what-is-a-caper) keeps the tradeable part and adds one that is not for sale. Voting power and treasury [exit share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) are the _same_ quantity — Caper computes both from `(t·v) / (V·T)` (`compute_vote_weight` in `contracts/logic/src/lib.rs`): `t` is the caper tokens you hold, `v` is your [soulbound proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens), and `V`/`T` are the totals. The vote token is minted one-per-vote, has `DIVISIBILITY_NONE`, and cannot leave the wallet that earned it (its only depositor is the component itself) — so the record of participation is **earned and unbuyable**.

The effect: a large bag of tokens alone can't capture a Caper the way a large bag of $DOG can capture the Doge NFT, because half of the weight (`v`) is a soulbound history you can't purchase off anyone. Stake still counts — `t` is a real multiplier, so this is not a "your bag doesn't matter" system — but the decisive, unbuyable factor is the participation you earned, and when you exit, your treasury slice is that same earned weight rather than a share you could have simply bought on the open market.

## The LAO

URL: https://caper.network/wiki/daos/investment/the-lao
Updated: 2026-08-03

| Organization | **The LAO** — a for-profit, member-directed venture DAO investing in early-stage crypto projects |
| --- | --- |
| Category | Investment / venture DAO (non-DeFi) with a legal wrapper |
| Legal structure | **Delaware LLC** — a real limited-liability company whose members are its DAO participants |
| Membership | Capped at **~100 members**, limited to [accredited investors](https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/updated-3) |
| Announced / launched | [September 2019](https://www.artificiallawyer.com/2019/09/09/smart-contract-co-openlaw-launches-the-dao-mark-ii-the-lao/) · live [April 2020](https://www.coindesk.com/tech/2020/04/28/openlaw-launches-first-legal-dao-for-distributed-vc-investments) |
| Governance | A fork of [MolochDAO](/wiki/daos/public-goods/molochdao) (v2), later generalized into the [Tribute DAO Framework](https://github.com/openlawteam/tribute-contracts) |
| Built by | OpenLaw (Aaron Wright, Cardozo Law), now [Tribute Labs](https://tributelabs.xyz/) |
| Sister DAOs | Flamingo (NFTs), Neptune (DeFi), Neon (metaverse), Noise (music) |

**The LAO** is a member-directed venture fund that runs like a DAO but sits inside a real [legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures). Members pool capital on-chain, vote on which startups and tokens to back, and split the returns — while a Delaware limited-liability company gives them the liability protection, tax treatment, and enforceable agreements that a bare smart contract cannot. When it went live in [April 2020](https://www.coindesk.com/tech/2020/04/28/openlaw-launches-first-legal-dao-for-distributed-vc-investments) it was widely described as the first "legal DAO," and it remains the canonical example of the archetype: a for-profit investment club that is simultaneously a piece of software and a company the courts recognize.

It matters because it answers a question [MolochDAO](/wiki/daos/public-goods/molochdao) and [ConstitutionDAO](/wiki/daos/social/constitutiondao) left open — _how does a pooled, on-chain treasury actually hold equity in a startup, sign a SAFE, or return profits to members without every participant becoming personally liable as a general partner?_ The LAO's answer was to marry Moloch-style on-chain mechanics to auto-generated legal documents, so an on-chain vote and an off-chain contract point at the same decision.

## The legal-wrapper model: a DAO the law can see

The LAO was built by **OpenLaw** — a smart-contract-and-legal-agreement toolkit from [Aaron Wright](https://www.artificiallawyer.com/2019/09/09/smart-contract-co-openlaw-launches-the-dao-mark-ii-the-lao/), a Cardozo Law professor, and his co-founders (OpenLaw later became [Tribute Labs](https://tributelabs.xyz/)). Its core move is to organize the DAO as a **Delaware LLC** and then use software to generate "all relevant legal documents from entity formation documents to member subscription agreements," as the [launch write-up](https://medium.com/openlawofficial/the-lao-a-for-profit-limited-liability-autonomous-organization-9eae89c9669c) put it — giving members "the backing of the U.S. legal system."

That wrapper does real work. It caps each member's liability at what they put in (no general-partnership exposure), it clarifies that members are LLC members rather than a securities-issuing partnership, and it lets the entity itself hold the assets the DAO buys — equity, tokens, SAFEs — under agreements a counterparty and a court will honor. The on-chain contract handles voting, funding, and allocation; the legal layer makes the outcome enforceable off-chain. This is the pattern later codified across the industry as the [DAO legal-structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) toolbox (Wyoming DAO LLCs, the Marshall Islands wrapper, foundation companies), and The LAO is its proof of concept.

## How members invest: shares, weighted votes, and rage-quit

Governance is a fork of [MolochDAO](/wiki/daos/public-goods/molochdao) (v2), the minimalist "guild bank" contract — and it inherits Moloch's three defining mechanics:

- **Capital buys shares.** Members contribute ETH and receive voting shares in proportion to their economic contribution, so influence tracks the money at stake.
- **A member nominates, the majority allocates.** To back a project, a member submits a proposal; funding proceeds only when a majority of members, weighted by their shares, [approve the allocation](https://medium.com/openlawofficial/the-lao-a-for-profit-limited-liability-autonomous-organization-9eae89c9669c). Deal flow is member-sourced, not run by a GP.
- **Rage-quit.** A member who dislikes a decision can exit immediately and reclaim their _fair share of unallocated funds based on their economic contribution, regardless of voting weight_ — the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) that stops a majority from spending a dissenter's capital against their will.

Because share weight and exit share both key off capital, The LAO is an honest instance of pure [capital-weighted](/wiki/dao-governance/concepts/treasury/dao-tokenomics) governance: the largest cheque is the largest [vote](/wiki/dao-governance/concepts/voting/voting-and-delegation), bounded only by the rage-quit backstop and the membership cap.

## Accredited membership, the cap, and the DAO family

To stay inside U.S. securities law, The LAO keeps membership **capped at roughly 100** and limits it to [accredited investors](https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/updated-3) — a deliberate trade of open, permissionless entry for legal defensibility. That constraint (a private placement to a small pool of qualified investors) is exactly what lets the fund invest in equity and tokens without registering as a public offering.

The LAO has since become the template for a whole [Tribute Labs](https://tributelabs.xyz/) family of member DAOs, each pointing the same wrapper at a different asset class: **Flamingo** for NFTs (which [grew an early ~$10M pool into a collection valued near $1B](https://www.coindesk.com/markets/2022/02/10/flamingodaos-nft-portfolio-is-now-worth-1b) at the 2022 peak), **Neptune** for DeFi, **Neon** for the metaverse, and **Noise** for music. The underlying tooling was generalized and open-sourced as the [Tribute DAO Framework](https://github.com/openlawteam/tribute-contracts). The LAO itself has kept deploying capital across dozens of early-stage rounds — [trackers count roughly four dozen investments](https://www.cbinsights.com/investor/the-lao) across its life — making it one of the longest-running productive investment DAOs.

## How Caper approaches this

The LAO shows what a well-built _capital-weighted_ investment DAO looks like: shares scale with the ETH you put in, your vote scales with your shares, and your [exit share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) scales — as the [docs](https://medium.com/openlawofficial/the-lao-a-for-profit-limited-liability-autonomous-organization-9eae89c9669c) say — with your "economic contribution, regardless of voting weight." That is the right design for an accredited-investor fund where capital _is_ the contribution. It also means control is, straightforwardly, for sale: the biggest cheque is the biggest voice.

[Caper](/wiki/foundations/what-is-a-caper) keeps the same open exit right but changes what a vote is made of. In the contract, a member's weight is `w = (t · v) / (V · T)` — held tokens _t_ multiplied by an _earned_ vote factor _v_, over total vote supply _V_ and circulating tokens _T_ (`compute_vote_weight`, verified in `contracts/logic/src/lib.rs`). Those vote tokens are **soulbound** — minted one per vote cast, non-transferable and indivisible (`DIVISIBILITY_NONE`), so _v_ is a record of participation you accumulate by showing up, not a thing you can buy.

The sharpest contrast is at the exit. The LAO returns a dissenter's stake purely by capital. Caper's `exit()` pays a treasury share equal to _the same_ `w = (t · v) / (V · T)` that determines voting power — so your slice on the way out reflects both your holdings and your earned participation, not capital alone. A big bag still counts (_t_ is a multiplier), but a bag with no earned _v_ can neither capture the vote nor claim a participant's exit share. Same legal-wrapper problem The LAO solved; a different answer to _who_ the treasury ultimately belongs to.

## Aave DAO

URL: https://caper.network/wiki/daos/lending/aave-dao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Aave DAO |
| **Type** | Protocol DAO (lending / money market) |
| **Governance token** | AAVE (migrated from LEND at 100:1, October 2020; 16M supply) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain voting via Aave Governance V3 + separable delegation |
| **Treasury** | On-chain Collector contracts; among the largest DAO treasuries (track live on DeepDAO) |
| **Notable for** | Largest DeFi lending protocol by TVL; the GHO stablecoin; the 2025 "Aavenomics" buyback |
| **Primary sources** | [aave.com/docs](https://aave.com/docs), [governance.aave.com](https://governance.aave.com/), [governance portal](https://app.aave.com/governance/) |
| **Related** | [Uniswap DAO](/wiki/daos/dexs/uniswap-dao), [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) |

The **Aave DAO** governs [Aave](https://aave.com/), a decentralized, non-custodial liquidity protocol where users supply assets to earn yield and borrow against overcollateralized positions. Deployed across more than a dozen EVM networks, Aave is consistently the **largest lending protocol in DeFi by total value locked** — several times the size of its nearest competitors; the live figure is tracked on [DeFiLlama](https://defillama.com/protocol/aave). Control over the protocol's parameters, its markets, its treasury, and its native stablecoin rests with holders of the **AAVE** token, who decide by [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain vote.

## Origins and the AAVE token

Aave began as ETHLend and its LEND token. In 2020 the project rebranded to Aave and, after its first governance proposal, **migrated LEND to AAVE at a 100:1 ratio** (100 LEND → 1 AAVE), going live in October 2020 with a fixed supply of **16 million AAVE** — 13 million from the migration and 3 million placed in an Ecosystem Reserve. AAVE (together with staked stkAAVE and aAAVE) confers proportional voting power, and staking it backs the protocol's safety module against shortfall events. ([CoinDesk, 2020](https://www.coindesk.com/tech/2020/07/29/defi-lender-aave-rolls-out-governance-token-on-path-to-decentralization))

The strength of Aave's markets also seeded a wider ecosystem: [Morpho](/wiki/daos/lending/morpho) launched in 2022 as a peer-to-peer optimizer layered on top of Aave and [Compound](/wiki/daos/lending/compound-dao) before shipping its own immutable lending primitive.

## Governance V3 and the proposal lifecycle

**Aave Governance V3** is a modular, multi-chain system: a Core network (Ethereum mainnet) holds voting power, low-cost Voting networks tally votes via storage proofs, and Execution networks implement approved payloads across chains, all wired together by the Aave Delivery Infrastructure (a.DI). Holders can **delegate voting power and proposition power separately** to different addresses. A change moves through a defined [lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle): forum discussion, a non-binding **Temp Check** (Snapshot poll), an **ARFC** (Aave Request for Final Comments) with service-provider review, and finally an on-chain **AIP** (Aave Improvement Proposal) — an IPFS-stored metadata file plus an executable payload — that must clear quorum before executing behind a one-day or seven-day timelock. Two emergency multisigs — a Protocol Guardian and a Governance Guardian — can pause markets or veto a malicious payload. ([Aave docs: Governance](https://aave.com/docs/ecosystem/governance); [proposal process](https://aave.com/help/governance/proposals))

## GHO — the DAO's own stablecoin

In July 2023, following a near-unanimous governance vote, the DAO launched **GHO**, a decentralized, overcollateralized, USD-pegged stablecoin minted directly by borrowers who post collateral in Aave markets. GHO is **fully governed by the DAO**: governance sets its interest rate, approves the "facilitators" allowed to mint it, and caps their bucket sizes — and **100% of the interest paid on GHO flows to the DAO treasury**, turning the stablecoin into a first-party revenue line rather than a fee handed to a third party. ([Aave docs: GHO](https://aave.com/help/gho-stablecoin/gho))

## Aavenomics — turning fees into token value

For years AAVE conferred votes but no direct claim on protocol revenue. That changed with **"Aavenomics,"** a 2025 tokenomics overhaul that routes surplus revenue back to the token. It introduced a **"Buy and Distribute"** program that buys AAVE from the open market and moves it to the Ecosystem Reserve; **Anti-GHO**, a non-transferable reward minted from GHO revenue and burnable against GHO debt; and **Umbrella**, a redesigned safety module covering bad debt on core assets. In 2025 the buyback was made a standing program of roughly $50M/year, later adjusted downward in 2026 governance — a concrete example of the broader industry shift from pure governance tokens toward [value-accruing](/wiki/daos/dexs/uniswap-dao) ones. ([Aavenomics ARFC](https://governance.aave.com/t/arfc-aavenomics-implementation-part-one/21248); [buyback update](https://governance.aave.com/t/arfc-aave-buybacks-program-an-update/23290))

## The service-provider model

The Aave DAO does not employ staff directly; it funds work through **service providers** — independent risk, finance, development, and delegate teams paid from the treasury by governance vote. Notable contributors include the founding company **Avara / Aave Labs** (which builds the core protocol), the delegate-and-steward **Aave Chan Initiative**, technical teams like **BGD Labs**, and risk providers such as **Chaos Labs**. Crucially, the DAO is not Aave Labs: Labs must request funding like any other provider, a separation that became visible in 2026 when BGD Labs announced its departure amid a public dispute over Aave Labs' roadmap and accountability, even as the DAO approved a $25M funding package for Labs. It is a live illustration of the recurring tension between a DAO and its closely-associated development company. ([Aave governance forum](https://governance.aave.com/))

## How Caper approaches this

Aave spent years retrofitting value accrual onto a token that originally carried none, and it coordinates a sprawling set of service providers through discretionary treasury grants. A [caper](/wiki/foundations/what-is-a-caper) starts from the other end: funding flows through an on-chain [bonding curve](/wiki/markets/bonding-curve) into a shared treasury from day one, and every deployment of that treasury is a bounded [PAYOUT or INVEST proposal](/wiki/governance/proposals) rather than a standing budget — with a member's economic claim realized directly at [exit](/wiki/governance/execution), sized by the same weight that decides their vote. The mechanics are described neutrally on those Caper pages.

## References

- [Aave documentation](https://aave.com/docs) — protocol and governance reference.
- [Aave Governance Forum](https://governance.aave.com/) — where ARFCs and AIPs originate.
- [Aave docs: GHO stablecoin](https://aave.com/help/gho-stablecoin/gho).
- [Aavenomics Implementation, Part One](https://governance.aave.com/t/arfc-aavenomics-implementation-part-one/21248) — the 2025 buyback / Anti-GHO / Umbrella package.
- [DeFiLlama: Aave](https://defillama.com/protocol/aave) — live total value locked.

## Beefy (BIFI)

URL: https://caper.network/wiki/daos/lending/beefy
Updated: 2026-08-06

|  |  |
| --- | --- |
| **What it is** | A multichain [yield optimizer](https://beefy.com/): vaults that auto-compound a deposit's farming rewards back into the deposited asset, charging a performance fee on the harvest. A [Yearn](/wiki/daos/lending/yearn-finance)-class strategy vault, deployed across dozens of chains. |
| **Token** | BIFI, fixed supply of exactly **80,000** tokens with no mint function [on the mainnet contract](https://etherscan.io/token/0xB1F1ee126e9c96231Cc3d3fAD7C08b4cf873b1f1). One token, one vote. |
| **Governance** | Off-chain [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) voting at [beefydao.eth](https://snapshot.box/#/s:beefydao.eth) (space opened December 2021; 130 proposals, 11,067 followers as of 6 August 2026). Any holder of 1 BIFI may propose. |
| **Treasury** | Multisigs on every chain Beefy runs on, signed by a 7-member Treasury Council on a [4-of-7 threshold](https://docs.beefy.finance/dao/treasury), formed September 2021. |
| **Funded by** | Vault performance fees only. No token emissions, no reserved allocation, no treasury BIFI stockpile to sell. |
| **Payroll** | [$145,500 per month](https://snapshot.box/#/s:beefydao.eth/proposal/0xb6ed8689ee9870bbb17b9c1ee4a8c722712e3c495146b84d96a546c051c48048) for contributors (Aug 2026 – Jan 2027), paid in stablecoins, approved by 31 voters. |

**Beefy** is a multichain yield optimizer that launched in September 2020 and has been governed since December 2021 by BIFI holders voting on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot). It sits beside [Yearn Finance](/wiki/daos/lending/yearn-finance) and [Convex Finance](/wiki/daos/lending/convex-finance) as one of the surviving first-generation yield aggregators, and its interest for a governance reader is not the vaults but the balance sheet behind them.

Almost every DAO in this directory can pay someone in its own token. Beefy cannot. BIFI's supply is fixed at 80,000 units, the contract has no mint function, and the treasury holds no undistributed allocation to draw down. That single design choice turns every governance decision Beefy makes into a cash decision, and it makes the DAO an unusually clean case study in what a governance organisation actually costs when the bill cannot be paid in inflation.

## A DAO with no seigniorage

The BIFI contract is four lines of substance: it mints 80,000 tokens to the treasury on initialisation and exposes no minting permission afterwards. Reading `totalSupply()` on the mainnet contract returns exactly 80,000 – the figure has not moved and structurally cannot. Beefy's own docs describe this as the point rather than an accident: over 90% of the supply went to the community within two months of the September 2020 launch, and the last founder's-fund emissions [expired in July 2022](https://docs.beefy.finance/dao/contributor-compensation).

The consequence is stated plainly on the same page: because the token was never designed as a payment instrument, Beefy has "a strong preference for any payments to be made in stablecoins, rather than BIFI". Compare that with the [compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) model most token-governed DAOs run, where a contributor budget denominated in dollars and settled in the governance token quietly transfers price risk from the treasury to the recipient. Beefy has no such lever. Its [operating cost](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) is a cash cost, funded out of revenue, every month.

This also removes a familiar attack surface. A DAO that can mint can dilute; a DAO with a fixed float and a treasury that has already distributed its holdings has nothing to dilute with. The trade is that it must earn what it spends.

## Where the money comes from

Beefy's vaults charge a performance fee on each harvest. Those fees are batched on-chain rather than forwarded per-harvest – Beefy found that sending small amounts immediately "depletes that cashflow with a corresponding increase in gas costs" – and the [Fee Batch](https://docs.beefy.finance/ecosystem/protocol/fee-batch) contract then splits the accumulated WETH two ways in a single multicall: part to the [incentive programmes](https://docs.beefy.finance/ecosystem/protocol/incentive-programmes) that pay BIFI holders, and part swapped to a stablecoin and sent to the treasury.

The holder side is worth reading as a governance design rather than a yield product. Holders can put BIFI in the BIFI Pool and receive WETH, or in the BIFI Vault and have the rewards auto-compounded into more BIFI. Beefy's stated reason for building these is defensive: freely circulating governance tokens, its docs argue, invite both liquidation cascades when they are used as loan collateral and "a parasitic takeover of the project, such as how [Convex](/wiki/daos/lending/convex-finance) was able to gain control over [Curve](/wiki/daos/dexs/curve-dao)". Paying holders to park their tokens in protocol-owned contracts is an explicit answer to the [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow) capture problem, reached without locking anyone up.

It also means the fee switch is not hypothetical here. Beefy has run revenue to tokenholders since inception, which puts it on the far side of the argument catalogued under [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual): the question for Beefy governance has never been whether to turn revenue on, only how to divide it.

## The payroll vote

Beefy's contributor budget is a recurring, itemised, public proposal – the clearest instance in this directory of a DAO putting its whole wage bill to a vote. [BIP:101](https://snapshot.box/#/s:beefydao.eth/proposal/0xb6ed8689ee9870bbb17b9c1ee4a8c722712e3c495146b84d96a546c051c48048), passed in July 2026, requests **$145,500 per month** covering August 2026 to January 2027, broken down as $104,250 for development, $23,750 for business development and $17,500 for marketing and design.

Two things changed with that proposal. The first is the term. Beefy had funded contributors quarterly, and the team argued for a six-month budget on the grounds that quarterly cycles "left contributors with uncertainty over their future and incurs more time each quarter for budget discussions than is desirable" – governance overhead named as a cost and traded away deliberately. The second is that the headline fell $3,000 while the actual spend did not: the reduction is matched by an increase in a service provider's budget in the [companion proposal](https://snapshot.box/#/s:beefydao.eth/proposal/0xc6c66e52e48eb12ac43aeb5bc80ef973dd542eaba52e17f44e9bbfbced38df70). A reader who tracks only the payroll line would record a cut that did not happen, which is the same reclassification problem that shows up in [operating-cost reporting](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) elsewhere.

The proposal is also candid that the budget is a ceiling rather than a forecast: recent months saw "actual payments undershooting the budgeted amount", and the six-month figure is presented as the maximum spend.

## Service providers, on renewal

Beefy buys parts of its operating team the way the [service-provider](/wiki/dao-governance/concepts/analysis/dao-service-providers) model describes: fixed-term engagements that expire and must be re-approved. Staworth Limited was [first engaged in January 2025](https://snapshot.org/#/s:beefydao.eth/proposal/0x7293b09c56e80bf7b655e6eea2a7c913d8ff6d8c3ee470b9f90349d0b196ea0e) for financial reporting, non-reserved legal work and general DAO support, and has been renewed on each expiry since – most recently in [BIP:102](https://snapshot.box/#/s:beefydao.eth/proposal/0xc6c66e52e48eb12ac43aeb5bc80ef973dd542eaba52e17f44e9bbfbced38df70), at $10,000 per month plus 20% VAT, for six months, aligned to the term of the main contributor budget. The renewal proposal makes its own case on delivery: roughly 130 vault strategies shipped in 2026 to that point, about five a week, plus tooling and accounting work.

Other line items renew on the same rhythm – ChainPatrol for brand and phishing takedowns, Octav for accounting data – each as its own proposal with its own vote. The pattern is worth noting because it is rarer than it looks: the engagement has a defined end date, the renewal is a public vote, and the vendor writes a delivery report to win it. Most DAO vendor relationships in this directory renew by silence.

## The budget got longer as the room got smaller

The turnout series on Beefy's own funding votes is a clean illustration of [governance participation decay](/wiki/dao-governance/concepts/analysis/voter-apathy), because the proposal type is held constant across two years – it is the same quarterly contributor budget each time:

- **129 voters** – BIP:77, Contributor Funding Q2 2024 (April 2024)
- **166 voters** – BIP:85, Profit Distribution Framework (December 2024), the series high
- **102 voters** – BIP:91, Contributor Funding Q3 2025 (July 2025)
- **44 voters** – BIP:97, Contributor Funding Q2 2026 (April 2026)
- **31 voters** – BIP:101, Contributor Funding H2 2026 (July 2026)

A 76% fall in voters on the same recurring question, against a space with 11,067 followers. The uncomfortable pairing is that the vote which extended the commitment from three months to six is also the thinnest of the series: the DAO lengthened the term of its largest recurring obligation at the point where the fewest members were watching.

Nothing in the rules catches this. The Beefy space sets its quorum at 1 unit of voting power, so a proposal cannot fail for want of turnout, and the 31 votes on BIP:101 split 2,122 for, zero against – a wide margin on a thin base. That is precisely the configuration the [quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) page treats as a false safeguard: a threshold set low enough never to bind tells you nothing about whether anyone read the proposal.

## When the token traded below the treasury

On 21 April 2026, BIFI's market capitalisation fell below what Beefy's Treasury Council considered the fair value of the assets behind it. [BIP:99](https://snapshot.box/#/s:beefydao.eth/proposal/0xef62f6c5745f7c898fc817329f843e608e8746c8ef5ccf388fd48fb7245948b3) asked for, and received, standing authority for the Council to buy BIFI back with treasury assets whenever it trades under that line. It passed with 5,376 voting power for and 152 against, on 76 voters – roughly double the turnout of the payroll votes either side of it.

The proposal's definition of "fair value" is the part worth reading. It is not treasury assets divided by supply. It is what the DAO "could reasonably be expected to receive if it successfully liquidated all of its available treasury assets and settled all of its ongoing payment obligations, divided by the remaining circulating supply" – with treasury-held BIFI removed from both the asset side and the circulating supply, and future payment obligations netted off. The proposal explicitly argues this figure is _lower_ than the naive treasury-divided-by-80,000 number some holders use, which is an unusual direction for a treasury to argue in. It is a discount-to-net-asset-value argument of the kind the [token valuation](/wiki/economics/token-valuation) page describes, made by the entity that would benefit from the more flattering version.

What it is not is a redemption right. The buyback is discretionary, exercised by a [council](/wiki/dao-governance/concepts/treasury/dao-treasury-management) on the open market at a price it computes; a holder who wants out sells into whatever bid exists. The distinction between that and a [rage-quit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is the difference between the treasury choosing to support a price and a member being able to claim a share.

## Who actually holds the votes

Beefy's voting strategy counts BIFI in five places at once: plain BIFI on Ethereum, BIFI held in a Uniswap V3 position on Ethereum, and mooBIFI – the receipt token for a BIFI Vault deposit – on Optimism, Base and Sonic. Delegation sits on top of the whole set.

This is a small design decision with a large effect. Because Beefy pays holders to deposit their BIFI into protocol contracts, a naive `balanceOf` strategy would have disenfranchised exactly the holders the incentive programme was built to attract, and it would have done so most severely for the most committed ones. Counting the receipt token, on every chain it lives on, is what keeps the [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) franchise aligned with the incentive design instead of fighting it – the same [activation problem](/wiki/dao-governance/concepts/voting/voting-and-delegation) other DAOs solve badly or not at all.

Day-to-day authority is delegated in the ordinary corporate sense rather than the on-chain one. Beefy's docs describe holders as "the legislature" and the core contributor team as "the executive wing", with any Core decision reviewable by a governance vote. There is no on-chain execution path: Snapshot votes are signalling, and the 4-of-7 Treasury Council [multisig](/wiki/dao-governance/tooling/treasury/safe) moves the money.

## How Caper approaches this

Beefy's buyback exists because BIFI holders have no way to claim the treasury directly. The token is a claim on a revenue stream and a vote, not on the assets; when the market prices it below those assets, closing the gap requires a council to notice, define a fair value, win a vote and then trade. Every one of those steps is discretionary, and none of them is available to an individual holder who simply wants their share.

[Caper](/wiki/foundations/what-is-a-caper) takes the other route. A member's claim on the treasury is a method they call themselves, and the share it pays out is the same canonical [vote weight](/wiki/governance/voting-mechanisms) that governs their say in the room – a function of both their governance tokens and their non-transferable vote record, so a large position alone does not buy either. There is no council to authorise it and no discount to argue about: the payout is computed from the contract's own state at the moment of the call.

That does not make Caper better at running a payroll, which is the thing Beefy demonstrably does well and in public. It makes the two answer different halves of the same question. Beefy's design asks how a DAO with no seigniorage sustainably pays its people; Caper's asks what a member can do about it when they conclude the answer is wrong.

## References

- Beefy DAO, [beefydao.eth Snapshot space](https://snapshot.box/#/s:beefydao.eth) – 130 proposals, 11,067 followers, quorum 1, delegation-aware BIFI strategy across five sources (read via the Snapshot GraphQL hub, 6 August 2026).
- Beefy DAO, [BIP:101 Contributor Funding H2 2026](https://snapshot.box/#/s:beefydao.eth/proposal/0xb6ed8689ee9870bbb17b9c1ee4a8c722712e3c495146b84d96a546c051c48048) – $145,500 per month, departmental breakdown, and the quarterly-to-six-month rationale.
- Beefy DAO, [BIP:102 Staworth Renewal H2 2026](https://snapshot.box/#/s:beefydao.eth/proposal/0xc6c66e52e48eb12ac43aeb5bc80ef973dd542eaba52e17f44e9bbfbced38df70) – $10,000 + 20% VAT per month, delivery report, and the offsetting reduction in BIP:101.
- Beefy DAO, [BIP:99 Fair Value Buybacks](https://snapshot.box/#/s:beefydao.eth/proposal/0xef62f6c5745f7c898fc817329f843e608e8746c8ef5ccf388fd48fb7245948b3) – the 21 April 2026 trigger and the Treasury Council's fair-value definition.
- Beefy docs, [Governance](https://docs.beefy.finance/dao/governance), [Treasury](https://docs.beefy.finance/dao/treasury) and [Contributor Compensation](https://docs.beefy.finance/dao/contributor-compensation) – the legislature/executive split, the 4-of-7 Treasury Council, and the stablecoin-payment preference.
- Beefy docs, [$BIFI Token](https://docs.beefy.finance/ecosystem/bifi-token), [Fee Batch](https://docs.beefy.finance/ecosystem/protocol/fee-batch) and [Incentive Programmes](https://docs.beefy.finance/ecosystem/protocol/incentive-programmes) – the 80,000 fixed supply, the fee split, and the anti-capture case for the BIFI Pool and Vault.
- BIFI token contract [0xB1F1…b1f1](https://etherscan.io/token/0xB1F1ee126e9c96231Cc3d3fAD7C08b4cf873b1f1) on Ethereum – `totalSupply()` returns 80,000 exactly, verified 6 August 2026.
- Beefy, [beefyfinance/beefy-contracts](https://github.com/beefyfinance/beefy-contracts) and [beefy-v2](https://github.com/beefyfinance/beefy-v2) – both actively maintained as of August 2026.

## Compound DAO

URL: https://caper.network/wiki/daos/lending/compound-dao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Compound DAO |
| **Type** | Protocol DAO (lending / money market) |
| **Governance token** | COMP (10,000,000 fixed supply; distributed to users from June 2020) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain voting via Governor Bravo + Timelock |
| **Key parameters** | Propose ≥ 25,000 COMP · 400,000-vote quorum · 3-day vote · 2-day timelock |
| **Treasury** | On-chain reserves controlled by the Timelock (track live on DeepDAO) |
| **Notable for** | Launched DeFi liquidity mining (2020); authored the Governor + Timelock contracts that became the industry on-chain-governance template |
| **Primary sources** | [docs.compound.finance](https://docs.compound.finance/), [comp.xyz](https://www.comp.xyz/), [governance portal](https://compound.finance/governance) |
| **Related** | [Uniswap DAO](/wiki/daos/dexs/uniswap-dao), [Aave DAO](/wiki/daos/lending/aave-dao), [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) |

The **Compound DAO** governs [Compound](https://compound.finance/), one of DeFi's original algorithmic money markets, where users supply assets to earn interest and borrow against overcollateralized positions. Its lasting influence on the industry is less about the protocol than about how it is _run_: Compound authored the **Governor + Timelock** contract pattern that most on-chain DAOs — Uniswap, ENS, and hundreds more — still copy today. Control over the protocol's markets, its risk parameters, and its treasury rests entirely with holders and delegates of the **COMP** token, deciding by [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain vote.

## COMP and the birth of liquidity mining

Compound distributed its **COMP** governance token beginning in **June 2020**, streaming it automatically to anyone supplying or borrowing on the protocol rather than selling it in a sale. The mechanism — later universally called **liquidity mining** or "yield farming" — kicked off the **"DeFi summer"** capital rush and became the default playbook for bootstrapping a DAO's token distribution. COMP has a fixed supply of **10,000,000** tokens and, like most governance tokens, originally conferred votes but no direct claim on protocol revenue. ([Compound: the COMP token](https://compound.finance/governance/comp); [CoinDesk, 2020](https://www.coindesk.com/business/2020/10/20/with-comp-below-100-a-look-back-at-the-defi-summer-it-sparked))

## Governor Bravo — the on-chain governance template

Compound governance is three contracts working together: the **COMP** token (which tracks voting weight and supports [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation)), the **Governor Bravo** module (which runs proposals and vote tallies), and a **Timelock** (which holds the admin keys and enforces a delay before any approved change executes). The canonical parameters are baked in:

- **Proposal threshold — 25,000 COMP.** An address must hold or be delegated at least 25,000 COMP to submit a proposal, a spam filter that also concentrates proposing power.
- **2-day review, then a 3-day vote.** After a short review delay, voting is open for roughly three days; voting weight is snapshotted at the block the proposal starts, so tokens bought afterwards do not count.
- **400,000-vote quorum.** A proposal passes only with a majority _and_ at least 400,000 votes cast in favour.
- **2-day timelock.** A passed proposal is queued in the Timelock and can be executed two days later, giving the community a window to react before code changes land.

"Bravo" was the 2021 upgrade to the original Governor Alpha, adding an upgradeable delegator pattern and vote-reason strings. Because the contracts were audited, permissionless, and copy-pasteable, they became the reference implementation for the whole [propose → vote → timelock → execute](/wiki/dao-governance/concepts/voting/proposal-lifecycle) lifecycle — the same skeleton [most protocol DAOs](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) run on. Forks are everywhere: [Ondo Finance](/wiki/daos/lending/ondo-finance)’s Flux Finance lending market runs a Governor Bravo fork with a 100,000,000-ONDO proposal threshold, one of many protocols that inherited these exact contracts wholesale. ([Compound v2 docs: Governance](https://docs.compound.finance/v2/governance/); [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol))

## Governance in practice — and under attack

Compound's model has been stress-tested in public. In 2024 a group nicknamed the **"Golden Boys,"** led by an activist known as **Humpy**, accumulated and delegated enough COMP to pass **Proposal 289** — a bid to move roughly **499,000 COMP (~$24M)** of DAO reserves into a "goldCOMP" yield vault the group would influence. It cleared the on-chain vote before the community mobilized; after intense backlash the proposers agreed to **rescind it**. The episode is now a textbook case of a [governance attack](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) executed entirely within the rules — no exploit, just concentrated voting power aimed at the treasury. ([Unchained, 2024](https://unchainedcrypto.com/compound-governance-attackers-agree-to-cancel-proposal-in-exchange-for-staking-product/))

The DAO continues to steer real money: in mid-2026 its **Treasury Management Committee** issued a request for professional managers to steward an initial **~$20–25M** of reserves (submissions due **24 June 2026**), part of a broader industry move to put idle DAO treasuries to work — the collective on-chain DAO treasury crossed **$26B** in Q1 2026 per [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao). ([Compound RFP: Treasury Management Program](https://www.comp.xyz/t/request-for-proposals-rfp-compound-dao-treasury-management-program/7867))

## How Caper approaches this

Compound's Governor Bravo showed the industry how to make a vote binding on-chain — but Prop 289 also showed its soft spot: enough delegated tokens can point the whole treasury at an exit, and dissenters have no way out but to sell COMP on the open market. A [caper](/wiki/foundations/what-is-a-caper) keeps the binding-execution property — every approved [PAYOUT or INVEST proposal](/wiki/governance/proposals) settles on-chain — but pairs it with a standing exit: a member who dislikes where a vote is heading can [redeem a treasury share sized by their own vote weight](/wiki/governance/execution) directly rather than dumping into a market. And Caper's [voting weight](/wiki/governance/voting) deliberately does not reduce to "tokens delegated at a snapshot block," which is the exact lever Prop 289 pulled. The mechanics are described neutrally on those Caper pages.

## References

- [Compound documentation](https://docs.compound.finance/) — protocol and governance reference.
- [Compound v2 docs: Governance](https://docs.compound.finance/v2/governance/) — Governor Bravo parameters.
- [Compound Community Forum (comp.xyz)](https://www.comp.xyz/) — where proposals originate.
- [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) — the on-chain governor contract.
- [Unchained: Golden Boys agree to rescind Proposal 289](https://unchainedcrypto.com/compound-governance-attackers-agree-to-cancel-proposal-in-exchange-for-staking-product/) (2024).

## Convex Finance

URL: https://caper.network/wiki/daos/lending/convex-finance
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Name** | Convex Finance |
| **Type** | Meta-governance / "liquid locker" — a vote-aggregation layer built on top of [Curve](/wiki/daos/dexs/curve-dao) (DeFi, Ethereum) |
| **Governance token** | CVX — [100,000,000 max supply](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx), minted pro-rata to CRV earned on a declining curve. 99,984,078.08 minted as of 9 August 2026, 09:14 UTC: the curve has reached its final cliff and 15,921.92 CVX remain to be issued, ever. |
| **Governance model** | [vlCVX](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx/vote-locking) — vote-locked CVX, minimum 16-week lock (`lockDuration()` = 9,676,800 seconds on-chain). 45,739,877.54 CVX locked, 45.75% of supply. |
| **Launched** | May 2021 |
| **What it governs** | Convex's own treasury and, indirectly, [Curve](/wiki/daos/dexs/curve-dao) gauge-weight emissions via the veCRV it controls — 419,428,844 veCRV, **53.68%** of the total, at block 25,716,457 |
| **Contracts** | [CVX token](https://eth.blockscout.com/address/0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B) · [veCRV voter proxy](https://eth.blockscout.com/address/0x989AEb4d175e16225E39E87d0D97A3360524AD80) · [vlCVX locker (CvxLockerV2)](https://eth.blockscout.com/address/0x72a19342e8F1838460eBFCCEf09F6585e32db86E) |
| **Links** | [convexfinance.com](https://www.convexfinance.com/) · [docs](https://docs.convexfinance.com/) · [@ConvexFinance](https://x.com/ConvexFinance) |

**Convex Finance** is not a DAO that governs a product of its own so much as a _governance layer built on top of another DAO_. It sits on [Curve](/wiki/daos/dexs/curve-dao) and solves the coordination problem that [vote-escrow](/wiki/dao-governance/concepts/treasury/dao-tokenomics) created: to earn Curve's maximum reward boost and to steer weekly CRV emissions, you had to lock CRV as veCRV for up to four years — illiquid, non-transferable, and pointless at small size. Convex lets holders pool that lock. You [deposit CRV](https://docs.convexfinance.com/convexfinance/general-information/why-convex/convex-for-crv-stakers), Convex locks it as veCRV on your behalf and votes the whole accumulated balance as a single bloc. Within months of its May 2021 launch Convex controlled [more than half of all veCRV](https://tokenbrice.xyz/crv-wars/), making it the effective power broker — the "kingmaker" — of Curve governance and the central character in the [Curve Wars](/wiki/daos/dexs/curve-dao). Five years on it still does, and the sections below check that claim against the chain rather than repeating it.

## The bloc, measured

Every figure here is a direct read of Ethereum mainnet at block 25,716,457 (9 August 2026, 09:14 UTC). The voter-proxy address is not taken from a dashboard: it is what the CVX token contract itself returns from `vecrvProxy()`.

|  |  |
| --- | --- |
| **veCRV held by the Convex voter proxy** | 419,428,844.59 |
| **veCRV total supply** | 781,351,819.47 |
| **Convex's share of the vote** | **53.68%** |
| **CRV locked by the Convex voter proxy** | 423,602,486.28 |
| **CRV locked in the escrow, all holders** | 850,886,947.22 |
| **Convex's share of the locked coins** | 49.78% |
| **Convex's lock expiry** | 25 July 2030 (the four-year maximum, continuously re-locked) |

The two shares do not match, and the gap is the whole point of a perpetual lock. Convex holds **under half the locked CRV but over half the voting weight**, because veCRV decays linearly toward its unlock date: a holder who locked for a year eighteen months ago has nothing left, while Convex's proxy is bumped back out to the four-year maximum and therefore sits permanently near its full weight. The bloc does not have to grow to keep the majority — it only has to stop decaying while everyone else's does. That is a structural feature of [the vote-escrow design](https://docs.curve.finance/user/vecrv/what-is-vecrv) rather than anything Convex added, and it is the mechanism that makes the [2021 kingmaker result](https://tokenbrice.xyz/crv-wars/) durable rather than a snapshot.

## cvxCRV — a liquid, boosted claim on a permanent lock

When you deposit CRV into Convex you receive **cvxCRV** in return. The underlying CRV is locked as veCRV essentially _forever_ — Convex keeps re-locking it at the maximum term, so the deposit is [one-way](https://docs.convexfinance.com/convexfinance/general-information/why-convex/convex-for-crv-stakers): cvxCRV can only be exited by selling it on the secondary market, never redeemed back into the locked CRV. In exchange, cvxCRV stakers receive the veCRV yield — trading fees, the CRV boost, and a cut of the bribes below — without ever managing a lock themselves. Convex takes a [17% platform fee](https://docs.convexfinance.com/convexfinance/faq/fees) on all CRV revenue: 10% to cvxCRV stakers, 4.5% to CVX/vlCVX lockers (paid as cvxCRV), 2% to the treasury, and 0.5% to whoever calls the harvest.

**That exit is not priced as a rounding error.** On 9 August 2026, 09:14 UTC, cvxCRV traded at $0.11469 against CRV's $0.22717 — [50.5 cents on the dollar](https://coins.llama.fi/prices/current/ethereum:0x62B9c7356A2Dc64a1969e19C23e4f579F9810Aa7,ethereum:0xD533a949740bb3306d119CC777fa900bA034cd52), a **49.5% discount**, with [an independent price feed](https://api.coingecko.com/api/v3/simple/price?ids=curve-dao-token,convex-crv&vs_currencies=usd) agreeing to four decimal places. The discount is the market's standing quote on irreversibility: a cvxCRV holder owns the yield of a lock that runs to 2030 and no way to reach the principal, and buyers price that gap rather than arbitrage it away. Anyone reading a liquid-locker receipt as a soft-peg substitute for the underlying asset should read this number first — it is the clearest live evidence on the wiki that [an exit route you cannot actually take](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is worth roughly half of one you can.

## vlCVX, Votium, and the vote market

Depositing CRV hands Convex the voting power; the second token, **CVX**, decides how that power is used. To vote on Curve gauge weights through Convex — or on Convex's own proposals — a holder must [vote-lock their CVX](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx/vote-locking) into **vlCVX** for a minimum of 16 weeks (16 epochs). vlCVX holders direct the bloc and earn a share of protocol fees. Because a single vlCVX vote moves a large, aggregated chunk of veCRV, an entire **bribe market** grew up around it: on [Votium](https://docs.votium.app/general-information/why-votium), any protocol that wants Curve emissions steered toward its own pool posts an incentive, and vlCVX voters who delegate their vote collect it — [96% to voters, 4% to Votium](https://docs.votium.app/faq/fees). This turned governance influence into a rentable, cash-flowing commodity, and the pattern spread: [Aura Finance](https://aura.finance/) is the same liquid-locker model rebuilt on top of [Balancer's](/wiki/daos/dexs/balancer-dao) veBAL. It is the canonical worked example on the [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) page: locking a token couples influence to commitment, but once the lock is tokenised the influence can simply be bought a layer up.

## The mint that bought the bloc has closed

CVX was never handed out on a calendar. The [deployed token contract](https://eth.blockscout.com/address/0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B) mints it as a side effect of Convex claiming CRV for its liquidity providers, on a step function written into `mint()`:

```
uint256 cliff = supply.div(reductionPerCliff);   // reductionPerCliff = 100,000e18
if (cliff < totalCliffs) {                       // totalCliffs = 1000
    uint256 reduction = totalCliffs.sub(cliff);
    _amount = _amount.mul(reduction).div(totalCliffs);
    ...
}
```

Each 100,000 CVX minted advances one cliff and cuts the CVX-per-CRV rate by a further 0.1%. At block 25,716,457 the supply is **99,984,078.08 of a hard 100,000,000 cap** — cliff 999 of 1000. The reduction multiplier is therefore `1/1000`: a liquidity provider whose CRV claim would have minted a full CVX in 2021 now mints a thousandth of one, and clearing the remaining **15,921.92 CVX** would take roughly 15.9 million CRV of future claims. Note also what the branch does not have: an `else`. Once `cliff` reaches 1000, `mint()` runs, mints nothing, and returns successfully — the reward pipeline never reverts, it just quietly stops paying in CVX.

The governance consequence is larger than the tokenomics one. CVX was the subsidy that _bought_ the veCRV majority: supply liquidity, earn CRV, receive CVX, and with it a claim on the direction of Curve's emissions. That route is now effectively closed. The bloc it purchased is permanent and still votes, but nobody can earn their way into steering it any more — the only remaining path to Curve's gauge weight is buying CVX from someone who already holds it, at whatever price they name. A distribution mechanism that reads as generous while it runs becomes an [enclosure](/wiki/dao-governance/concepts/fundamentals/governance-minimization) the moment it finishes, and the finishing line here is a single integer comparison in a contract deployed five years ago.

## CVX tokenomics and the meta-governance model

CVX has a fixed [100 million maximum supply](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx). Rather than a time-based schedule, CVX is minted every time Convex claims CRV for its liquidity providers, and the CVX-per-CRV ratio steps down as more CVX enters circulation — issuance that tapered automatically as the protocol matured, and that has now, as the section above measures, essentially run out. That design made CVX itself the object of accumulation: because vlCVX controls Curve's emission gauges, buying and locking CVX is the cheapest way to command veCRV influence, which is why treasuries such as [Curve-adjacent protocols](/wiki/daos/dexs/curve-dao) and, at its peak, [Frax](/wiki/daos/stablecoins/frax-finance) and [others](https://tokenbrice.xyz/crv-wars-l2/) amassed large vlCVX positions. Convex is the clearest demonstration of **meta-governance** as a market: the right to direct another DAO's parameters became a liquid asset with its own token, its own yield, and its own [attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), all layered on top of the base protocol without its explicit consent.

## A sixteen-week electorate voting a lock that runs to 2030

Read the two commitments side by side and they are not the same commitment at all. The CRV underneath is locked until **25 July 2030** and re-locked before it can ever run down. The people who decide how that stake votes are committed for **16 weeks** — `lockDuration()` on the [vlCVX locker](https://eth.blockscout.com/address/0x72a19342e8F1838460eBFCCEf09F6585e32db86E) returns exactly 9,676,800 seconds, and the contract was on its 233rd weekly epoch at block 25,716,457. A vlCVX holder can lock, steer four and a half years of somebody else's escrowed capital through 16 weekly gauge votes, take the [Votium incentives](https://docs.votium.app/general-information/why-votium) that came with them, and walk.

The electorate is also a minority of a minority. 45,739,877.54 CVX is vote-locked — 45.75% of all CVX in existence — which means a bloc that is itself under half the token steers 53.68% of Curve's gauge weight, which in turn directs emissions against 850.9 million CRV of locked capital. None of that is hidden or illicit; it is what every layer of the stack was designed to do. But it is a precise measurement of the thing the vote-escrow model was invented to prevent. Curve made influence expensive in _time_ so that whoever steered emissions would still be there to live with the result. Convex kept the four-year time cost on the capital and reduced the time cost on the _decision_ to sixteen weeks, and the difference between those two numbers is where the [vote market](https://docs.votium.app/faq/fees) makes its money. Duration mismatch between the stake and the voter is the structural defect worth carrying away from this page — see [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) and [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) for where else it shows up.

## How Caper approaches this

Convex is what happens when a lock becomes a product: veCRV was meant to tie influence to commitment, and Convex financialised exactly that bond — CVX is freely transferable, vlCVX voting rights are [rented out on an open market](https://docs.votium.app/general-information/why-votium), and control of Curve drifted toward whoever could pay. A [caper](/wiki/foundations/what-is-a-caper) chases the same goal — coupling say to genuine commitment — but leaves nothing for a Convex-style layer to aggregate. Its [voting weight](/wiki/governance/voting) multiplies the _stake_ a member holds by the _participation_ they have actually earned, and that participation record is **soulbound** — minted to the member and non-transferable, so it cannot be pooled, tokenised, or rented to a third party. Holdings still matter (a bigger position is a larger factor in the weight), but the earned half is not for sale, so no external cartel can buy a controlling bloc the way Convex did over Curve. And a caper has [no emission gauges](/wiki/markets/bonding-curve) to steer — its tokens come from a bonding curve, not a weekly inflation vote — so there is no emission stream for a "war" to capture in the first place.

The duration mismatch resolves differently too, because a caper has no lock to mismatch against. There is no escrow term and no unlock date to wait out: a member [exits](/wiki/markets/trading) whenever they choose, surrendering their governance tokens and their soulbound vote tokens together, and the treasury share they receive is _the same weight formula they voted with_. Commitment is not enforced by freezing anyone in place; it is enforced by making the value of leaving and the power of staying the same number. This is a design contrast, not a claim of superiority; the mechanics are on the linked pages and verified against the contract.

## References

- [Convex Finance documentation](https://docs.convexfinance.com/) — [Understanding CVX](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx), [vote-locking](https://docs.convexfinance.com/convexfinance/general-information/understanding-cvx/vote-locking), and [fees](https://docs.convexfinance.com/convexfinance/faq/fees) (primary).
- [Convex — for CRV stakers](https://docs.convexfinance.com/convexfinance/general-information/why-convex/convex-for-crv-stakers): the cvxCRV deposit and permanent-lock mechanics (primary).
- **On-chain state, Ethereum block 25,716,457 (9 August 2026, 09:14 UTC)**, read directly and reproducible with `eth_call`: [ConvexToken (CVX)](https://eth.blockscout.com/address/0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B) — `totalSupply()`, `maxSupply()`, `totalCliffs()`, `reductionPerCliff()`, `vecrvProxy()`; [Curve VotingEscrow](https://eth.blockscout.com/address/0x5f3b5DfEb7B28CDbD7FAba78963EE202a494e2A2) — `totalSupply()`, `supply()`, `balanceOf()` and `locked()` for the proxy; [CvxLockerV2 (vlCVX)](https://eth.blockscout.com/address/0x72a19342e8F1838460eBFCCEf09F6585e32db86E) — `lockedSupply()`, `lockDuration()`, `epochCount()`. The verified source of `mint()` quoted above is on the [CVX contract page](https://eth.blockscout.com/address/0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B?tab=contract) (primary).
- [DefiLlama price feed](https://coins.llama.fi/prices/current/ethereum:0x62B9c7356A2Dc64a1969e19C23e4f579F9810Aa7,ethereum:0xD533a949740bb3306d119CC777fa900bA034cd52) and [CoinGecko](https://api.coingecko.com/api/v3/simple/price?ids=curve-dao-token,convex-crv&vs_currencies=usd) — the cvxCRV/CRV ratio, cross-checked between two independent sources on the same day.
- [Votium documentation](https://docs.votium.app/) — the vlCVX incentive/bribe marketplace and its [96/4 fee split](https://docs.votium.app/faq/fees) (primary).
- [Curve — what is veCRV](https://docs.curve.finance/user/vecrv/what-is-vecrv): the lock term, the linear decay, and the boost the lock buys (primary).
- TokenBrice, [CRV Wars](https://tokenbrice.xyz/crv-wars/) and [Advanced CRV warfare](https://tokenbrice.xyz/crv-wars-l2/) — analysis of Convex's veCRV dominance and the protocols built on it.
- [Aura Finance](https://aura.finance/) — the liquid-locker model applied to Balancer's veBAL.

## Euler (EUL)

URL: https://caper.network/wiki/daos/lending/euler
Updated: 2026-07-23

| Type | Permissionless lending protocol / modular credit layer (DeFi) |
| --- | --- |
| Token | EUL (governance) |
| Governance | Euler DAO — EUL token voting via the [Euler Improvement Proposal (EIP) process](https://snapshot.org/#/eulerdao.eth) |
| Launched | v1 December 2021; [Euler v2 September 2024](https://cryptobriefing.com/euler-v2-launch-decentralized/) |
| Chain | Ethereum (v2 also multi-chain) |
| Notable event | [March 2023 $197M exploit](https://www.chainalysis.com/blog/euler-finance-flash-loan-attack/), with funds [returned in full](https://www.theblock.co/post/224705/euler-hacker-returns-funds) |

## Overview

[Euler](https://www.euler.finance/) is a permissionless lending protocol on Ethereum, governed by the **Euler DAO** through its **EUL** token. Euler v1 launched in December 2021 as a reactive-interest-rate money market that let anyone list a lending market for almost any ERC-20 asset without a central listing gate — a contrast to the curated asset lists of [Aave](/wiki/daos/lending/aave-dao) and [Compound](/wiki/daos/lending/compound-dao).

After a [$197 million exploit in March 2023](https://www.chainalysis.com/blog/euler-finance-flash-loan-attack/) — the largest DeFi hack of that year — and the subsequent [return of the stolen funds](https://www.theblock.co/post/224705/euler-hacker-returns-funds), the team rebuilt the protocol from scratch. [Euler v2 shipped in September 2024](https://cryptobriefing.com/euler-v2-launch-decentralized/) as a _modular_ credit layer: instead of one monolithic pool, it is a toolkit for deploying and connecting independent lending vaults. That architecture is what makes Euler structurally distinct from every other lending DAO in this directory.

## The 2023 exploit and the recovery

On 13 March 2023 an attacker drained roughly **$197 million** from Euler v1 in a flash-loan attack that exploited a missing health-check in the protocol's `donateToReserves` function, letting the position be pushed into a state where the liquidation logic mispriced the collateral. [Chainalysis](https://www.chainalysis.com/blog/euler-finance-flash-loan-attack/) documented it as the largest DeFi exploit of 2023.

What followed is a widely cited case study in on-chain negotiation. Over roughly three weeks the Euler team combined public appeals, a bounty offer, and back-channel messages sent as on-chain transactions; the attacker ultimately [returned effectively all recoverable funds](https://www.theblock.co/post/224705/euler-hacker-returns-funds), and Euler used the reclaimed assets to make depositors whole. The team's own [post-mortem](https://www.euler.finance/blog/war-peace-behind-the-scenes-of-eulers-240m-exploit-recovery) recounts the recovery in detail. The episode is a useful counterpoint to the assumption that a "DAO" resolves a crisis by vote: the recovery was coordinated by the core team, with governance ratifying the redistribution afterward — the pattern documented on [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail), where decisive crisis response tends to route through a small core rather than a token vote.

## Euler v2: modular vaults and the EVK

Euler v2 is not a single lending contract. It is a system of [ERC-4626 vaults](https://docs.euler.finance/lite-paper/) built with the **Euler Vault Kit (EVK)** — a vault-development toolkit that, per the [EVK white paper](https://docs.euler.finance/euler-vault-kit-white-paper/), is deliberately agnostic about governance, upgradability, and oracle choice. Anyone can deploy a lending vault permissionlessly and configure its own collateral set, interest-rate model, oracle, and liquidation parameters.

Each vault is an isolated lending market: lenders deposit an asset, borrowers post collateral held in other vaults, and the vault's parameters bound the risk. Because vault creation is open, Euler v2 supports a long tail of markets — from blue-chip pairs to exotic or real-world-asset collateral — that a monolithic, DAO-curated pool would never list. Two products sit on top of the kit: **EulerEarn**, ERC-4626 yield aggregators that route deposits across vaults, and **EulerSwap**, an AMM that borrows against vault liquidity.

## The Ethereum Vault Connector

Isolated vaults would fragment liquidity if they could not share collateral. The **[Ethereum Vault Connector (EVC)](https://evc.wtf/)** is the interoperability primitive that solves this: it lets a vault recognise a deposit sitting in a _different_ vault as collateral for a loan, and it batches multi-step operations (deposit, enable-collateral, borrow) into a single atomic call while deferring the account health check to the end.

The EVC is an open-source standard, not Euler-specific plumbing — other protocols can build on it. In practice it turns Euler v2 into a network of composable credit markets: vault creators chain vaults together so that liquidity deposited in one market can back borrowing in another, recovering the capital efficiency that pure market isolation would otherwise sacrifice. This is the same isolation-vs-composability tension explored on the [Morpho](/wiki/daos/lending/morpho) page, reached by a different design.

## Governed, ungoverned, and escrow vaults

The EVK draws a sharp line between vaults that a manager can change and vaults whose rules are frozen. A [governed vault](https://docs.euler.finance/lite-paper/) hands a DAO, a professional risk manager, or an individual ongoing authority over its parameters — loan-to-value ratios, interest-rate model, accepted collateral — so passive lenders are effectively trusting that governor. An **ungoverned (finalised)** vault has fixed parameters and no active manager; its two variants, `0x` and `nzx`, differ only in whether the collateral it accepts itself carries any governance exposure. **Escrow** vaults hold deposits usable only as collateral, earn no interest, and are ungoverned by construction.

This is the heart of Euler's governance model: the protocol base layer is immutable, and risk curation is pushed to the vault level. A depositor chooses their trust assumption by choosing a vault, rather than inheriting one global risk surface set by a single DAO.

## What the Euler DAO controls

Because the base protocol is immutable and anyone can spin up an ungoverned vault, the [Euler DAO](https://forum.euler.finance/) does not sit astride a single monolithic risk surface the way an [Aave](/wiki/daos/lending/aave-dao)-style money-market DAO does. EUL-weighted votes, run through the Euler Improvement Proposal (EIP) process, instead direct: the [protocol treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and any fee switch; which _official_ governed vaults Euler Labs curates and surfaces in the front end; grants and incentive programmes; and the parameters of the governed vaults the DAO itself operates. The permissionless long tail of ungoverned vaults is outside the DAO's reach by design — a division of labour between a governed core and an open periphery that few lending DAOs make explicit.

## How Caper approaches this

Euler's control token, EUL, is freely tradeable: voting power over the governed core and the treasury is capital that can be bought on the open market. That is the standard DeFi arrangement, and it is the thing a [caper](/wiki/foundations/what-is-a-caper) deliberately does not replicate. In Caper, a member's influence is set by a canonical vote weight `w = (t · v) / (V · T)` that folds together how much of the token they hold (`t`) and a _soulbound, non-transferable_ proof-of-vote balance (`v`) earned by actually voting — the `v` factor cannot be purchased or moved between wallets.

The same weight drives the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): a member redeems a share of the treasury proportional to that weight and burns their vote balance on the way out. A large bag still matters — `t` is a multiplier, so holdings are not irrelevant — but a bag alone cannot capture control the way accumulating EUL can, and the treasury claim is a first-class protocol primitive rather than something a governed vote has to be trusted to honour. Where Euler curates trust at the vault level, a caper builds the accountability into the weight itself.

## Maple Finance

URL: https://caper.network/wiki/daos/lending/maple-finance
Updated: 2026-07-26

|  |  |
| --- | --- |
| **Type** | On-chain institutional credit / private-credit marketplace, governed by a token-holder DAO |
| **Governance token** | [SYRUP](https://maple.finance/syrup) (and staked **stSYRUP**) – the sole governance token since the 2025 MPL migration |
| **Governance process** | Maple Improvement Proposals (MIPs) on the [Maple Governance Forum](https://community.maple.finance) |
| **Products** | Syrup (permissionless _syrupUSDC/syrupUSDT_ yield); Maple Institutional (permissioned lending pools) |
| **Chains** | Ethereum (mainnet since May 2021), Solana, and other integrations |
| **Founded** | 2019, by Sidney Powell and Joe Flanagan (Australia) |
| **Reference** | [maple.finance](https://maple.finance) · [docs](https://docs.maple.finance/) · [DeFiLlama](https://defillama.com/protocol/maple) · [Messari](https://messari.io/project/syrup) |

**Maple Finance** is an on-chain credit business that runs as a token-holder DAO. Where a [peer-to-pool money market](/wiki/daos/lending/aave-dao) lends against volatile crypto collateral, Maple originates _institutional_ loans – over-collateralised digital-asset credit, and tokenised exposure to real-world private credit – and packages the yield into stablecoin products anyone can hold. The protocol has described itself as building “onchain asset management since 2019” ([maple.finance/about](https://maple.finance/about)); it launched on Ethereum mainnet in May 2021 and, by its [own reporting and DeFiLlama](https://defillama.com/protocol/maple), grew assets under management into the multi-billion range through 2025–2026 as the “RWA on-chain” thesis matured.

## What the DAO actually governs

Maple is a governance-over-a-business, not a governance-of-a-primitive. Holders of [SYRUP](https://maple.finance/syrup) do not vote loan-by-loan; they set the _policy_ around an operating credit desk: how protocol revenue is used, what the token’s emission and buyback schedule looks like, which strategic initiatives the treasury funds, and how the two product surfaces – permissionless **Syrup** and permissioned **Maple Institutional** – are resourced. Day-to-day underwriting, borrower diligence and pool management sit with the Maple team and its delegates; the DAO governs the economic frame they operate inside. That split – a professional credit operation wrapped in token governance – puts Maple closer to [Ondo](/wiki/daos/lending/ondo-finance) and other real-world-asset issuers than to a fully permissionless lending protocol.

## From MPL to SYRUP: collapsing to one token

Maple originally ran a two-token design (MPL and staked xMPL). Through 2023–2025 the DAO rebuilt its tokenomics on-chain via proposals: [MIP-009](https://community.maple.finance/t/mip-009-upgrade-mpl-token-design/300) upgraded the token design and set a defined inflation schedule, and [MIP-010/011](https://docs.maple.finance/maple-for-token-holders/mpl-token/mpl-token-migration) opened a one-time conversion of **1 MPL → 100 SYRUP**, explicitly structured so migrating holders were not diluted. The migration window closed in [April–May 2025](https://maple.finance/insights/syrup-token-launch-staking-and-conversion-of-mpl-to-syrup), after which SYRUP and stSYRUP became the _sole_ governance tokens. Total supply follows a governance-approved schedule projected toward roughly 1.27 billion SYRUP by late 2026.

## A DAO that legislated away its own discretion

Maple’s most instructive governance feature for the wider DAO industry is what it did to its _treasury and revenue policy_. Rather than leave buybacks and fund allocations to case-by-case votes, the DAO has used successive MIPs to make those decisions increasingly automatic:

- [MIP-019](https://community.maple.finance/t/mip-019-activate-the-ssf-and-sunset-staking/1042) (Oct 2025) activated the **Syrup Strategic Fund (SSF)** – directing 25% of protocol revenue to token buybacks and treasury growth – and _sunset_ the old staking-rewards program, tying value to revenue instead of inflation.
- [MIP-021](https://community.maple.finance/t/mip-021-a-rules-based-buyback-that-scales-with-revenue/1153) replaced discretionary buyback sizing with a **rules-based** model that scales with revenue.
- [MIP-023](https://community.maple.finance/t/mip023-proposal-hyper-programmatic-revenue-model-and-governance-parity/1152) (2026) pushed further to a **~90% fully programmatic** SYRUP buyback, leaving governance to set the rules rather than pull the levers.

The arc – discretionary → rules-based → programmatic – is a live example of a treasury DAO deliberately narrowing the surface where a vote (or a signer) can act, to reduce the gap between a passed policy and its execution. Coverage: [The Defiant on MIP-019](https://thedefiant.io/news/defi/stsyrup-holders-vote-to-end-staking-rewards-launch-syrup-strategic-fund).

## Products: Syrup and Maple Institutional

**Syrup** is the permissionless surface: depositors mint yield-bearing _syrupUSDC_ / _syrupUSDT_, whose market cap crossed $1 billion in late 2025, earning yield sourced from Maple’s lending activity plus a points-style **Drips** rewards program that multiplies with longer capital commitments. **Maple Institutional** is the permissioned surface, where vetted borrowers access over-collateralised digital-asset credit and where Maple has built facilities such as an on-chain warehouse line for asset-backed loans. Both surfaces feed the same revenue engine that the SSF now taps for buybacks. Live figures are best read from [DeFiLlama](https://defillama.com/protocol/maple) and [Messari](https://messari.io/project/syrup) rather than a fixed number, since AUM moves with subscriptions and credit demand.

## Where Maple sits in the DAO landscape

Maple is one of the clearest cases of a DAO governing a _credit institution_ rather than an automated protocol. It shares the real-world-asset frame with [Ondo Finance](/wiki/daos/lending/ondo-finance), the yield-bearing-stablecoin frame with [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao), and the on-chain-lending frame with [Aave](/wiki/daos/lending/aave-dao) and [Morpho](/wiki/daos/lending/morpho) – but differs from all of them in how explicitly it has converted governance from a discretionary body into a rules-writing one. For the [lending directory](/wiki/daos/lending), it is the reference point for “institutional credit, run as a DAO.”

## How Caper approaches this

Maple’s progression is really about one thing: shrinking the distance between a policy the token approves and the action that carries it out. [Caper](/wiki/foundations/what-is-a-caper) takes the execution side of that same problem directly on-chain. A passed Caper proposal is not a signal that a multisig then honours by hand – its action is executed by an on-chain function (a treasury [payout or investment execution](/wiki/governance/execution) triggered from the [proposal](/wiki/governance/proposals) itself), so “the vote passed” and “the thing happened” are the same event rather than two. And where Maple routes revenue to a strategic fund, a Caper’s value flows to its own on-chain treasury; a member’s exit claim on that treasury is their canonical vote weight, so influence and payout are computed from one figure, not negotiated after the fact. Different domain, same instinct Maple is chasing: leave as little as possible to discretion between decision and execution.

## References

- [Maple Finance](https://maple.finance) – protocol site; [About](https://maple.finance/about) (“onchain asset management since 2019”).
- [Maple documentation](https://docs.maple.finance/) – product and token-holder docs; [MPL→SYRUP migration](https://docs.maple.finance/maple-for-token-holders/mpl-token/mpl-token-migration).
- [Maple Governance Forum](https://community.maple.finance) – all MIP proposals and votes ([MIP-019](https://community.maple.finance/t/mip-019-activate-the-ssf-and-sunset-staking/1042), [MIP-021](https://community.maple.finance/t/mip-021-a-rules-based-buyback-that-scales-with-revenue/1153), [MIP-023](https://community.maple.finance/t/mip023-proposal-hyper-programmatic-revenue-model-and-governance-parity/1152)).
- [SYRUP token](https://maple.finance/syrup) – governance-and-yield token overview.
- [DeFiLlama – Maple](https://defillama.com/protocol/maple) and [Messari – Syrup](https://messari.io/project/syrup) – live TVL/AUM and token data.

## Morpho

URL: https://caper.network/wiki/daos/lending/morpho
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Name** | Morpho |
| **Type** | DeFi lending protocol & DAO |
| **Founded** | August 2021 ([Morpho Labs](https://en.wikipedia.org/wiki/Morpho_(DeFi_lending_protocol)), France) — Paul Frambot, Merlin Égalité, Julien Thomas, Mathis Gontier Delanuey |
| **Governance token** | [MORPHO](https://docs.morpho.org/learn/governance/morpho-token/) — wrapped MORPHO transferable since 21 Nov 2024 |
| **Chains** | Ethereum, Base, OP Mainnet (multi-chain) |
| **Scale** | ≈ $7.5B TVL (Apr 2026), second-largest lending protocol |
| **Governance** | [Snapshot (morpho.eth)](https://snapshot.org/#/morpho.eth) + 5/9 execution multisig; [Morpho Association](https://docs.morpho.org/learn/governance/organization/) (French nonprofit) |
| **Status** | 🟢 Active |
| **Website** | [morpho.org](https://morpho.org) |

**Morpho** is a decentralized lending network and one of the largest protocols in DeFi, with roughly [$7.5 billion in total value locked](https://morpho.org/blog/the-morpho-effect-2025/) by early 2026 — the second-largest lender after Aave. Its distinguishing choice is architectural: rather than a single governed money market, Morpho splits into an **immutable, permissionless lending primitive** and a **governed periphery** of a token, a fee switch, and independent risk curators. The Morpho DAO governs the periphery; it cannot alter a deployed market. That line — between what is immutable and what is voted on — is what makes Morpho a useful case study alongside minimal-governance stablecoin peers like [Liquity](/wiki/daos/stablecoins/liquity) and [Reflexer / RAI](/wiki/daos/stablecoins/reflexer-rai), and a contrast to the fully-governed markets of [Aave](/wiki/daos/lending/aave-dao) and [Compound](/wiki/daos/lending/compound-dao).

## From optimizer to primitive

Morpho began in June 2022 as the **Morpho Optimizer** (V0) — a peer-to-peer matching layer sitting _on top of_ [Aave](/wiki/daos/lending/aave-dao) and [Compound](/wiki/daos/lending/compound-dao) that paired lenders and borrowers directly to tighten the spread between supply and borrow rates, falling back to the underlying pool when no match existed. It improved rates but inherited every risk parameter of the market it was built on.

In January 2024 Morpho shipped [V1](https://en.wikipedia.org/wiki/Morpho_(DeFi_lending_protocol)) — its own base layer, **Morpho Blue** (Morpho Markets) plus **Morpho Vaults** — described by the project as an immutable protocol. This was the pivot from being a wrapper around other lenders to being a primitive other applications build on. By 2025, [Coinbase's crypto-backed loans](https://morpho.org/coinbase-loans/) were running on Morpho Blue, bringing retail borrowers on-chain against BTC and ETH collateral without those users ever touching a DeFi interface.

## Morpho Blue: minimal, immutable, permissionless

The core of Morpho is deliberately small. A Morpho [Blue market](https://docs.morpho.org/) is defined by five immutable parameters set at creation: one collateral asset, one loan asset, a liquidation loan-to-value (**LLTV**), an interest-rate model (**IRM**), and an oracle. Markets are **isolated** — a bad debt event in one market cannot spill into another — and anyone can permissionlessly deploy a new market from the whitelisted LLTV and IRM options.

Once deployed, a market is fixed. As Morpho's own documentation puts it, governance _does not_ control deployed Blue markets — "the core smart contract code is immutable." There is no admin key that can raise a market's LLTV, swap its oracle, or pause it after the fact. This is the opposite of the monolithic-lender model, where a single governance body tunes every collateral factor and interest curve for a shared risk pool.

## Vaults and curators

Isolated primitives are safe but hard to use directly — a passive lender does not want to pick individual markets. **Morpho Vaults** (originally MetaMorpho) close that gap: a depositor puts a single asset into a vault, and a **curator** allocates that liquidity across many underlying Blue markets under a published risk mandate (supply caps, allowed markets, timelocked changes). The curator earns a fee and bears reputational risk; the depositor gets a one-click yield product built on immutable markets.

Curation is a permissionless _role_, not a governance seat. Professional risk firms run competing vaults, and the DAO does not pick winners — depositors do, by where they place capital. It is the same active-management function that [karpatkey](/wiki/dao-governance/tooling/treasury/karpatkey) performs for whole treasuries, pushed down to the level of a single lending vault. [Euler v2](/wiki/daos/lending/euler) reaches the same permissionless-primitive-plus-curated-vault split by a different route — the Euler Vault Kit and the Ethereum Vault Connector — with governed vaults playing the curator role.

## What the DAO governs — and what it cannot

The [Morpho DAO](https://docs.morpho.org/learn/governance/organization/) is intentionally scoped. MORPHO holders vote through the [morpho.eth Snapshot space](https://snapshot.org/#/morpho.eth); anyone holding or delegated at least 500,000 MORPHO can submit a proposal, and a passing vote binds all holders. Approved decisions are executed by a **5-of-9 multisig**, with separate multisigs handling reward distribution on Ethereum and Base. Legal and operational support comes from the **Morpho Association**, a French nonprofit that maintains the front end, documentation, and GPL-licensed code.

Governance powers, per the docs, are limited to: managing the MORPHO tokens in the treasury; owning the upgradeable MORPHO token contract; activating and adjusting the protocol **fee switch** (capped at 25%); **whitelisting new LLTVs and IRMs** for use across the protocol; and granting licenses to the Morpho codebase. It does _not_ reach into any live market. Governance chooses the menu of building blocks; it does not manage the buildings.

The MORPHO token itself carries the same minimalism. The original token was deployed as an immutable contract with no on-chain vote accounting; governance later ratified [MIP-75](https://forum.morpho.org/t/vote-to-enable-transferability-of-the-morpho-token/983) to wrap it 1:1 into a transferable, vote-trackable **wrapped MORPHO**, and voted to [enable transferability on 21 November 2024](https://morpho.org/blog/the-morpho-dao-to-enable-transferability-for-morpho/).

## V2 and institutional scale

In June 2025 Morpho announced [V2](https://morpho.org/blog/morpho-v2-liberating-the-potential-of-onchain-loans/), an **intent-based** design that adds fixed-rate, fixed-term loans on top of the variable-rate V1 markets. Instead of only depositing into isolated pools, a borrower expresses an intent — amount, term, rate — and is matched against a global book of curator-created offers, a model [CoinDesk framed](https://www.coindesk.com/business/2025/06/12/crypto-lending-platform-morpho-v2-brings-defi-closer-to-traditional-finance) as pulling DeFi lending closer to how traditional fixed-income desks work.

The combination — an immutable base, curated vaults, and institutional fixed-term loans — is what pushed Morpho to roughly $7.5B TVL by April 2026 and made it the settlement layer behind consumer products like Coinbase Loans, which by then routed [over $1.6B of collateral](https://morpho.org/coinbase-loans/) through Morpho Blue.

## How Caper approaches this

Morpho's core insight — keep the part that holds value immutable, and let governance touch only a narrow periphery — is one [Caper](/wiki/foundations/what-is-a-caper) reaches from the other direction. Where Morpho separates an immutable market contract from a governed token, a caper puts both inside one contract but draws an equally hard line. The [bonding-curve collateral](/wiki/markets/bonding-curve) that backs every token's sell-back price is moved only by buys and sells; no proposal can reach it. Governance acts on a _separate_ treasury through three typed proposal kinds — PAYOUT, INVEST, and VOTE — and nothing else. So, as with a deployed Blue market, the price a holder can always redeem at is immune to any vote.

The two also differ on what makes a vote heavy. In Morpho, governance weight is bought MORPHO; in a caper it is a product of token holdings and an earned, non-transferable factor. Per `contracts/logic/src/lib.rs`, `compute_vote_weight` returns `(t · v) / (V · T)`, where `v` is the voter's balance of a **soulbound proof-of-vote token** — divisibility-none, mintable one-per-ballot, and non-transferable (its depositor role is pinned to the component). `exit()` settles a member's treasury share with the _same_ weight and then burns those vote tokens. A large bag alone (a big `t`) cannot capture control, because the decisive multiplier has to be earned by participating and cannot be bought. This is a real trade-off, not a free lunch: Morpho's curator layer delivers actively-managed, institution-grade lending markets that a caper deliberately forgoes — the comparison is about where each protocol fixes the boundary between immutable and governed, not feature parity.

## References

- [Morpho Docs — Governance organization](https://docs.morpho.org/learn/governance/organization/)
- [Morpho Docs — The MORPHO token](https://docs.morpho.org/learn/governance/morpho-token/)
- [Morpho — The Morpho DAO to Enable Transferability for MORPHO (Nov 2024)](https://morpho.org/blog/the-morpho-dao-to-enable-transferability-for-morpho/)
- [Morpho — Morpho V2 (June 2025)](https://morpho.org/blog/morpho-v2-liberating-the-potential-of-onchain-loans/)
- [Morpho — The Morpho Effect: 2025](https://morpho.org/blog/the-morpho-effect-2025/)
- [CoinDesk — Morpho V2 brings DeFi closer to TradFi (12 Jun 2025)](https://www.coindesk.com/business/2025/06/12/crypto-lending-platform-morpho-v2-brings-defi-closer-to-traditional-finance)
- [Wikipedia — Morpho (DeFi lending protocol)](https://en.wikipedia.org/wiki/Morpho_(DeFi_lending_protocol))

## Ondo Finance (ONDO)

URL: https://caper.network/wiki/daos/lending/ondo-finance
Updated: 2026-07-26

|  |  |
| --- | --- |
| **Name** | Ondo Finance (Ondo DAO) |
| **Type** | Real-world-asset (RWA) platform – tokenized US Treasuries & yield; DAO governs the [Compound](/wiki/daos/lending/compound-dao)-fork lending protocol Flux Finance |
| **Governance token** | ONDO (10,000,000,000 fixed supply, no planned inflation) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) on-chain voting – a fork of Compound’s Governor Bravo, tallied via [Tally](https://www.tally.xyz/) |
| **Key parameters** | Propose ≥ 100,000,000 ONDO · 1,000,000-vote quorum · 3-day vote · 1-day timelock |
| **Products** | OUSG (tokenized Treasuries), USDY (yield-bearing dollar), Ondo Global Markets (tokenized stocks/ETFs) |
| **Founded** | 2021, by Nathan Allman (d. May 2026); Ian De Bode, CEO from 2026 |
| **Reference** | [ondo.finance](https://ondo.finance) · [Ondo Foundation docs](https://docs.ondo.foundation/ondo-token) |

## Overview

**Ondo Finance** is one of the largest [real-world-asset](/wiki/dao-governance/concepts/treasury/dao-treasury-management) (RWA) platforms in crypto: it wraps short-term US Treasuries and other regulated instruments into freely-composable on-chain tokens. It is the RWA sibling to the on-chain money markets in this section: where [Aave](/wiki/daos/lending/aave-dao) lends crypto collateral, Ondo brings the collateral itself – tokenized government debt – on-chain. By 2026 it held on the order of **$3.5–3.8 billion** in tokenized assets across more than a dozen chains – track the live figure on [DeFiLlama](https://defillama.com/protocol/ondo-finance) rather than trusting a fixed number, since it moves with subscriptions and yield. Ondo was founded in 2021 by [Nathan Allman](https://www.coindesk.com/markets/2026/05/26/ondo-finance-founder-nathan-allman-passes-away), a former member of Goldman Sachs’ digital-assets desk; after Allman’s death in May 2026 at 32, longtime president Ian De Bode took over as CEO.

Ondo matters to the DAO industry because it is the clearest live example of a structural split that RWA protocols cannot escape: **the token is on-chain, but the asset is not.** The ONDO governance token and the Flux Finance lending market run as smart contracts a DAO can vote on; the Treasuries backing OUSG and USDY sit in bankruptcy-remote legal wrappers with off-chain custodians and administrators, gated behind KYC. Reading Ondo honestly means keeping those two layers apart – which is exactly what makes it a useful case study alongside fully on-chain protocols like [Aave](/wiki/daos/lending/aave-dao) and [Compound](/wiki/daos/lending/compound-dao).

## The RWA product suite

Ondo’s products are issued and operated by Ondo entities under off-chain legal structure – they are _not_ governed by ONDO holders. What the token buys is exposure and composability, not a vote over the reserves.

- **OUSG** – a token representing [tokenized short-term US Treasuries](https://ondo.finance/ousg), with near-instant mint and redemption for qualified purchasers. It is _permissioned_: holders pass KYC/AML and eligibility checks, so OUSG is a regulated-investor instrument, not a permissionless one.
- **USDY** – a [yield-bearing dollar token](https://ondo.finance/usdy) backed by short-term Treasuries and bank deposits, transferable by non-US persons after an initial lock. It is closer to a yield-bearing [stablecoin](/wiki/daos/stablecoins/sky-dao) than to a fund share.
- **Ondo Global Markets** – launched September 2025, it [extends tokenization to US stocks and ETFs](https://www.prnewswire.com/news-releases/ondo-brings-over-100-tokenized-us-stocks-and-etfs-onchain-starting-on-ethereum-302545276.html) for non-US investors. In November 2025 Liechtenstein’s Financial Market Authority granted Ondo [MiCA approval](https://www.theblock.co/post/379007/ondo-finance-mica-approval) to offer tokenized equities across the European Economic Area.
- **Institutional rails** – in December 2025 Ondo, [State Street and Galaxy announced SWEEP](https://investors.statestreet.com/investor-news-events/press-releases/news-details/2025/State-Street-Investment-Management-and-Galaxy-Digital-Partner-to-Tokenize-Private-Liquidity-Fund-With-Planned-Seed-Investment-from-Ondo/default.aspx), a tokenized private-liquidity fund on Solana seeded with roughly $200 million of OUSG – a signal of how far the “RWA on-chain” thesis has moved into regulated finance.

## Ondo DAO and Flux Finance – what the token actually governs

The on-chain governance surface is narrower than Ondo’s balance sheet suggests. ONDO is the [governance token for the Ondo DAO and Flux Finance](https://docs.ondo.foundation/ondo-token), and the DAO’s concrete authority centers on **[Flux Finance](https://docs.fluxfinance.com/governance)** – a lending protocol forked from [Compound](/wiki/daos/lending/compound-dao) that lets tokenized assets like OUSG serve as collateral. Flux inherits Compound’s governance machinery directly:

- A fork of **Governor Bravo** plus a Timelock, with votes tallied on [Tally](https://www.tally.xyz/).
- Submitting a proposal requires **100,000,000 ONDO** of voting power (held or delegated); proposals need a **1,000,000-vote quorum**, run a **3-day** vote, and pass through a **1-day timelock** before execution.
- Through those proposals, “[stakeholders in the DAO exercise control over the protocol, including economic parameters and smart contract upgrades](https://docs.fluxfinance.com/governance).” Locked ONDO can still vote, so distribution decisions stay inside the DAO.

The 100-million-ONDO proposal threshold is worth dwelling on: against a 10-billion fixed supply it is a fraction of a percent, but in absolute terms it is a very large, concentrated stake – a reminder that a low _percentage_ threshold can still be a high _practical_ bar to who can steer the protocol. Compare Compound’s own [25,000-COMP](/wiki/daos/lending/compound-dao) threshold on a 10-million supply.

## The RWA governance tension

Ondo is the archetype for a problem every tokenized-asset DAO runs into: **on-chain governance cannot reach the off-chain asset.** ONDO holders can vote to change Flux’s interest-rate parameters or upgrade its contracts, but they cannot vote to break the custody of the Treasuries behind OUSG, override a redemption freeze, or force a distribution – those live in legal agreements, regulated administrators, and KYC gates that a smart-contract vote has no power over. The token votes on the wrapper; a court and a custodian govern the collateral.

That is not a flaw unique to Ondo – it is the honest cost of putting a real-world bond on a public chain, and it is the same seam that shows up whenever a DAO holds assets it does not natively control. It sits in useful contrast to protocols whose entire object of governance _is_ on-chain and therefore fully reachable by a vote, and to the recurring failure mode where token-holders _believe_ they govern something the legal structure has quietly placed out of reach – a pattern the wiki catalogues in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) and in the [Aragon DAO](/wiki/daos/infrastructure/aragon-dao) episode, where holders discovered the treasury they thought they controlled was not theirs to direct. The same seam runs through [Maple Finance](/wiki/daos/lending/maple-finance), a peer institutional-credit DAO whose token can rewrite the protocol’s revenue and buyback policy on-chain but cannot itself underwrite the off-chain loans that generate that revenue.

## How Caper approaches this

Caper is a [DAO protocol](/wiki/foundations/what-is-a-caper), not an RWA issuer – it does not tokenize Treasuries or custody off-chain assets. Where it speaks to Ondo’s tension is the opposite design choice: Caper is built so that **what a member governs and what a member can redeem are the same on-chain object**, with no off-chain layer that a vote cannot reach.

Every vote in a caper mints a [soulbound proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens) – non-divisible and non-transferable in the contract (`DIVISIBILITY_NONE`, with deposits gated to the component’s own calls, so it cannot be sent peer-to-peer). A member’s earned voting record folds directly into both their voting weight and their _exit share_ of the treasury, computed by the same on-chain function: `(held · votes) / (supply · circulation)`. The right to leave and pull your share is not a promise held in a legal wrapper; it is the [same contract call](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) that reads your on-chain vote token and burns it as it redeems. Influence is un-buyable by design – though not bag-less, since holdings still multiply weight. (Verified against `contracts/logic/src/lib.rs` and `contracts/core/src/caper_dao.rs`.)

## References

- [Ondo Finance](https://ondo.finance) – product site (OUSG, USDY, Global Markets).
- [Ondo Foundation – The ONDO Token](https://docs.ondo.foundation/ondo-token) – supply, governance scope.
- [Flux Finance Docs – Governance](https://docs.fluxfinance.com/governance) – Governor Bravo parameters.
- [DeFiLlama – Ondo Finance](https://defillama.com/protocol/ondo-finance) – live TVL across chains.
- [CoinDesk](https://www.coindesk.com/markets/2026/05/26/ondo-finance-founder-nathan-allman-passes-away) – founder Nathan Allman’s death and CEO transition (May 2026).
- [CoinDesk](https://investors.statestreet.com/investor-news-events/press-releases/news-details/2025/State-Street-Investment-Management-and-Galaxy-Digital-Partner-to-Tokenize-Private-Liquidity-Fund-With-Planned-Seed-Investment-from-Ondo/default.aspx) – Ondo / State Street / Galaxy SWEEP fund (Dec 2025).

## Pendle Finance

URL: https://caper.network/wiki/daos/lending/pendle-finance
Updated: 2026-08-03

| Project | Pendle Finance |
| --- | --- |
| Category | Yield-tokenization protocol · vote-escrow → liquid-staking governance |
| Chains | Ethereum, Arbitrum, BNB Chain, and other EVM networks ([multichain](https://docs.pendle.finance/)) |
| Went live | Ethereum mainnet, [2021](https://www.pendle.finance/) |
| Governance token | PENDLE → [vePENDLE](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/sPENDLE) (legacy) → [sPENDLE](https://medium.com/pendle/introducing-spendle-8479744dfdf8) (Jan 2026) |
| Emissions | Inflationary; ~1.1%/week decay to a [2%/yr terminal tail from April 2026](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/Tokenomics) |
| TVL at sPENDLE launch | [over $3B](https://www.coindesk.com/markets/2026/01/20/pendle-introduces-spendle-removing-the-need-for-long-lockups) (Jan 2026) |
| Related | [Curve](/wiki/daos/dexs/curve-dao) · [Balancer](/wiki/daos/dexs/balancer-dao) · [Convex](/wiki/daos/lending/convex-finance) |

**Pendle Finance** is a decentralized protocol that [tokenizes future yield](https://docs.pendle.finance/): it wraps a yield-bearing asset and splits it into a **Principal Token (PT)**, redeemable 1:1 at maturity, and a **Yield Token (YT)**, which captures the variable yield until then. Traded against each other on a purpose-built AMM, PT and YT let users lock in a fixed yield, speculate on a floating one, or hedge — the on-chain analogue of an interest-rate market. What makes Pendle a governance case study rather than just a DeFi venue is **how it steered its own token incentives**: for four years it ran one of the most-copied [vote-escrow gauge systems](/wiki/daos/dexs/curve-dao) in DeFi, and in January 2026 it [tore that system out](https://www.coindesk.com/markets/2026/01/20/pendle-introduces-spendle-removing-the-need-for-long-lockups) — making it a live data point in the broader retreat from the ve-lock model.

## vePENDLE: gauge voting, the Curve way

From 2022, Pendle governance ran on **vePENDLE** — vote-escrowed PENDLE, the same [veCRV pattern](/wiki/daos/dexs/curve-dao) Curve pioneered. Holders [locked PENDLE for up to two years](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/sPENDLE); voting weight scaled with both the amount locked and the time remaining, decaying as the lock ran down. That weight did one central job: **direct emissions**. Every epoch — snapshotted [each Thursday at 00:00 UTC](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/sPENDLE) — vePENDLE holders voted to channel PENDLE incentives toward specific pools, and in return earned [80% of the swap fees](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/sPENDLE) from the pools they backed. An [incentive cap](https://docs.pendle.finance/pendle-v2/ProtocolMechanics/Mechanisms/sPENDLE) tied each pool's maximum incentive to its actual swap-fee performance, so votes could not endlessly farm emissions into a pool nobody traded.

This is the exact [token-weighted, lock-to-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) design that produced the "[Curve wars](/wiki/daos/dexs/curve-dao)" and the [Convex](/wiki/daos/lending/convex-finance) liquid-locker layer built to game it. Pendle inherited both its power and its problem.

## January 2026: retiring the lock (vePENDLE → sPENDLE)

On [20 January 2026](https://www.coindesk.com/markets/2026/01/20/pendle-introduces-spendle-removing-the-need-for-long-lockups) Pendle announced **sPENDLE**, a liquid staking token that replaces vePENDLE as the protocol's primary governance and reward token. The team's stated reason is a governance-participation failure: only [about 20% of PENDLE supply](https://www.coindesk.com/markets/2026/01/20/pendle-introduces-spendle-removing-the-need-for-long-lockups) was ever actively engaged under vePENDLE, because the multi-year lock was too complex and too illiquid for most holders. sPENDLE keeps skin in the game without the trap — a [14-day withdrawal period](https://medium.com/pendle/introducing-spendle-8479744dfdf8) (or instant redemption for a 5% fee) instead of a two-year lock, and rewards funded by [up to 80% of protocol revenue used for PENDLE buybacks](https://medium.com/pendle/introducing-spendle-8479744dfdf8). Existing lockers were not stranded: they received [boosted sPENDLE up to 4×](https://medium.com/pendle/introducing-spendle-8479744dfdf8) based on remaining lock duration, decaying linearly to 1× over the life of the old lock. sPENDLE staking [went live 20 January; new vePENDLE locks were paused 29 January](https://medium.com/pendle/introducing-spendle-8479744dfdf8).

The deeper change is under the hood. Manual gauge voting — the heart of the ve-model — was replaced with an [algorithmic emissions model](https://www.coindesk.com/markets/2026/01/20/pendle-introduces-spendle-removing-the-need-for-long-lockups) that routes incentives by data-driven demand signals rather than by weekly vote, cutting overall emissions by roughly 30%. Governance shifts from _humans bribing votes to steer rewards_ toward _a formula allocating rewards, with tokenholders governing the formula_.

## Where it sits: the post-ve turn

Pendle's move is not isolated. Within months of each other, the two other most prominent ve-forks in this directory made the same call: [Balancer](/wiki/daos/dexs/balancer-dao) voted (BIP-919/920/921) to deprecate **veBAL** for raw one-token-one-vote, and Pendle retired **vePENDLE** for a liquid staking token plus algorithmic emissions. The vote-escrow model that dominated 2022–2024 DeFi governance — [Curve](/wiki/daos/dexs/curve-dao), Balancer, Pendle, [Convex](/wiki/daos/lending/convex-finance), and the bribe markets on top — is being unwound by the very protocols that popularized it, on the recurring finding that lock-to-vote concentrates power in a rentable few while leaving the median holder [disengaged](/wiki/dao-governance/concepts/voting/token-weighted-voting). Pendle's own number — 80% of supply sitting out — is a clean statement of the problem. The open question these redesigns raise is whether making governance _more liquid_ improves participation or simply makes vote weight [easier to rent by the epoch](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance). Not every ve-fork is unwinding, though: on Base, [Aerodrome](/wiki/daos/dexs/aerodrome-finance) kept the ve(3,3) model, became the chain's dominant DEX, and in 2026 is consolidating Velodrome under it rather than retiring the lock.

## How Caper approaches this

Pendle spent four years engineering elaborate _escrow_ to make governance weight expensive to acquire, then concluded the escrow itself was the problem and swapped it for a liquid, tradeable stake. [Caper](/wiki/foundations/what-is-a-caper) starts from the other side: it never issues a lockable or tradeable governance token at all. In a caper a member's [vote weight](/wiki/governance/voting) is `(held × votes) / (vote_supply × circulation)` — the amount of the caper's token held, multiplied by a **soulbound, non-transferable** vote record that is minted one-per-vote and can never be sent, sold, or locked to another wallet (verified in `contracts/core/src/caper_dao.rs`: the vote token is `DIVISIBILITY_NONE` and minted straight into the voter's account, and `compute_vote_weight` is that product). Because the record is earned by participating rather than bought or escrowed, there is no lock to optimize, no bribe market to build on top, and no liquid governance token to rent — the failure modes Pendle, Curve, and Convex spent years fighting simply have no surface to attach to.

The same weight also settles the exit: a member's pro-rata share of the [treasury on exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) uses the identical `(held × votes) / (vote_supply × circulation)` helper, so the number that governs and the number that cashes out are the same — governance and skin-in-the-game are one quantity, not two tokens to reconcile. (This is a design contrast, not a claim that Caper does yield tokenization.)

## Spark (SPK)

URL: https://caper.network/wiki/daos/lending/spark
Updated: 2026-07-25

| Type | On-chain stablecoin allocator & lending protocol; Sky "Star" sub-DAO (DeFi) |
| --- | --- |
| Token | SPK (governance & staking) |
| Governance | SPK-holder voting scoped to the [Spark Agent artifact inside the Sky Atlas](https://docs.spark.fi/governance); signalling via [Snapshot](https://snapshot.box/#/s:sparkfi.eth) |
| Parent | [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao) — Spark is Sky's first live Star |
| Launched | SparkLend May 2023; SPK token & airdrop 2025 ([claim concluded 17 Dec 2025](https://docs.spark.fi/governance/spk-token)) |
| Chains | Ethereum plus Base, Arbitrum, Optimism & Unichain via the Spark Liquidity Layer |
| Scale | [~$3.55B SparkLend TVL, ~$2.36B Savings, ~$1.15B deployed by the Liquidity Layer](https://spark.fi/) (live figures) |
| Website | [spark.fi](https://spark.fi/) |

## Overview

[Spark](https://spark.fi/) is an on-chain allocator of stablecoin liquidity and a lending protocol governed by its own **SPK** token — and, distinctively, it is a **sub-DAO** that operates inside a larger DAO. Spark is the first live "Star" in the Endgame architecture of [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao), so its scope, budgets, and risk parameters are defined by a governance artifact that lives within Sky's constitution rather than standing fully independent. That structure makes Spark the wiki's clearest worked example of the [sub-DAO pattern](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups): a semi-sovereign unit with its own token and voters, nested under a parent that retains ultimate control.

Functionally, Spark does three things — it lends (SparkLend), it pays a savings rate on stablecoins and ETH (Spark Savings), and it routes idle Sky-backed liquidity into external venues to earn yield (the Spark Liquidity Layer). Where standalone money markets such as [Aave](/wiki/daos/lending/aave-dao), [Compound](/wiki/daos/lending/compound-dao), [Morpho](/wiki/daos/lending/morpho) and [Euler](/wiki/daos/lending/euler) answer to no one but their own token, Spark's mandate is set — and can be revised or revoked — by its parent DAO.

## From a MakerDAO front-end to a Sky "Star"

Spark began in May 2023 as **Spark Protocol / SparkLend**, a lending market forked from [Aave v3](/wiki/daos/lending/aave-dao) and stood up by MakerDAO to lend out its own [DAI](/wiki/daos/stablecoins/sky-dao) at a rate the Maker governance voted directly — a native front-end for Maker's stablecoin rather than a third-party venue. It was, from day one, an arm of a DAO rather than a rival to one.

When MakerDAO rebranded to Sky and launched its [Endgame](https://docs.spark.fi/user-guides/getting-started) plan, the design called for semi-independent "Stars" — sub-DAOs with their own tokens and governance that build on Sky's liquidity while remaining bound to the Sky Atlas. Spark became the **first Star to go live**, graduating from an internal product into a token-governed protocol in its own right while staying inside the parent's orbit. Its SPK token, launched in 2025, formalised that half-step: real governance for Spark, still framed by Sky.

## What Spark builds

**SparkLend** is the lending core: users borrow USDC and USDS against ETH, staked-ETH (wstETH, rETH, weETH) and BTC collateral, at rates set through governance rather than a pure utilization curve. **Spark Savings** issues yield-bearing vault tokens (sUSDS, sUSDC) that pay a rate sourced from Spark's allocations, withdrawable back into USDC, USDT, PYUSD, USDS or ETH.

The **[Spark Liquidity Layer (SLL)](https://docs.spark.fi/user-guides/spark-liquidity-layer)** is the piece that makes Spark an "allocator" and not just a money market: it deploys Sky-backed stablecoin reserves directly into external venues — [Aave](/wiki/daos/lending/aave-dao), [Morpho](/wiki/daos/lending/morpho), [Ethena](/wiki/daos/stablecoins/ethena) and tokenized real-world assets — across Ethereum, Base, Arbitrum, Optimism and Unichain. Because it can bootstrap products with its own reserves, Spark does not depend on mercenary third-party capital to seed a new market. Its 2025 [$1B tokenized-treasuries "Grand Prix"](https://www.coindesk.com/business/2025/03/18/blackrock-s-buidl-superstate-and-centrifuge-win-spark-s-usd1b-tokenized-asset-windfall-report) — won by BlackRock's BUIDL, Superstate and Centrifuge — routed a large slice of that liquidity into RWAs.

## The SPK token

SPK is Spark's governance and staking token, native to Ethereum. Its supply is fixed at genesis but its distribution is controlled by the parent: [10 billion SPK were minted](https://docs.spark.fi/governance/spk-token), split **65% to a ten-year "Sky Farming" campaign** (6.5B SPK, released to users through a Sky-controlled Pause Proxy), **23% to the Spark ecosystem & treasury** (2.3B, including the concluded airdrop), and **12% to the team** (1.2B, a 12-month cliff then three-year vest). Users still earn SPK today by depositing USDS into the SPK Farm.

SPK can be staked to earn Spark Points (and, via [Symbiotic](https://docs.spark.fi/governance/spk-token), external restaking points), with staked SPK earmarked to help secure future Spark products. One clause underlines the sub-DAO relationship: **Sky retains the ability to mint additional SPK under extreme circumstances**, governed by the Sky Atlas — the parent keeps a lever over its Star's own money.

## Governance: a sub-DAO of a DAO

Spark's governance does not edit Spark's contracts directly. Instead it revises the **[Spark Agent artifact](https://docs.spark.fi/governance)** — a scoped document inside the **Sky Atlas**, Sky's machine-readable constitution — which defines Spark's budgets, risk settings, asset onboarding, Liquidity-Layer integrations and new-chain deployments. Changes take the form of _Atlas Root Edit Proposals_, so every Spark decision is expressed as an amendment to a sub-section of the parent's rulebook and must stay aligned with it.

SPK holders vote on and delegate over these proposals, with a whitelisted delegate set and an Operational Facilitator plus a risk-review mandate that can stop a malicious or high-risk proposal before it reaches a vote. The result is **scoped sovereignty**: Spark's community steers Spark, but only within a perimeter its parent drew and can redraw. This is the pattern the wiki covers in the abstract under [sub-DAOs and working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups) — Spark is what it looks like at a multi-billion-dollar scale.

## Why the sub-DAO model matters

The sub-DAO answers a real governance problem: a large treasury-rich DAO wants to move fast in a new product area without either (a) subjecting every operational decision to a slow full-DAO vote, or (b) spinning out a fully independent protocol it can no longer align. A Star like Spark splits the difference — a dedicated token and voter base for speed and accountability, a constitutional tether for alignment and safety. It also lets the parent concentrate liquidity behind a focused team while keeping the option to wind the unit down.

The cost is the same tether: SPK governance is real but bounded, and the parent's residual powers — controlling the farming schedule, holding a mint switch, owning the Atlas the Agent lives in — mean Spark's holders never have the last word the way an [Aave](/wiki/daos/lending/aave-dao) or [Euler](/wiki/daos/lending/euler) holder does over their own protocol. Whether that trade is worth it is the open question every DAO weighing a sub-DAO has to answer.

## How Caper approaches this

Spark shows a parent DAO delegating scoped authority to a sub-unit and keeping residual control through tokens, budgets and a constitution its Star cannot rewrite. A [caper](/wiki/foundations/what-is-a-caper) works on a different unit of trust: rather than nesting governance inside a parent's discretion, it fixes each member's influence with a canonical vote weight `w = (t · v) / (V · T)` that folds together how much of the token they hold (`t`) and a _soulbound, non-transferable_ proof-of-vote balance (`v`) earned by actually voting. The `v` factor cannot be bought, minted for insiders, or moved between wallets — so influence tracks participation, not a distribution schedule a parent controls.

The same weight drives the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): a member redeems a share of the treasury proportional to that weight and burns their vote balance on the way out. A large bag still matters — `t` is a multiplier, so holdings are not irrelevant — but a bag alone cannot capture control, and the treasury claim is a first-class protocol primitive rather than a budget a parent grants and can revoke. Where a sub-DAO borrows legitimacy from the DAO above it, a caper builds the accountability into the weight itself.

## Yearn Finance

URL: https://caper.network/wiki/daos/lending/yearn-finance
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Yearn Finance (Yearn DAO) |
| **Type** | Protocol DAO — DeFi yield aggregator (automated vault strategies) |
| **Founded** | 2020 (Andre Cronje, as _iearn_ → yearn.finance); YFI token fair-launched 17 July 2020 |
| **Governance token** | YFI — [fair-launched with no premine](https://docs.yearn.fi/contributing/governance/yfi), no team/investor allocation; original supply 30,000, expanded to 36,666 by [YIP-57](https://github.com/yearn/YIPS/blob/master/YIPS/yip-57.md) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) yGov via YIPs ([Snapshot](https://snapshot.org/#/veyfi.eth) + multisig execution); [veYFI](https://docs.yearn.fi/contributing/governance/veyfi) vote-escrow layer since 2022 |
| **Products** | yVaults — automated, auto-compounding yield strategies; the original DeFi yield aggregator |
| **Notable for** | The canonical DeFi **fair launch**; a DAO that voted to mint its own supply and later adopted Curve-style vote-escrow |
| **Primary sources** | [yearn.fi](https://yearn.fi/), [docs.yearn.fi](https://docs.yearn.fi/), [gov.yearn.fi](https://gov.yearn.fi/), [yearn/YIPS](https://github.com/yearn/YIPS) |
| **Related** | [Curve DAO](/wiki/daos/dexs/curve-dao), [Convex](/wiki/daos/lending/convex-finance), [Frax](/wiki/daos/stablecoins/frax-finance), [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics), [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) |

**Yearn Finance** is the original DeFi **yield aggregator**: a protocol whose [vaults](https://docs.yearn.fi/getting-started/intro) take a user's deposit and route it through whatever lending and liquidity strategies are earning the most at that moment, auto-compounding the returns so an ordinary depositor gets an actively-managed yield without doing the work. It grew out of _iearn_, a set of contracts [Andre Cronje](https://www.coindesk.com/markets/2020/12/08/andre-cronje-defi-expressionist) built in 2020 to rebalance stablecoins across lending markets. Yearn matters to DAO history less for the vaults than for how its token arrived — the **YFI fair launch** became the template every "no premine, no VC allocation" project has cited since — and for what the DAO did afterward: it voted to _inflate its own supply_, then bolted a [Curve](/wiki/daos/dexs/curve-dao)-style vote-escrow lock onto governance. Yearn is a live record of a community repricing and re-architecting its own token by proposal. The contrast case is [Beefy](/wiki/daos/lending/beefy), a yield optimizer of the same vintage whose supply is fixed at 80,000 tokens with no mint function at all — which leaves it no version of that lever, and forces every cost onto the cash side of the balance sheet.

## The fair launch and yGov

On 17 July 2020 Cronje released **YFI** with what he described as "a completely valueless 0 supply token" — no allocation to himself, no team or investor slice, no premine. All **30,000** YFI were distributed to people who supplied liquidity to designated pools over roughly a week; the only way to get any was to use the protocol. ([Yearn docs: YFI](https://docs.yearn.fi/contributing/governance/yfi)) That distribution — later shorthanded as the DeFi **"fair launch"** — put governance entirely in the hands of users from day one, and it is the property most often held up as the antidote to the [insider-heavy token distributions](/wiki/dao-governance/concepts/treasury/dao-tokenomics) common elsewhere.

Governance runs as **yGov**: **Yearn Improvement Proposals (YIPs)** are debated on the [governance forum](https://gov.yearn.fi/), ratified by [Snapshot](https://snapshot.org/#/veyfi.eth) token vote, and executed by a multisig — an [off-chain-signalling / on-chain-execution](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) split that predated most tooling and is still common today. Contributor pay was an early problem Yearn solved in public, pioneering peer-allocated compensation through [Coordinape](/wiki/dao-governance/tooling/treasury/coordinape) (which spun out of Yearn) rather than top-down salaries.

## yVaults, the treasury, and a DAO that repriced its own token

The product is the **yVault**: deposit an asset, and Yearn's strategies farm it — supplying to lending markets, providing liquidity, harvesting and re-depositing rewards — abstracting a full yield-farming operation behind one token. Because that machinery earns real protocol revenue, Yearn's governance has repeatedly had to decide what to do with the money, and those decisions rewrote YFI's own economics twice.

First, supply. The 30,000-cap was never sacred: [YIP-57](https://github.com/yearn/YIPS/blob/master/YIPS/yip-57.md) (Feb 2021) minted **6,666 new YFI** — about **22%** of the supply — with one-third earmarked for contributor retention and two-thirds sent to the treasury under governance control, taking the total to **36,666**. A community that had prized its fixed, fairly-launched supply voted, in the open, to dilute itself to fund the protocol's future — one of the clearest examples of a DAO exercising [monetary policy over its own token](/wiki/dao-governance/concepts/treasury/dao-tokenomics) by vote. Second, the treasury flywheel: [YIP-56 ("Buyback and Build")](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929) disbanded the old YFI staking-rewards system and redirected protocol earnings into **buying YFI back** from the market for the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and contributor rewards — routing value to the DAO's balance sheet instead of paying it straight out to stakers.

## veYFI: Yearn adopts vote-escrow

In 2022 Yearn added a [vote-escrow layer](https://docs.yearn.fi/contributing/governance/veyfi) modelled on [Curve's veCRV](/wiki/daos/dexs/curve-dao). Locking YFI mints non-transferable **veYFI** for a term of **one week to four years**; a four-year lock carries **100%** weight, two years **50%**, and the weight decays as the unlock date nears and must be renewed. veYFI holders capture the bulk of gauge rewards — vaults emit **dYFI** (a token redeemable for YFI), and lockers can boost their share up to **10×** based on how much veYFI they hold relative to their vault deposits; unlocked depositors earn only the base [10%](https://docs.yearn.fi/contributing/governance/veyfi). The distinctive twist is the **early-exit penalty**: leaving before the lock ends forfeits `min(75%, time_left / 4 years)` of the position — up to three-quarters — and the forfeited YFI is **redistributed to the remaining lockers**, so patience is paid for by the impatient. ([veYFI docs](https://docs.yearn.fi/contributing/governance/veyfi))

The move placed Yearn firmly inside the [vote-escrow](/wiki/dao-governance/concepts/voting/token-weighted-voting) lineage alongside [Curve](/wiki/daos/dexs/curve-dao), [Convex](/wiki/daos/lending/convex-finance), [Balancer](/wiki/daos/dexs/balancer-dao) and [Frax](/wiki/daos/stablecoins/frax-finance) — the same bargain of trading liquidity for time-weighted say, and the same open question of whether that locked weight stays with committed holders or gets aggregated and rented a layer up.

## How Caper approaches this

Yearn's fair launch is rightly admired: no premine, no insider slice, governance in users' hands from block one. But the launch settled _who got the token_, not _how the token confers power_ — and there the story is familiar. YFI is transferable and tradable, so influence tracks holdings; the DAO minted 22% more of it by vote; and to re-couple control to commitment Yearn ultimately reached for a [Curve-style lock](/wiki/daos/dexs/curve-dao), inheriting the same ve-model tensions the rest of that [cluster](/wiki/daos/lending/convex-finance) lives with. A [caper](/wiki/foundations/what-is-a-caper) pursues the coupling Yearn's lock was reaching for without a lock to tokenise: its [voting weight](/wiki/governance/voting) combines the _stake_ a member holds with the _participation_ they have actually earned, and that participation record is **soulbound** — non-transferable by construction, so it cannot be bought, borrowed or aggregated the way locked veYFI can. Supply is not a governance lever either: a caper's tokens come from a [bonding curve](/wiki/markets/bonding-curve), not a mint proposal, so there is no equivalent of a YIP-57 dilution vote. And because that same earned weight is each member's pro-rata [exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on the treasury, say stays tied to real economic exposure. This is a design contrast, not a claim of superiority; the mechanics are on the linked pages and verified against the contract.

## References

- [Yearn documentation](https://docs.yearn.fi/) — vaults, governance and the protocol overview (primary).
- [YFI — Yearn docs](https://docs.yearn.fi/contributing/governance/yfi) — the fair launch, no-premine distribution and 30,000 supply (primary).
- [YIP-57](https://github.com/yearn/YIPS/blob/master/YIPS/yip-57.md) — the 6,666-YFI mint to 36,666 total, split contributor retention / treasury (primary).
- [YIP-56 — Buyback and Build](https://gov.yearn.fi/t/yip-56-buyback-and-build/8929) — disbanding staking rewards for a treasury buyback flywheel (primary).
- [veYFI — Yearn docs](https://docs.yearn.fi/contributing/governance/veyfi) — the vote-escrow lock, 4-year 100% weight, 10× gauge boost and early-exit penalty (primary).
- CoinDesk, [Andre Cronje: DeFi Expressionist](https://www.coindesk.com/markets/2020/12/08/andre-cronje-defi-expressionist) (2020) — background on Yearn's founder and the fair launch.

## Arbitrum DAO

URL: https://caper.network/wiki/daos/networks/arbitrum-dao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Arbitrum DAO |
| **Type** | Protocol DAO (Ethereum Layer-2 rollup) |
| **Governance token** | ARB (airdropped 23 March 2023; ~10B supply) |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting): [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) temp-check → on-chain Governors (Tally) + a 12-member Security Council |
| **Treasury** | One of the largest DAO treasuries — billions of ARB (track live on DeepDAO / Tally) |
| **Notable for** | The AIP-1 launch controversy; large-scale incentive programs (STIP, LTIPP, Gaming Catalyst) |
| **Primary sources** | [forum.arbitrum.foundation](https://forum.arbitrum.foundation/), [docs.arbitrum.foundation](https://docs.arbitrum.foundation/), [Tally governance portal](https://www.tally.xyz/gov/arbitrum) |
| **Related** | [Optimism Collective](/wiki/daos/networks/optimism-collective), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures) |

The **Arbitrum DAO** governs [Arbitrum](https://arbitrum.io/), a leading Ethereum [Layer-2](/wiki/daos/networks/optimism-collective) ecosystem built on optimistic-rollup technology. It comprises **Arbitrum One** (a full rollup), **Arbitrum Nova** (an AnyTrust chain for gaming and social apps), and the **Orbit / Arbitrum Chains** framework for launching further chains. Arbitrum One is routinely the single largest rollup by value secured, tracked live on [L2Beat](https://l2beat.com/scaling/summary). Holders of the **ARB** token, and the delegates they choose, govern the chains, the treasury, and an elected Security Council. ([Arbitrum docs: a gentle introduction](https://docs.arbitrum.io/welcome/arbitrum-gentle-introduction))

## ARB and the transition to a DAO

Arbitrum was built by **Offchain Labs**, the company founded in 2018 by Ed Felten, Steven Goldfeder, and Harry Kalodner. On **23 March 2023** the **ARB** token launched via a broad airdrop, handing governance to the newly-formed Arbitrum DAO. Of an initial supply of roughly 10 billion ARB, the largest single share — about **42.78%** — was allocated to the DAO treasury, with the remainder split across the team, investors, the user airdrop, and the Arbitrum Foundation. ([Arbitrum Foundation: airdrop distribution](https://docs.arbitrum.foundation/airdrop-eligibility-distribution))

## AIP-1 — the launch controversy

The DAO's very first proposal became one of the industry's cautionary tales. Posted on **15 March 2023**, **AIP-1** was an omnibus package that, among many other things, designated **750 million ARB (7.5% of supply, then worth roughly $1 billion)** to a Foundation-controlled "Administrative Budget Wallet." Delegates discovered that the tokens had **already been moved** — and that the Foundation had already loaned 40M ARB to a market maker and converted more to fiat — before the vote concluded, which the Foundation framed as a **"ratification"** of decisions already made rather than a request. The community **rejected AIP-1 decisively** (over three-quarters of votes against), and the Foundation split it into **AIP-1.1** (placing 700M ARB under a four-year lockup and setting a transparent operating budget) and **AIP-1.2** (which, among other changes, lowered the on-chain proposal threshold from 5,000,000 to 1,000,000 ARB and affirmed the DAO's power to replace Foundation directors). It remains a landmark case study in the gap between a DAO's launch messaging and its actual power. ([CoinDesk](https://www.coindesk.com/business/2023/04/02/contentious-arbitrum-vote-over-1b-in-tokens-ratification-not-request-says-foundation); [AIP-1.1](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360); [AIP-1.2](https://forum.arbitrum.foundation/t/proposal-aip-1-2-foundation-and-dao-governance/13362))

## Governance structure

Arbitrum governance runs under the **Constitution of the Arbitrum DAO**, which sorts proposals into two tracks: **Constitutional AIPs** (amending the Constitution, installing or modifying chain software, or exercising chain-owner powers) and **Non-Constitutional AIPs** (treasury spends, grants, and signaling). A proposal typically begins with an off-chain [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) temperature check, then moves to a binding on-chain vote through the Governor contracts — the **Core** governor for Constitutional matters (higher quorum) and the **Treasury** governor for the rest — with the interface hosted on [Tally](https://www.tally.xyz/gov/arbitrum). A **12-member Security Council**, split into two six-seat cohorts elected by the DAO every six months, can take emergency and non-emergency actions but only with a **9-of-12** supermajority; ordinary treasury and chain actions clear multi-day timelocks before they execute. ([Arbitrum Constitution](https://docs.arbitrum.foundation/dao-constitution); [Security Council](https://docs.arbitrum.foundation/concepts/security-council)) A newer take on the same "token vote plus a technical Security Council" pattern is [ZKsync's ZK Nation](/wiki/daos/networks/zksync-era), which stacks a third body — a Guardians veto — on top of the Assembly and Council.

## Treasury and incentive programs

Holding billions of ARB, the DAO runs one of the [largest treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) in the industry — its dollar value swings heavily with the ARB price, so live figures are best read from [Tally](https://www.tally.xyz/gov/arbitrum/treasury) rather than a fixed number. Much of the DAO's activity has been deploying that treasury as ecosystem incentives: the **Short-Term Incentive Program (STIP)** distributed 50M ARB to protocols in late 2023, followed by a ~21M ARB backfund; the **Long-Term Incentive Pilot Program (LTIPP)** allocated up to 45M ARB in 2024; the **Gaming Catalyst Program (GCP)** earmarked 200M ARB for game development; and the **DRIP** DeFi program and **STEP** real-world-asset allocations followed in 2025. The scale of these programs — and debates over whether spending outruns revenue — has made treasury discipline the DAO's central governance theme. ([STIP proposal](https://forum.arbitrum.foundation/t/arbitrums-short-term-incentive-program-arbitrum-improvement-proposal/16131); [DRIP](https://blog.arbitrum.io/introducing-drip-the-defi-renaissance-incentive-program-on-arbitrum/))

## Foundation and Offchain Labs

Two entities sit alongside the DAO. **Offchain Labs** is the private company that builds the Arbitrum technology; the **Arbitrum Foundation** is a Cayman Islands foundation that administers governance, handles legal and regulatory matters, and executes DAO decisions — and is itself **accountable to the DAO**, which can elect and remove its directors. The Foundation received 7.5% of ARB at genesis and contracts with Offchain Labs for core development; the closeness of these "Arbitrum-aligned entities" is a recurring subject of governance scrutiny. ([Arbitrum Foundation overview](https://docs.arbitrum.foundation/what-foundation))

## How Caper approaches this

AIP-1 is the cautionary tale a [caper](/wiki/foundations/what-is-a-caper) is built to avoid: a foundation moved and spent treasury funds before the ratifying vote had concluded. A caper has no administrative wallet that can pre-spend its treasury — funds leave only through a [PAYOUT or INVEST proposal](/wiki/governance/proposals) that passes the vote and clears an [execution delay](/wiki/governance/execution) — and any member who disagrees with where the treasury is heading can [exit](/wiki/governance/execution) for a treasury share sized by their own vote weight rather than depend on a governance fight to claw funds back. The mechanics are described neutrally on those Caper pages.

## References

- [Constitution of the Arbitrum DAO](https://docs.arbitrum.foundation/dao-constitution) — the governing ruleset.
- [Arbitrum DAO Governance Forum](https://forum.arbitrum.foundation/) — where AIPs originate.
- [Tally: Arbitrum governance](https://www.tally.xyz/gov/arbitrum) — on-chain proposals and treasury.
- [AIP-1.1](https://forum.arbitrum.foundation/t/proposal-aip-1-1-lockup-budget-transparency/13360) and [AIP-1.2](https://forum.arbitrum.foundation/t/proposal-aip-1-2-foundation-and-dao-governance/13362) — the post-controversy remedies.
- [L2Beat](https://l2beat.com/scaling/summary) — live rollup standing and value secured.

## Cosmos Hub (ATOM)

URL: https://caper.network/wiki/daos/networks/cosmos-hub
Updated: 2026-07-30

| Type | Layer-0 hub chain / sovereign-network DAO (chain `cosmoshub-4`) |
| --- | --- |
| Governance token | ATOM (staking, governance, fees) |
| Governance mechanism | Cosmos SDK `x/gov`: fully on-chain, stake-weighted, with delegator votes inherited from validators by default |
| Mainnet | Live since 2019; implementation is [gaia](https://github.com/cosmos/gaia) |
| Proposal deposit | 500 ATOM minimum, 14-day deposit window (at least 10% of it up front) |
| Voting period | 7 days (expedited: 3 days) |
| Quorum / threshold / veto | 40% / 50% / 33.4% (expedited threshold 66.7%) |
| Proposals to date | 1,050+ on-chain votes as of July 2026 |
| Website | [cosmos.network](https://cosmos.network) · [Hub docs](https://docs.cosmos.network/hub/latest) · [governance forum](https://forum.cosmos.network/) |

## What the Cosmos Hub governs

The **Cosmos Hub** is the first chain built on the Cosmos SDK and the origin of the `x/gov` module that most Cosmos app-chains still run today. Its token, **ATOM**, is bonded to validators for consensus and is the same weight that votes. Governance here is not advisory: an approved proposal changes chain parameters, spends the community pool, or swaps the node software itself. Proposal [#1049](https://www.mintscan.io/cosmos/proposals/1049), in voting as this page was written, is simply titled “Gaia v27.6.0 Upgrade”: the chain's own binary is a ballot question.

That makes the Hub one of the cleanest large-scale examples of [on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) in production, and a useful contrast to the Snapshot-plus-multisig pattern that dominates Ethereum DAOs. It is also the template two of this directory's other entries inherited: [dYdX](/wiki/daos/dexs/dydx) and [Osmosis](/wiki/daos/dexs/osmosis) both govern through the same module on their own sovereign chains.

## The pipeline: deposit, then vote

Every proposal passes through two windows, both defined by on-chain [gov parameters](https://cosmos-rest.publicnode.com/cosmos/gov/v1/params/tallying):

- **Deposit period**, up to **14 days**. A proposal only enters voting once its deposits reach **500 ATOM**; the submitter must post at least 10% of that themselves, and anyone can top up the rest. Proposals that never reach the minimum expire.
- **Voting period**, **7 days**, fixed. There is no lead-in, no confirmation curve, and no per-topic track: a typo fix in a parameter and a full runtime upgrade get exactly the same week.

An **expedited** proposal compresses voting to **3 days** but raises the bar to **66.7%** Yes. The interesting detail is the failure mode: per the [x/gov specification](https://github.com/cosmos/cosmos-sdk/blob/main/x/gov/README.md), an expedited proposal that misses its higher threshold is not rejected, it is _converted into a regular proposal and restarts voting_ under normal rules. Urgency costs you a stricter bar, not the proposal.

## Four options, and what each one actually does

Voters choose **Yes**, **No**, **NoWithVeto**, or **Abstain**, and the three tally rules each count a different denominator. Getting these apart is the whole skill of reading a Cosmos vote:

- **Quorum, 40%**: the share of bonded voting power that _cast anything at all_. Abstain counts here. It is the turnout test.
- **Threshold, 50%**: Yes as a share of Yes + No + NoWithVeto. Abstain is excluded. It is the majority test.
- **Veto, 33.4%**: NoWithVeto as a share of _all_ votes, abstain included. Clear it and the proposal fails no matter how large the Yes majority was.

Abstain is therefore not a null vote. It helps a proposal reach quorum while refusing to help it reach a majority, which is how large validators signal “this should be decided, but not by me”. NoWithVeto is the sharp one: on the Hub, `burn_vote_veto` is set to **true** while `burn_vote_quorum` and `burn_proposal_deposit_prevote` are both **false**. A vetoed proposal's 500 ATOM deposit is destroyed; one that simply fails, or never reaches quorum at all, is refunded in full. The Hub charges you for being _objectionable_, not for being ignored, which is a deliberate spam filter aimed at bad-faith proposals rather than unpopular ones.

## Validator inheritance: the default that decides most votes

The Hub's most consequential design choice is not a threshold, it is a default. Per the [module spec](https://github.com/cosmos/cosmos-sdk/blob/main/x/gov/README.md): _“If a delegator does not vote, it will inherit its validator vote.”_ A delegator who votes after their validator overrides it; one who never votes has still voted, through whoever they staked with.

This is why Cosmos turnout numbers look healthy next to the single-digit participation documented on [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) pages elsewhere in this wiki, and why that comparison is misleading. Turnout measures _bonded stake represented_, not people who formed a view. With `max_validators` set to **200** and a **5%** minimum commission, the practical electorate is a couple of hundred operators whose delegators mostly never override them. Cosmos did not solve apathy; it made apathy vote.

The trade is real in both directions. Inheritance guarantees a decisive result within seven days and removes the quorum-failure mode that stalls [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) DAOs. It also means [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation) chosen for yield, uptime, and commission silently becomes delegation of political authority, and unstaking to escape it costs a **21-day** unbonding period.

The same default carries a credit risk. A double-sign by the validator you picked slashes **5%** of your bonded ATOM whether or not you voted with them, and that 21-day queue means you cannot step out of the way once it happens; see [staking and slashing](/wiki/economics/staking-and-slashing) for the Hub's live penalty parameters.

## Proposal 848, and the fork that followed

The clearest case study in Hub governance is **[Proposal 848](https://www.mintscan.io/cosmos/proposals/848)**, “ATOM Halving: Set the max. Inflation Rate to 10%”, submitted 11 November 2023. Its final on-chain tally, in ATOM:

- Yes: **73,165,204** · No: **56,667,012** · NoWithVeto: **11,669,550** · Abstain: **36,323,836**

Run the three tests separately and the result is a lesson in denominators. Yes took **51.7%** of the non-abstain vote, clearing the 50% threshold by under two points, while amounting to only **41.1%** of everything cast. NoWithVeto reached **6.6%**, nowhere near the 33.4% needed to burn it. The proposal passed, and it is still in force: the Hub's live [mint parameters](https://cosmos-rest.publicnode.com/cosmos/mint/v1beta1/params) read `inflation_max: 0.10` today, against an `inflation_min` of 7% that a later reduction attempt failed to move.

What happened next is the part DAO designers should sit with. The losing 48% did not accept the outcome and did not keep arguing. They left, and took the state with them: [AtomOne](https://atom.one/) launched as a self-described minimal fork of the Hub, airdropped ATONE to over a million ATOM addresses, and rebuilt governance around the specific things its founders objected to, including a live on-chain constitution and the removal of delegation-based voting. A two-point margin on one parameter produced a chain split, which is [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) in its rawest form: when a governance system offers no way out short of forking, forking is the way out. See also [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## Treasury, and the Hub in July 2026

The Hub's [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) is the **community pool**, funded by a **2%** community tax skimmed from staking rewards and spent only by passing proposal. It is a protocol-native fund with no multisig standing between a vote and a disbursement, and, like most on-chain treasuries, it is easier to fill than to deploy well.

Live chain state gives a fair picture of the Hub's current position. Of **521.95M** ATOM in supply, **328.03M** is [bonded](https://cosmos-rest.publicnode.com/cosmos/staking/v1beta1/pool), a bonded ratio near **62.8%**. Because that sits below the protocol's `goal_bonded` of 67%, the inflation schedule drifts up toward its 10% ceiling to bid for more stake, which is exactly the dynamic Proposal 848 capped rather than removed. Governance has kept widening what the chain does: [Proposal 1007](https://www.mintscan.io/cosmos/proposals/1007) (August 2025) enabled permissionless CosmWasm contract deployment, passing with 97.4M ATOM Yes against 1.4M No. It has also kept saying no, rejecting two IBC client-recovery proposals (#1047 and #1048) in July 2026 alone.

## How Caper approaches this

Inheritance is the assumption [Caper](/wiki/foundations/what-is-a-caper) declines. There is no delegation layer in the contract and no validator standing in for you: if you do not vote, nothing votes your balance. A member's weight comes from what they personally hold and the votes they personally cast, computed as `(t × v) / (V × T)`, where `t` is their governance-token balance, `v` the vote tokens they have accumulated, `V` the vote-token supply, and `T` circulating supply. Holdings alone do not carry a vote, and participation alone does not either; the two multiply.

The pass rule differs in the same direction. Rather than testing turnout against total bonded stake, [settlement](/wiki/governance/execution) compares the leading option's share of the weight actually cast against a threshold of `1.5 / number of options`, and refuses to pass a proposal whose leading option is a “no”. Weight is also clamped at the tally to the smaller of what a voter held when they voted and what they hold then (a clamp anyone can re-apply downward until the result settles), so selling out of a position after voting shrinks the vote it bought. See [proposals](/wiki/governance/proposals) and [voting](/wiki/governance/voting) for the full mechanism, and the [networks directory](/wiki/daos/networks) for sibling chains, including [Polkadot](/wiki/daos/networks/polkadot), which reaches for conviction locks where Cosmos reaches for delegation.

## GnosisDAO

URL: https://caper.network/wiki/daos/networks/gnosisdao
Updated: 2026-07-31

|  |  |
| --- | --- |
| **Name** | GnosisDAO |
| **Type** | Protocol / treasury DAO governing the Gnosis ecosystem (Ethereum) |
| **Origin** | Gnosis prediction markets — [April 2017 ICO](https://www.forbes.com/sites/rogeraitken/2017/04/24/gnosis-prediction-market-scores-12-5m-in-record-breaking-crypto-auction/) (250,000 ETH, ~$12.5M, sold out in ~12 minutes) |
| **DAO launched** | December 2020 |
| **Token** | GNO — 3M fixed supply; governs the treasury and ratifies [GIPs](https://forum.gnosis.io/) |
| **Governance** | Off-chain [Snapshot](https://snapshot.org/#/gnosis.eth) voting with trustless on-chain execution via [SafeSnap / Zodiac Reality Module](https://github.com/gnosisguild/zodiac-module-reality) |
| **Treasury** | ~$228M (2026), ~51% held in GNO; dollar value moves with the GNO price |
| **Spun out** | [Safe](https://safe.global/), [CoW Protocol](https://cow.fi/), [Gnosis Chain](https://www.gnosischain.com/), [Gnosis Pay](https://gnosispay.com/), [Circles](https://www.aboutcircles.com/), [Zodiac](https://www.zodiac.wiki/) |
| **Founders** | Martin Köppelmann · Stefan George (ConsenSys-incubated, 2015) |
| **Site** | [gnosis.io](https://www.gnosis.io/) · [forum](https://forum.gnosis.io/) · [Snapshot](https://snapshot.org/#/gnosis.eth) |

**GnosisDAO** is the community-run treasury and governance body of the Gnosis ecosystem — one of the oldest continuously-operating organizations on Ethereum. It began not as a DAO but as a [prediction-market](/wiki/dao-governance/concepts/fundamentals/history-of-daos) protocol: Gnosis was [founded in 2015](https://www.gnosis.io/blog/ten-years-of-gnosis-from-prediction-markets-to-a-user-owned-open-finance-revolution) by Martin Köppelmann and Stefan George inside the ConsenSys incubator, and its [April 2017 ICO](https://www.forbes.com/sites/rogeraitken/2017/04/24/gnosis-prediction-market-scores-12-5m-in-record-breaking-crypto-auction/) raised 250,000 ETH (~$12.5M at the time) in about twelve minutes — a landmark early token sale. In December 2020 the project handed control of its treasury and roadmap to **GNO** holders, converting a company-led protocol into a [protocol DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) that has since become a holding entity for a portfolio of spun-out products.

## Oracle-executed governance: SafeSnap and Zodiac

GnosisDAO's most-copied contribution is a governance pattern that keeps voting cheap while making execution trustless. Proposals (Gnosis Improvement Proposals, "GIPs") are drafted on the [forum](https://forum.gnosis.io/), then ratified by a gas-free [Snapshot](https://snapshot.org/#/gnosis.eth) vote — [off-chain signalling](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) that costs holders nothing. The innovation is what happens next: [SafeSnap](https://medium.com/gnosis-pm/introducing-safesnap-the-first-in-a-decentralized-governance-tool-suite-for-the-gnosis-safe-ea67eb95c34f) — now the [Zodiac Reality Module](https://github.com/gnosisguild/zodiac-module-reality) — attaches the executable transactions to that Snapshot vote and posts the outcome to the [Reality.eth](https://reality.eth.limo/) escalation-game oracle. Once the oracle finalizes the result and a cooldown passes, anyone can trigger the on-chain transactions permissionlessly from the DAO's [Safe](https://safe.global/). This "optimistic governance" bridges the gap between free off-chain voting and binding on-chain action without a trusted multisig deciding what the vote "meant" — [GIP-11](https://forum.gnosis.io/t/gip-11-enable-safesnap/1250) enabled it for GnosisDAO, and it now underpins dozens of DAOs. Compare it to the fully [on-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) and delegate-based models in [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models).

## The ecosystem it spun out

GnosisDAO functions less like a single product and more like an [on-chain holding company](/wiki/dao-governance/concepts/treasury/dao-treasury-management): tools built for internal use were repeatedly graduated into standalone projects, several with their own tokens and DAOs.

- [Safe](https://safe.global/) (formerly Gnosis Safe) — the dominant smart-contract wallet / multisig standard, [securing $100B+ in assets](https://www.gnosis.io/blog/ten-years-of-gnosis-from-prediction-markets-to-a-user-owned-open-finance-revolution); spun out with its own [SafeDAO](/wiki/daos/infrastructure/safe-dao) and SAFE token.
- [CoW Protocol](https://cow.fi/) — batch-auction, MEV-protecting DEX aggregator (CoW Swap), now governed by [CoW DAO](/wiki/daos/dexs/cow-dao) and the COW token.
- [Gnosis Chain](https://www.gnosischain.com/) — an EVM Layer-1 (the former xDai chain) where GNO is the staking asset for validators.
- [Gnosis Pay](https://gnosispay.com/) — a self-custodial Visa debit card settling directly from an on-chain Safe.
- [Circles](https://www.aboutcircles.com/) — a personal-currency / universal-basic-income money system.
- [Zodiac](https://www.zodiac.wiki/) — the open standard behind SafeSnap and a toolkit of composable DAO modules used far beyond Gnosis.

## GIP-151: the treasury-redemption vote (2026)

Because GNO's ~$228M treasury is roughly half held in liquid assets while GNO itself often trades below that per-token backing, GnosisDAO became a case study in a question every token-treasury DAO eventually faces: _does the token grant a claim on the assets behind it?_ In April 2026 a group of activist holders dubbed the "[RFV Raiders](https://protos.com/rfv-raiders-target-gnosis-dao-for-treasury-redemption-proposal/)" (led by community member Wismerhill) proposed [GIP-150](https://forum.gnosis.io/t/gip-150-should-gnosisdao-let-gno-holders-redeem-their-pro-rata-share-of-the-treasury/12263) — a voluntary, one-time mechanism letting GNO holders redeem their [pro-rata share](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) of the treasury: in-kind distribution of the liquid buckets plus `gLTD-CLAIM` tokens representing future claims on illiquid venture holdings. GIP-150 was rejected on Snapshot by roughly five-to-two.

Its successor **GIP-151** passed decisively — [reportedly at ~215% of the required quorum](https://cryptoslate.com/a-223m-dao-vote-could-turn-governance-into-a-cash-out-button/) — authorizing the redemption against ~$223M of assessed value, an estimated ~$115 of backing per GNO. The result put a treasury-linked floor under the token: GNO [surged](https://thedefiant.io/news/defi/gnosis-treasury-redemption-vote-swings-as-whale-counters-cofounder) on the news, and a redemption interface went live at [redeem.gno.now](https://redeem.gno.now/). The episode is one of 2026's clearest demonstrations that a governance token with a large treasury behind it can, by a single vote, be turned into a redeemable claim — reshaping the incentives around [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) across the industry.

## How Caper approaches this

GnosisDAO had to hold a contentious governance fight to _build_ a treasury redemption at all — and even then it is a one-time, opt-in event. [Caper](/wiki/foundations/what-is-a-caper) makes that redemption a standing, protocol-native right. Every caper's `exit()` function lets a member burn their vote tokens and redeem a pro-rata slice of the treasury at any time — no proposal, no quorum, no bespoke smart contract. Crucially, a member's redemption share equals their [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)`, computed by the exact same function that sets their voting power: the influence you carry and the value you can walk away with are one and the same number. Where GnosisDAO's saga asked "should the token be a claim on the treasury?", Caper answers that at the protocol layer — the "cash-out button" is always present, and it is inseparable from governance rather than voted into existence.

## Helium (HNT)

URL: https://caper.network/wiki/daos/networks/helium
Updated: 2026-08-03

| Project | Helium (the People's Network) |
| --- | --- |
| Type | DePIN — decentralized wireless (LoRaWAN IoT + 5G/CBRS mobile) |
| Native token | HNT (Solana SPL) |
| Governance | veHNT vote-escrow via [Realms](https://app.realms.today/); Helium Improvement Proposals (HIPs) |
| subDAO tokens | IOT and MOBILE (being phased out — see HIP-138) |
| Blockchain | Solana (migrated from its own L1 in 2023) |
| Launched | Company founded 2013; HNT mainnet 2019 |
| Status | 🟢 Active |
| Website | [helium.com](https://www.helium.com) |

**Helium** is the canonical [DePIN](/wiki/dao-governance/concepts/fundamentals/types-of-daos) — a decentralized physical infrastructure network — and one of the few DAOs whose token rewards are paid for producing a real-world good rather than an on-chain one. Individuals run "Hotspots" that provide wireless coverage ([LoRaWAN for Internet-of-Things devices and, since 2022, 5G mobile](https://en.wikipedia.org/wiki/Helium_Network)) and earn HNT in proportion to verifiable coverage and data transfer. The network began as Helium, Inc. in 2013 under co-founder Amir Haleem, pivoting in 2017 to pay node operators in cryptocurrency ([Wikipedia](https://en.wikipedia.org/wiki/Helium_Network)).

What makes Helium interesting as a governance case study is that it has restructured its token model twice by community vote — first splitting into a multi-token subDAO federation, then reversing course back to a single token — with each turn decided through vote-escrowed HNT. It is the wiki's reference for how a DAO coordinates _hardware_ incentives, and for what happens when governance is used to undo its own earlier design.

## From its own L1 to Solana

Helium originally ran a purpose-built Layer 1 blockchain. In late 2022 the core team proposed [HIP-70](https://medium.com/helium-foundation/hip-70-passed-solana-here-we-come-e0578eba2de9), moving Proof-of-Coverage, data-transfer accounting, and token issuance onto [Solana's](/wiki/daos/dexs/curve-dao) high-throughput chain to shed the burden of maintaining a bespoke L1. The proposal passed with 6,177 wallets voting — the most "For" votes on any HIP in Helium's history — and the network [migrated to Solana on 18 April 2023](https://solana.com/news/case-study-helium). Governance moved with it: staking, voting, and treasury operations now run through Solana's SPL governance tooling ([Realms](https://heliumvote.com/)).

## veHNT and the subDAO model

Helium's governance is [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow), established by [HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md) and its siblings HIP-52 and HIP-53. Holders lock HNT to receive **veHNT** voting power, and — importantly — the docs describe these locked positions as [Non-Fungible Tokens that are “not tradable or transferable and are considered ‘soulbound’ to your wallet”](https://github.com/helium/HIP/blob/main/0051-helium-dao.md). Voting power scales with both size and lock length: a minimum six-month lock earns 1× the veHNT, a maximum four-year lock earns 100×.

HIP-51 also drew a line between the _Network_ and its _subnetworks_, each with its own token: **IOT** for the IoT network and **MOBILE** for the cellular network. veHNT could be delegated to the IOT or MOBILE subDAO to earn a share of that subnetwork's emissions, and the split of new HNT minted to each subDAO was proportionate to the veHNT delegated to it — a design that let each subnetwork govern its own build-out while remaining backed by, and convertible to, HNT ([HIP-51](https://github.com/helium/HIP/blob/main/0051-helium-dao.md)).

## Return to one token

The multi-token structure proved hard to explain and hard to value. In November 2024 the community proposed [HIP-138, “Return to HNT”](https://github.com/helium/HIP/blob/main/0138-return-to-hnt.md), which phases out the IOT and MOBILE subnetwork tokens and returns the network to rewarding participants directly in HNT. In the authors' words, "moving to a single token simplifies the Helium ecosystem, making it more understandable for current and future network builders." The same proposal ends HNT emissions to Helium Security Token (HST) holders — early Nova Labs investors and employees, who had been receiving 30% of emitted HNT declining toward 15% — redirecting that HNT to active Hotspot owners and builders and increasing rewards to participants [by over 40%](https://github.com/helium/HIP/blob/main/0138-return-to-hnt.md).

The reversal is the noteworthy part. Helium used its governance process to build an elaborate multi-DAO token economy, ran it for two years, and then used the _same_ process to dismantle it — a live demonstration that on-chain token structure is not permanent when a DAO retains the power to rewrite it. (Compare the [durability-versus-flexibility trade-off](/wiki/dao-governance/concepts/analysis/how-daos-fail) that recurs across DAO design.)

## The off-chain trust problem

Not everything about Helium was decided on-chain, and that is where its sharpest cautionary tale lies. In January 2025 the U.S. SEC charged Nova Labs — the company that launched Helium — with misleading investors during a 2021–2022 round that raised $200 million at a $1 billion valuation, by exaggerating relationships with Nestlé, Salesforce, and Lime ([SEC litigation release](https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26291)). Per the complaint, the Nestlé relationship was a small 2018 hardware test predating Nova Labs' crypto business, and the Lime relationship amounted to two demonstrations to two Lime employees; both companies later sent cease-and-desist letters. Nova Labs settled in April 2025, paying $200,000 without admitting or denying wrongdoing, and the SEC dropped a separate unregistered-securities claim ([CoinDesk](https://www.coindesk.com/policy/2025/04/10/helium-issuer-nova-labs-agrees-to-pay-sec-usd200k-to-settle-allegations-it-lied-to-investors-about-brand-partnerships)).

The governance lesson generalizes: a DAO can make its _on-chain_ mechanics transparent and still carry off-chain claims that its token-holders cannot verify from the ledger. Decentralizing the vote does not decentralize the marketing.

## How Caper approaches this

Helium and [Caper](/wiki/foundations/what-is-a-caper) both reach for the word "soulbound," but they bind very different things. A veHNT position is soulbound only in the sense that a _locked capital position_ cannot be sold while it is locked — it is bought with HNT, its weight is proportional to how much you locked and for how long, and when the lock expires your capital comes back. It is a time-boxed bet, not a record of participation.

Caper's soulbound token is the opposite kind of soulbound. Verified against the contract (`contracts/core/src/caper_dao.rs`), every vote mints a non-transferable proof-of-vote token (indivisible, depositable only by the DAO component itself), and a member's influence is `w = (t · v) / (V · T)` — where _v_ is the votes they have actually cast. That weight is _earned by taking part_, never unlocks, and cannot be bought or rented; a member's first-ever vote even counts for zero, because the snapshot is taken before the token mints. The identical figure sets each member's [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) share of the treasury, then the vote tokens are burned. Holdings still matter — _t_ is a genuine multiplier, so this is not "one person, one vote" — but the decisive, un-buyable half of control is the participation history that Helium's expiring capital lock does not attempt to capture.

## Mantle (formerly BitDAO)

URL: https://caper.network/wiki/daos/networks/mantle
Updated: 2026-07-31

|  |  |
| --- | --- |
| **Name** | Mantle (formerly BitDAO) |
| **Type** | Treasury / ecosystem DAO — a mega-treasury that operates a modular Ethereum L2 and on-chain finance products |
| **Governance token** | MNT — voting weight in Mantle Governance and gas on Mantle Network (converted 1:1 from BitDAO's BIT, from June 2023) |
| **Origin** | BitDAO (2021, backed by [Bybit](https://www.bybit.com/)); rebranded and merged with Mantle Network via [proposal BIP-21](https://www.theblock.co/post/231557/ethereum-layer-2-mantle-network-merges-with-backer-bitdao) in mid-2023 |
| **Governance model** | One MNT = one vote, off-chain [Snapshot](https://snapshot.org/) voting; treasury moved to Budget Treasuries only via Budget Proposals |
| **Treasury** | Among the largest in the industry — multiple billions of dollars, held largely in its own MNT plus ETH and stablecoins |
| **Products** | [Mantle Network](https://www.mantle.xyz/) (OP-stack L2), the [mETH](https://www.mantle.xyz/meth) liquid-staking protocol, and the $200M [Mantle EcoFund](https://www.mantle.xyz/ecofund) |

**Mantle** is a DAO built around one of the largest treasuries in crypto, and the clearest example of the _mega-treasury_ archetype in the [directory](/wiki/daos). It began as **BitDAO**, a 2021 treasury DAO seeded by the exchange Bybit that raised and warehoused a multi-billion-dollar war chest, then reinvented itself as a product organisation: in 2023 the community voted to merge BitDAO's governance and treasury with the Mantle Network Ethereum layer-2 and rebrand the whole thing "Mantle." Today MNT holders govern a treasury running into the billions and a stack of on-chain-finance products built on top of it.

## From BitDAO to Mantle: the 2023 merger

BitDAO launched in 2021 as a pure treasury DAO — capital in, governance token (BIT) out, and a mandate to fund web3 builders. What made it unusual was scale: it accumulated a treasury of [over $2.5 billion](https://cryptoslate.com/bitdao-mantle-merger-creates-2-5b-dao-led-web3-ecosystem/) at merger time, dwarfing almost every other DAO.

In mid-2023 the community passed [BIP-21, “Optimization of Brand, Token and Tokenomics”](https://www.theblock.co/post/231557/ethereum-layer-2-mantle-network-merges-with-backer-bitdao), authorising a merger of BitDAO's governance and treasury with Mantle Network — an Ethereum L2 that BitDAO had itself funded. BIT was rebranded to **MNT** and converted 1:1, and the treasury (including "almost $300 million" in stablecoins and "over 270,000 ETH") passed to the unified ecosystem. The move turned a passive treasury DAO into an operating one: instead of only funding outside builders, the DAO now runs its own chain and products. It is the mirror image of a pure [venture DAO like The LAO](/wiki/daos/investment/the-lao), which invests but never operates.

## The mega-treasury archetype

Mantle's defining feature is the size and composition of its treasury. It is consistently ranked among the largest DAO treasuries tracked by [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao), running into several billion dollars. That scale is also its central risk, and a live illustration of the [concentration problem](/wiki/dao-governance/concepts/treasury/dao-treasury-management): a large share of the treasury is held in Mantle's own MNT, so its dollar value swings with the token's price and much of it can only be realised by selling the asset whose price the sale would move. The DAO diversifies into ETH and stablecoins for exactly this reason, and the [tokenomics](https://docs.mantle.xyz/governance/parameters/tokenomics) formally separate non-circulating _Treasury Holdings_ from the _Budget Treasuries_ that fund day-to-day spending.

## Governance: one token, one vote, off-chain

Mantle is governed by MNT holders on a straightforward [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) basis — one MNT equals one vote — with proposals decided by off-chain [Snapshot](https://snapshot.org/) voting rather than on-chain execution. Of the [~6.22 billion MNT](https://docs.mantle.xyz/governance/parameters/tokenomics) minted at launch, roughly half sits in the Treasury and half circulates. Spending is gated by process rather than by code: MNT transfers from Treasury Holdings to a Budget Treasury must be authorised by a **Budget Proposal** before any funds are distributed, and execution is carried out by the ecosystem's operators rather than enforced by the vote itself.

This is the standard large-treasury pattern — a big, buyable, token-weighted electorate deciding off-chain, with a human execution layer between the vote and the money. It is powerful at Mantle's scale, but it also means voting power tracks capital, and the gap between "the vote passed" and "the funds moved" is filled by trust.

## From treasury to operating stack

The merger reframed the treasury as fuel for products rather than an end in itself. Three pieces stand out. [Mantle Network](https://www.mantle.xyz/) is a modular, OP-stack Ethereum layer-2 — the same [Optimism](/wiki/daos/networks/optimism-collective) lineage many rollups share — with MNT as its gas token. The [mETH Protocol](https://www.mantle.xyz/meth) is a liquid ETH staking and restaking product that has grown into one of the larger [liquid-staking](/wiki/daos/staking/lido-dao) protocols by TVL, putting the DAO in direct competition with [Rocket Pool](/wiki/daos/staking/rocket-pool) and Lido. And the [Mantle EcoFund](https://www.mantle.xyz/ecofund) is a DAO-established ~$200M venture vehicle that co-invests alongside outside VCs to seed projects on Mantle — a governance-created fund in the spirit of a [venture DAO](/wiki/daos/investment/the-lao), but pointed inward at its own ecosystem.

## How Caper approaches this

Mantle shows what maximal treasury scale looks like: billions of dollars, an off-chain token-weighted electorate, and a trusted execution layer that moves the money after a vote passes. A [caper](/wiki/foundations/what-is-a-caper) deliberately occupies the opposite corner. Its treasury is a protocol-controlled vault _inside_ the contract, moved only by a typed, on-chain proposal (a PAYOUT or INVEST), so there is no gap between the vote and the transfer for trust to fill — the passing vote _is_ the execution.

And where Mantle's weight is one-MNT-one-vote — capital that anyone can buy on the open market — a caper folds an **earned, non-transferable** factor into governance. A member's voting weight is `(t·v)/(V·T)` — held tokens times accumulated votes, over supply times circulation (verified in [the contract's](https://github.com/) `compute_vote_weight`) — and those vote tokens are minted one-per-vote as [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens), divisibility-none records that can never be transferred or bought. The same metric sizes a member's [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) share of the treasury. This is not "your bag doesn't count" — held stake `t` is a multiplier, so capital still matters — but it does mean a well-funded buyer can't simply purchase control the way they can accumulate MNT. Mantle buys scale and an operating business the DAO governs; a caper trades that reach for a treasury no one has to be trusted to move and an influence factor no one can buy outright.

## Optimism Collective

URL: https://caper.network/wiki/daos/networks/optimism-collective
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Name** | Optimism Collective |
| **Type** | Protocol DAO (Ethereum Layer-2 / the Superchain) |
| **Governance token** | OP (first airdrop June 2022; initial supply 4,294,967,296) |
| **Governance model** | **Bicameral**: the Token House (OP holders) and the non-token Citizens' House |
| **Treasury** | Governance Fund + a ~20% public-goods reserve (~850M OP); track live on DeepDAO |
| **Notable for** | Retroactive Public Goods Funding; a widely-copied non-plutocratic two-house design |
| **Retro Funding status** | **Paused.** “[The Retro Funding program will not run for at least the next 12 months](https://www.optimism.io/blog/season-9-from-experiment-to-organization)” (8 January 2026) |
| **Primary sources** | [gov.optimism.io](https://gov.optimism.io/), [docs.optimism.io/governance](https://docs.optimism.io/governance), [optimism.io/blog](https://www.optimism.io/blog) |
| **Related** | [Arbitrum DAO](/wiki/daos/networks/arbitrum-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Public-goods funding](/wiki/desci/desci-funding) |

The **Optimism Collective** governs [Optimism](https://www.optimism.io/), an Ethereum [Layer-2](/wiki/daos/networks/arbitrum-dao) optimistic rollup, and the wider **Superchain** of chains built on the open-source **OP Stack** — a federation that includes OP Mainnet, Coinbase's **Base**, Unichain, World Chain, and others sharing standards, tooling, and governance. Its defining feature is a **bicameral** government designed to keep decision-making from collapsing into pure token-holder rule. Live chain standing is tracked on [L2Beat](https://l2beat.com/scaling/summary). ([Superchain explainer](https://docs.optimism.io/superchain/superchain-explainer))

## Bicameral governance — two houses

The Collective splits authority between two chambers with deliberately different membership. The **Token House** — [OP holders](/wiki/dao-governance/concepts/voting/token-weighted-voting) and their delegates — governs protocol upgrades, project incentives, inflation, treasury appropriations, and director removals. The **Citizens' House** is **reputation-based and non-token** (one entity, one vote), and its primary job is deciding how to allocate funding for public goods. The stated rationale, from the Collective's founding, is that "tokenholders represent one constituency out of many, and are not always the right unilateral owners for decisions that don't involve the economics of the system." Matching different decisions to different constituencies is the central experiment other DAOs have since borrowed. ([Introducing the Optimism Collective](https://www.optimism.io/blog/introducing-the-optimism-collective); [Operating Manual](https://gov.optimism.io/t/operating-manual-of-the-optimism-collective-v0-2-0/3370))

## The OP token

**OP** is the governance token of the Token House, with an initial supply of exactly 4,294,967,296 (2³²). Its first airdrop, in **June 2022**, distributed roughly 5% of supply to reward early users and active community members, and OP holders vote on the Governance Fund, protocol upgrades, and OP inflation. The genesis allocation set aside a striking **20% of supply for retroactive public goods funding** and ~5.4% for the Governance Fund, alongside airdrops, contributors, and investors. ([Optimism: token allocation](https://www.optimism.io/blog/introducing-the-optimism-collective))

## Retroactive Public Goods Funding

The Collective's signature idea is **Retroactive Public Goods Funding (RetroPGF, or "Retro Funding")**, which rests on the thesis that **"impact = profit"**: because it is far easier to agree on what _was_ useful than what _will be_, the Collective rewards work after it has proven valuable. The **Citizens' House allocates it** from the ~20% (≈850M OP) reserve. Across its first several rounds Retro Funding grew from ~$1M in Round 1 (2022) to tens of millions of OP per round, and Optimism reports well over 60 million OP distributed to builders since 2022. In 2025 the model shifted from discrete annual rounds to an ongoing, **metrics-driven "missions"** system with rolling applications and monthly measurement across categories like Dev Tooling and Onchain Builders. Network sequencer revenue is directed back toward public goods, forming the intended funding flywheel. ([Citizens' House launch](https://www.optimism.io/blog/introducing-the-citizens-house-10m-op-to-public-goods); [Retro Funding 2025](https://www.optimism.io/blog/retro-funding-2025))

**The programme is currently paused.** On **8 January 2026**, announcing Season 9, the Optimism Foundation wrote that “[the Retro Funding program will not run for at least the next 12 months](https://www.optimism.io/blog/season-9-from-experiment-to-organization)”, as the Collective reorients toward execution, scale, and enterprise adoption. The Foundation said it would assess other ways to support public goods, and flagged that a proposal may be brought to re-allocate all or part of the roughly **775 million OP** still reserved for Retro Funding to other purposes. That is the single largest reversal to date in the sector's flagship [retroactive-funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) experiment, and it leaves the Citizens' House — a chamber whose defining job was allocating that reserve — without its principal mandate for the duration.

## How the process works

Governance runs in **Seasons**, each with an updated charter, under an **Operating Manual** that fixes the proposal types and process. Standing bodies handle specialized work: a **Grants Council** allocates Governance Fund grants, and a **Developer Advisory Board** reviews protocol upgrades on technical merit, with a stakeholder veto window before an upgrade takes effect. Citizenship itself is conferred by a **non-transferable ("soulbound") credential** — evolving from an early Foundation-selected, web-of-trust set toward proof-of-personhood and onchain-activity criteria — and the **Law of Chains** extends governance from a single chain to the shared standard that binds the Superchain together. ([Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md); [Law of Chains](https://www.optimism.io/blog/introducing-the-law-of-chains))

## Recent developments

In January 2026 the Collective approved (with about 84% in favor) an **OP buyback pilot** directing 50% of net Superchain sequencer revenue to monthly open-market OP repurchases for a twelve-month trial — Optimism's first formal link between OP demand and Superchain revenue, with repurchased tokens held for future governance-decided use. It was approved three weeks _after_ the Foundation paused Retro Funding, and the pairing is the clearest signal of the Collective's 2026 reorientation: sequencer revenue that the original design pointed at public goods is now being pointed, at least in part, at the token itself. ([CoinDesk, Jan 2026](https://www.coindesk.com/business/2026/01/28/optimism-governance-approves-op-token-buyback-plan-tied-to-superchain-revenue))

## How Caper approaches this

Optimism's bicameral design separates economic voting from public-goods allocation precisely to blunt [plutocracy](/wiki/dao-governance/concepts/voting/token-weighted-voting) — the risk that whoever holds the most tokens decides everything. A [caper](/wiki/foundations/what-is-a-caper) targets the same concern with a single house but a different weighting: voting power is **participation-gated**, multiplying a member's governance-token stake by the non-transferable vote tokens they earn only by actually voting, so a first-time or purely-financial holder starts at zero weight. It is honestly a narrower tool than a second chamber — participation-gating, not proof-of-personhood — described neutrally on the linked [Caper governance](/wiki/governance/voting-mechanisms) pages.

## References

- [Introducing the Optimism Collective](https://www.optimism.io/blog/introducing-the-optimism-collective) — the bicameral design and token allocation.
- [Optimism Governance Forum](https://gov.optimism.io/) — proposals and Seasons.
- [Optimism governance docs](https://docs.optimism.io/governance).
- [Retro Funding 2025](https://www.optimism.io/blog/retro-funding-2025) — the shift to a continuous missions model.
- [Season 9: From Experiment to Organization](https://www.optimism.io/blog/season-9-from-experiment-to-organization) (8 Jan 2026) — the Retro Funding pause and the ~775M OP reserve.
- [L2Beat](https://l2beat.com/scaling/summary) — live Superchain standing.

## Polkadot (DOT & OpenGov)

URL: https://caper.network/wiki/daos/networks/polkadot
Updated: 2026-07-30

| Type | Layer-0 relay chain / sovereign-network DAO |
| --- | --- |
| Governance token | DOT (voting, staking, bonding) |
| Governance mechanism | Polkadot OpenGov — fully on-chain conviction-voted referenda across 15 origin tracks |
| Founder / steward | Gavin Wood; Web3 Foundation & Parity Technologies |
| Relay chain launch | May 2020 (DOT redenominated 100× Aug 2020) |
| OpenGov live | June 2023 (replaced the Council-based Governance V1) |
| Treasury | On-chain, funded by fees + inflation + slashes; spends by referendum |
| Website | [polkadot.com](https://polkadot.com) · [OpenGov docs](https://wiki.polkadot.com/learn/learn-polkadot-opengov/) |

## What Polkadot governs

[Polkadot](https://polkadot.com) is a layer-0 network: a central **relay chain** that provides shared security and interoperability to the parachains connected to it. Its native token, **DOT**, is used to stake for validation, bond parachain slots, and—most relevant here—to govern the protocol itself. The relay chain went live in [May 2020](https://polkadot.network/blog/polkadot-launch/), and DOT was [redenominated 100×](https://support.polkadot.network/support/solutions/articles/65000168057-how-was-the-dot-redenomination-implemented-) in August 2020.

Unlike most token-DAOs on this directory—which run off-chain [token-weighted votes](/wiki/dao-governance/concepts/voting/token-weighted-voting) on Snapshot and then execute through a multisig—Polkadot's governance is **entirely on-chain**. An approved referendum executes its own privileged call directly against the runtime, with no council or foundation as an execution intermediary. That makes it one of the purest large-scale examples of [on-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) in production.

## From Governance V1 to OpenGov

Polkadot's original model (“Gov1”) split power between a token-elected **Council**, a **Technical Committee**, and public referenda. In [June 2023](https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance), Polkadot enacted **OpenGov** (formerly [“Gov2”](https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance)), which **abolished the Council entirely** and handed every decision to direct, token-holder referenda.

The key unlock is **parallelism**: Gov1 could decide roughly one referendum at a time, whereas OpenGov lets many referenda run simultaneously across different classes of decision, each with a risk-calibrated set of rules. A tweak to a treasury tip and a change to the Root runtime no longer compete for the same queue.

## Origins and tracks

Every privileged action in OpenGov is dispatched from an **Origin**, and each origin is bound to a **track** with its own capacity, deposit, and timing rules. There are [15 origins](https://wiki.polkadot.com/learn/learn-polkadot-opengov-origins/), ordered roughly by how much damage a bad decision could do:

- **Root** — the most powerful origin (runtime upgrades, setting the code itself). It accepts only one proposal at a time and carries the longest lead-in and highest deposits.
- **Whitelisted Caller** — a fast path for changes that the [Technical Fellowship](https://wiki.polkadot.com/learn/learn-polkadot-technical-fellowship/) has vetted and whitelisted, with shorter timing than Root while still requiring a token-holder referendum.
- **Treasury spenders** — a graduated ladder from the _Small Tipper_ (up to 250 DOT) through _Big Tipper_, _Small_/_Medium_/_Big Spender_, up to the _Treasurer_ (up to 10,000,000 DOT). Bigger asks route to higher-scrutiny tracks.

Riskier tracks demand higher turnout and slower timelines; a cheap tip can clear quickly, while a Root change must survive a long, high-bar decision window.

## Conviction voting and the referendum lifecycle

OpenGov weighs votes by **[conviction](/wiki/dao-governance/concepts/voting/conviction-voting)**: a voter multiplies their voting power by voluntarily locking DOT for longer after the vote resolves. The multiplier runs from **0.1×** (no lock) up to **6×**, where the 6× level locks tokens for 32 lock periods (roughly 224 days). Voting power is `tokens × conviction`, so someone who is willing to be locked in behind a decision counts for more than a whale who wants their DOT back immediately.

A referendum passes only if two curves are both satisfied through a **confirmation period**: **Approval** (the conviction-weighted share of _aye_ votes) and **Support** (turnout, measured against total possible votes). Both thresholds _relax over time_—an uncontroversial proposal can meet a high early bar, while a contested one has to wait for the curves to loosen. The lifecycle is: _Lead-in_ → _Decision_ → _Confirmation_ → _Enactment_, per the [OpenGov reference](https://wiki.polkadot.com/learn/learn-polkadot-opengov/).

DOT holders who don't want to vote on everything can use **multirole [delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation)**: delegate voting power to a different trusted account _per origin_, so you might follow one expert on treasury spends and another on technical upgrades.

## The on-chain Treasury

Polkadot runs a large, protocol-owned [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) that spends only by referendum. Per the [treasury docs](https://wiki.polkadot.com/learn/learn-polkadot-opengov-treasury/), it is funded by **80% of transaction fees** (the other 20% goes to block producers), **15% of annual DOT inflation**, and slashed validator/nominator stake. Crucially, unspent funds are **partially burned** at the end of each spend period—a deliberate pressure to _deploy capital rather than hoard it_, a problem many idle DAO treasuries never solve.

Spending flows through the _Tipper_ and _Spender_ tracks above. For recurring, curated work, the treasury also funds **bounties**: a parent bounty reserves DOT under a curator (usually a multisig), and _child bounties_ pay out from it without a fresh referendum for every disbursement—an on-chain answer to the [working-group](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups) funding problem.

## The Technical Fellowship

OpenGov removed the appointed Technical Committee and replaced it with the on-chain **[Polkadot Technical Fellowship](https://wiki.polkadot.com/learn/learn-polkadot-technical-fellowship/)**: a permissionless, rank-based collective of the protocol's technical experts. Ranks run from **0 (Member) to 9 (Grand Master)**, votes inside the Fellowship are weighted by rank, and members are promoted through the Fellowship's own referenda (see the live [fellowship dashboard](https://polkadot-fellows.github.io/dashboard/)).

The Fellowship's main governance power is **whitelisting**: it can flag a proposal as technically sound, routing it to the faster _Whitelisted Caller_ origin. It cannot enact anything alone—a whitelisted proposal still faces a full token-holder referendum. This is a clean separation of _expertise_ from _authority_: technical review speeds a decision up, but token holders still decide.

## How Caper approaches this

Conviction voting solves a real problem—letting committed holders outweigh mercenary ones—by asking voters to _opt in_ to a lock. [Caper](/wiki/foundations/what-is-a-caper) reaches the same goal without a separate locking step. A member's weight on a proposal is computed directly from the stake they already hold in that specific caper: in the contract it is `(your caper-token holdings × your votes) / (vote supply × circulating supply)`, and when the tally is taken after voting closes, the holdings term is clamped to the smaller of what you held when you voted and what you hold then (a clamp anyone can re-apply downward until the result settles), so selling out of a position after voting shrinks the vote it bought. Influence and exposure move together by construction—you weigh more because you already have more capital at risk in the outcome, not because you signed up for a longer lock.

See also sibling network DAOs [Arbitrum](/wiki/daos/networks/arbitrum-dao) and [the Optimism Collective](/wiki/daos/networks/optimism-collective), and the [networks directory](/wiki/daos/networks).

## Polygon (POL)

URL: https://caper.network/wiki/daos/networks/polygon
Updated: 2026-07-23

| Type | Multichain scaling network / network DAO (Ethereum-aligned) |
| --- | --- |
| Native token | POL — gas + staking on Polygon PoS, and the coordination token for the wider network |
| Migrated from | MATIC → POL, 1:1, native token from 4 September 2024 |
| Genesis supply | 10,000,000,000 POL, with 2% annual emission (PIP-17) |
| Governance | Three pillars — protocol (PIPs), system contracts (Protocol Council), community treasury |
| Protocol Council | 13-member multisig · 7/13 with 10-day timelock (regular), 10/13 with none (emergency) |
| Builder | Polygon Labs (network stewarded toward the Polygon community / Foundation) |
| Website | [polygon.technology](https://polygon.technology) |

## Overview

[Polygon](https://polygon.technology) began in 2017 as Matic Network, an Ethereum scaling sidechain, and is now a family of Ethereum-aligned chains coordinated under the **Polygon 2.0** roadmap. Its flagship [Polygon PoS](https://polygon.technology/polygon-pos) chain runs a permissionless proof-of-stake validator set that checkpoints to Ethereum, and the newer [AggLayer](https://www.agglayer.dev) is a cross-chain settlement layer designed to let many chains share liquidity and behave as one network. Governance of the protocol, its system contracts, and a community-owned treasury is what makes Polygon a [network DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) rather than a company product — a peer of [Arbitrum](/wiki/daos/networks/arbitrum-dao), the [Optimism Collective](/wiki/daos/networks/optimism-collective), and [ZKsync](/wiki/daos/networks/zksync-era) in this directory.

## POL: the migration and the token

In September 2024 Polygon completed the network's biggest token change: **MATIC was upgraded to POL 1:1**, and since [4 September 2024](https://polygon.technology/blog/matic-to-pol-migration-is-99-complete-everything-you-need-to-know) every Polygon PoS transaction pays gas in POL and staking is denominated in POL. As of mid-2025 roughly **99%** of MATIC had migrated; holders and delegators on Polygon PoS needed to do nothing, as the swap was automatic.

POL's economics are set by [PIP-17](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-17.md): a **10 billion** genesis supply minted to the migration contract, plus a **2% annual emission** split evenly — **1% to validator staking rewards** and **1% to the Community Treasury** — with minting capped on-chain at 10 POL per second. POL is designed as a _hyperproductive_ token: one stake is meant to secure and be paid across many Polygon chains and roles (block validation, ZK proving, data availability) rather than one chain alone, which is the economic backbone of the [Polygon 2.0](https://polygon.technology/blog/polygon-2-0-tokenomics) multichain design.

## Three pillars of governance

Polygon 2.0 organises decisions into [three governance pillars](https://polygon.technology/blog/kicking-off-the-polygon-governance-hub-a-unified-and-transparent-interface-for-community-governance), each with its own venue and process:

- **Protocol Governance** — changes to the core protocol move through the [Polygon Improvement Proposal (PIP)](https://github.com/maticnetwork/Polygon-Improvement-Proposals) framework: an idea is discussed on the [Polygon Community Forum](https://forum.polygon.technology), drafted against a template, refined on Protocol Governance Calls, and adopted by rough consensus. [PIP-1](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-01.md) and PIP-8 set the ground rules; a [PRC](https://github.com/maticnetwork/Polygon-Improvement-Proposals) track covers token standards.
- **System Smart Contracts Governance** — upgrades to the on-chain contracts that _are_ the protocol (bridge, staking, emission manager) are executed by the **Protocol Council**, not by a raw token vote.
- **Community Treasury Governance** — the 1%-of-emissions treasury is a self-sustaining ecosystem fund for public goods, research, grants, and adoption, allocated under community oversight.

This split is deliberate: high-stakes contract upgrades get a fast, accountable, timelocked body, while direction-setting and funding stay open to the wider community. It is a different answer to the same tension explored in [on-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) and [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization).

## The Protocol Council

[The Protocol Council](https://polygon.technology/blog/meet-the-polygon-protocol-council), defined in [PIP-29](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-29.md), is a **13-member multisig** implemented as four Gnosis Safe contracts — two on Ethereum and two on Polygon PoS — responsible for narrow, timelock-limited changes to system smart contracts. It has two thresholds:

- **Regular changes: 7 of 13** signers, subject to a **10-day timelock** before execution.
- **Emergency changes: 10 of 13** signers, executable immediately with no timelock.

The higher bar and dropped delay for emergencies trade some deliberation for the ability to patch a live exploit fast; the timelock on ordinary upgrades gives the community a window to react before a change lands. Structuring a small, publicly-named signer set with charter-bound powers is the same "constrain the multisig" pattern that [Safe](/wiki/daos/infrastructure/safe-dao) and ZKsync's security bodies use.

## How Caper relates

Polygon's governance is deliberately heavyweight — a PIP pipeline, a 13-signer council with timelocks, and a treasury board — because it stewards a multi-billion-dollar network where a bad upgrade is catastrophic. That machinery is appropriate at that scale, and it takes years and a foundation to stand up. [Caper](/wiki/foundations/what-is-a-caper) sits at the other end: a token, a treasury, and on-chain governance are created in a **single launch transaction**, so a small group gets working governance on day one instead of bootstrapping councils. The trade Caper makes for that simplicity is to hard-wire a member's protection into the token itself — the [exit right](/blog/the-exit-right). Rather than appointing a council to guard against a bad decision, a holder who disagrees can leave and reclaim a [canonical share of the treasury](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), computed from the same vote weight that governs their say. Big networks need standing bodies; small ones are often better served by a door that is always open.

## Starknet (STRK)

URL: https://caper.network/wiki/daos/networks/starknet
Updated: 2026-07-25

| Type | Ethereum L2 validity (ZK) rollup / network DAO |
| --- | --- |
| Governance token | STRK (governance, staking & gas) |
| Governance mechanism | vSTRK + STRK, delegated voting on Snapshot X |
| Steward | Starknet Foundation (non-profit) |
| Initial supply | 10,000,000,000 STRK (minted Nov 30, 2022; inflates via staking/block rewards) |
| Builder | StarkWare (Cairo, STARK proofs) |
| Website | [starknet.io](https://www.starknet.io) |

## Overview

[Starknet](https://www.starknet.io) is an Ethereum layer-2 built by [StarkWare](https://starkware.co) on validity proofs: transactions are executed off-chain and a [STARK proof](https://docs.starknet.io/learn/protocol/intro) is verified on Ethereum, inheriting L1 security without re-executing every transaction. Contracts are written in [Cairo](https://www.cairo-lang.org), a language purpose-built for provable computation. Protocol stewardship sits with the non-profit [Starknet Foundation](https://www.starknet.io/blog/introducing-the-starknet-foundation/) and, increasingly, with STRK holders voting through the [governance portal](https://governance.starknet.io).

Starknet belongs to the family of L2 _network DAOs_ this wiki tracks — communities that govern a rollup's contracts and treasury through a token — alongside [Arbitrum](/wiki/daos/networks/arbitrum-dao), the [Optimism Collective](/wiki/daos/networks/optimism-collective), [ZKsync](/wiki/daos/networks/zksync-era) and [Polygon](/wiki/daos/networks/polygon). What sets it apart is that STRK is not a pure governance chip: it also pays gas and secures consensus, so the same asset carries three distinct jobs.

## STRK: one token, three jobs

Ten billion STRK were created in May 2022 and minted on-chain on [November 30, 2022](https://docs.starknet.io/learn/protocol/strk); supply inflates over time as the protocol mints staking and block rewards on a community-set schedule. The initial allocation splits across early contributors (20.04%), investors (18.17%), StarkWare (10.76%), grants and development partners (12.93%), community provisions and rebates (9.00% each), and the Foundation's strategic reserves and treasury (10.00% and 8.10%). Investor and early-contributor tranches unlock monthly [through March 2027](https://docs.starknet.io/learn/protocol/strk).

The token does three things. It is the **gas asset** — since [v0.14.0 (Sept 1, 2025)](https://docs.starknet.io/learn/protocol/strk) transaction fees on Starknet are paid only in STRK. It is the **staking asset** that secures sequencing, consensus, proving and data availability. And it is the **governance asset** that weights votes over protocol upgrades. Bundling gas, security and voting into one token is a deliberate contrast with [ZKsync](/wiki/daos/networks/zksync-era), whose ZK token votes but never pays gas.

## Governance: vSTRK, delegation and Snapshot X

To vote with STRK held on Starknet, a holder wraps it 1:1 into **vSTRK**, a token dedicated solely to governance. Voting power is the sum of STRK held on Ethereum L1 and vSTRK held on L2, and — as in most large token-DAOs — that power can be [delegated](/wiki/dao-governance/concepts/voting/voting-and-delegation) to a representative rather than voted directly. Votes run on [Snapshot X](https://governance.starknet.io), the on-chain successor to off-chain Snapshot, so tallies are settled by contract rather than by a signature server.

Starknet's governance opened in [phases](https://www.starknet.io/blog/starknets-governance-first-phase/). In the first phase a professional **Builders' Council**, seated by the Foundation, held 23.3% of voting power as a competence backstop while the broader delegate base matured. The Foundation has since run an application-based, _tiered_ delegate program through the [governance portal](https://governance.starknet.io): it lends STRK voting power to vetted delegates, and delegates who miss participation standards risk having that power reallocated — a design meant to keep delegated weight active rather than dormant, one of the failure modes catalogued in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## Progressive decentralization: staking and consensus

Starknet is decentralizing its stack in numbered stages rather than all at once. **Staking v1/v2** are live, letting STRK holders stake — directly or by delegating to a validator — with a seven-day unstaking delay; validators currently attest to blocks. **Staking v3** (Q4 2025 / Q1 2026) has validators attest _and vote_ on sequenced blocks, and **v4** (2026) is slated to fully decentralize both the sequencer and the prover, per the [2025 roadmap recap](https://www.starknet.io/blog/how-starknets-q3-paved-the-way-for-bitcoin-decentralization-and-the-future-of-crypto/).

On the sequencing side, the **Grinta** release (v0.14.0, Sept 1, 2025) moved Starknet to multiple sequencers running [Tendermint consensus](https://docs.starknet.io/learn/protocol/intro) with a 1/2 threshold — three sequencers operated by StarkWare at launch, with community-run sequencers to follow. Governance and staking are the two levers that hand each of these roles from StarkWare to the token community over time.

## Bitcoin as a second security asset

In 2025 Starknet became the first rollup to run a **dual-token consensus**: alongside STRK, staked Bitcoin can help secure the network, with STRK carrying 75% and BTC 25% of consensus weight (a BTC staking-power weight of 0.25). Within weeks of the [launch](https://www.starknet.io/blog/how-starknets-q3-paved-the-way-for-bitcoin-decentralization-and-the-future-of-crypto/) more than 650 BTC (~$72M) were staked and over 1,000 bridged. Admitting Bitcoin into consensus and validating the bridge design were themselves decided by [on-chain governance votes](https://governance.starknet.io) — a concrete case of the token community, not a core team, setting the rollup's security model.

## How Caper relates

Starknet's answer to the risk that delegated power goes stale is _procedural_: seat a competent council early, then lend voting weight to delegates on the condition that they keep showing up, and claw it back when they don't. It is a good design for keeping a large token-holder base engaged. [Caper](/wiki/foundations/what-is-a-caper) works on a smaller, earlier-stage problem and answers it differently. Instead of curating who holds power, it gives every holder a credible [exit right](/blog/the-exit-right) — the ability to leave on defined terms and reclaim a canonical share of the treasury — so the discipline on a bad decision is that participants can walk with their fair slice, not that an underperforming delegate loses a seat. Both are ways to keep governance honest; one manages representatives, the other keeps the door open.

## ZKsync (ZK & ZK Nation)

URL: https://caper.network/wiki/daos/networks/zksync-era
Updated: 2026-07-31

| Type | Ethereum L2 rollup / network DAO |
| --- | --- |
| Governance token | ZK (governance only — gas is paid in ETH) |
| Governance framework | ZK Nation — three onchain bodies, three governors |
| Onchain governance live | October 2024 |
| Total supply | 21,000,000,000 ZK (fixed) |
| Builder | Matter Labs (ZK Stack / Elastic Network) |
| Website | [zknation.io](https://zknation.io) |

## Overview

[ZKsync](https://zksync.io) is an Ethereum layer-2 built by Matter Labs on validity (ZK) proofs. ZKsync Era went live on mainnet in March 2023, and the stack has since generalised into the [Elastic Network](https://docs.zksync.io/zksync-network) — a set of ZK-powered chains built with the open-source [ZK Stack](https://docs.zksync.io/zk-stack) that settle to the same shared bridge. Its governance sits with **ZK Nation**, the community of [ZK token](https://zksync.io/token) holders and delegates that controls the protocol contracts.

ZK is a pure governance asset: transaction fees on ZKsync are paid in ETH, so ZK's only protocol role is voting weight over upgrades, the token itself, and governance operations. That separation — a governance token that is _not_ the gas token — puts ZKsync alongside other L2 network DAOs the wiki tracks, such as [Arbitrum](/wiki/daos/networks/arbitrum-dao), the [Optimism Collective](/wiki/daos/networks/optimism-collective), [Starknet](/wiki/daos/networks/starknet), and [GnosisDAO](/wiki/daos/networks/gnosisdao).

## The ZK token & distribution

ZK has a fixed supply of **21 billion** tokens, with roughly two-thirds (66.7%) earmarked for the community and the remainder split between investors and the Matter Labs team under a one-year lock followed by a linear unlock from June 2025 to June 2028. The token generation event and initial airdrop landed in June 2024.

The community airdrop distributed **3.675 billion ZK (17.5% of supply)** across **695,232 wallets**, based on a snapshot of ZKsync Era and ZKsync Lite activity taken on 24 March 2024 — about 89% weighted to users who transacted and met an activity threshold, and 11% to ecosystem contributors. Details are set out in Matter Labs' [airdrop announcement](https://web.archive.org/web/20251215233918/https://www.zknation.io/blog/zk-token) (archived; the post has since been removed from zknation.io) and [reported](https://www.coindesk.com/tech/2024/06/11/zksyncs-zk-airdrop-is-coming-next-week-heres-what-to-expect) at the time.

## Three-body governance

ZK Nation's defining feature is a **three-body structure** — a deliberate departure from the single-house token vote used by most protocol DAOs. Each body checks the others ([governance 101](https://docs.zknation.io/voting-and-delegation/zksync-governance-101)):

- **Token Assembly** — ZK holders who delegate voting power to ZKsync addresses. The Assembly submits and votes on proposals to upgrade the protocol, the token, and the governance system itself.
- **Security Council** — 12 technical experts (auditors, security engineers) who are signers of a security multisig. They [review and actively approve](https://docs.zknation.io/zksync-governance-procedures/schedule-3-zksync-security-council) protocol upgrades passed by the Token Assembly and, facing an imminent threat, can freeze the protocol and push time-sensitive fixes.
- **Guardians** — protectors of the ZK Credo, a minimum of 5 of 8 allocated seats, holding **veto power** to block decisions that clash with the ecosystem's stated values.

Splitting proposing power (Assembly), technical safety (Council), and a values veto (Guardians) is a different answer to the [capture and rushed-upgrade risks](/wiki/daos/networks/arbitrum-dao) that a plain token vote carries — closer in spirit to a constitutional separation of powers than to one-token-one-vote.

## Onchain governors & proposal types

The three bodies act through three onchain [governor contracts](https://docs.zknation.io/zksync-governance-procedures/zksync-governance-procedures-overview) on ZKsync Era, each paired with a timelock and each owning one proposal class:

- **Protocol Governor** executes **ZKsync Improvement Proposals (ZIPs)** — upgrades to the protocol contracts.
- **Token Governor** executes **Token Program Proposals (TPPs)** — proposals that assign minting and burning rights over ZK.
- **GovOps Governor** facilitates **Governance Advisory Proposals (GAPs)** — governance and operations decisions.

Standard upgrades follow a set path: Token Assembly approval → Security Council risk review → timelocked execution. Emergency changes route instead through the **Emergency Upgrade Board**, which accepts approvals from all three governance bodies before an expedited upgrade can execute.

## BORGs: smart contracts wrapping legal entities

The Security Council and Guardians are structured as **BORGs** (blockchain organizations) — legal entities whose behaviour is constrained by onchain rules embedded in their charters, so a multisig cannot simply act outside its mandate. It is the same "cybernetic org" pattern that [Safe](/wiki/daos/infrastructure/safe-dao) multisigs and adjacent tooling have popularised, applied here to give a values veto and a security freeze real legal and onchain teeth rather than social convention alone.

## How Caper relates

ZKsync's Guardians are a _backstop against capture_: if a vote drifts from the ecosystem's values, a small values body can veto it. [Caper](/wiki/foundations/what-is-a-caper) answers the same worry from the opposite direction. Rather than appointing guardians to protect a holder who disagrees, it gives that holder the [exit right](/blog/the-exit-right) — the ability to leave on defined terms and reclaim a canonical share of the treasury — so the check on a bad decision is the credible threat of exit, not a standing veto seat. Two honest designs for the same problem: a body that can say no, versus a door that is always open.

## Gitcoin DAO

URL: https://caper.network/wiki/daos/public-goods/gitcoin-dao
Updated: 2026-07-18

|  |  |
| --- | --- |
| **Name** | Gitcoin (Gitcoin DAO) |
| **Type** | [Grants / public-goods-funding DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) |
| **Governance token** | GTC (governance only; non-transferable claim to steward the DAO) |
| **Governance model** | Token-weighted stewardship — GTC holders and delegated _stewards_ steer the treasury and the Grants Program; funding rounds allocate a matching pool by [quadratic funding](/wiki/governance/voting-mechanisms) |
| **Products** | Gitcoin Grants (recurring matching rounds) · **Allo Protocol** (open-source allocation contracts) · Human Passport (Sybil resistance) · Grants Stack _(sunset May 2025)_ |
| **Notable for** | Mainstreaming **quadratic funding** for public goods; routing tens of millions in matching capital to open-source and Ethereum-ecosystem builders |
| **Primary sources** | [gitcoin.co](https://gitcoin.co/), [gov.gitcoin.co](https://gov.gitcoin.co/), [docs.allo.gitcoin.co](https://docs.allo.gitcoin.co/) |
| **Related** | [Optimism Collective](/wiki/daos/networks/optimism-collective), [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos), [Voting mechanisms](/wiki/governance/voting-mechanisms) |

**Gitcoin** is the DAO that did more than any other to turn [quadratic funding](/wiki/governance/voting-mechanisms) from an economics paper into a working way to pay for public goods. Where most of the [protocol DAOs](/wiki/daos/dexs/uniswap-dao) in this directory govern _their own_ product and treasury, Gitcoin's job is to fund _everyone else's_ — the open-source infrastructure, developer tooling, and community work that the wider ecosystem relies on but no single company has an incentive to pay for. It is the canonical example of a [grants DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos), and its funding mechanism is studied and forked far beyond crypto. Gitcoin's own governance runs through the [Gitcoin governance forum](https://gov.gitcoin.co/) and the **GTC** token.

## Quadratic funding: matching what the crowd cares about

Gitcoin's signature mechanism is **quadratic funding (QF)** — the funding cousin of the quadratic _voting_ rule covered in [voting mechanisms](/wiki/governance/voting-mechanisms). A round starts with a **matching pool** put up by sponsors. The crowd then donates directly to the projects they value, and the pool is split so that the _number_ of distinct contributors matters far more than the size of any single cheque: a grant's match grows with the square of the sum of the square-roots of its donations. In plain terms, a project backed by a thousand people giving $1 each is matched far more generously than one backed by a single whale giving $1,000. QF is a formal answer to the classic under-provision of public goods — it lets a small, diffuse crowd out-signal concentrated capital about what deserves funding. Gitcoin describes the mechanism and its Allo implementation in its [Grants Stack & Allo product overview](https://gov.gitcoin.co/t/introducing-gitcoin-grants-stack-allo-protocol-product-overviews-part-1-of-2/12664).

## The Gitcoin Grants Program

The **Gitcoin Grants Program** runs in periodic rounds — the "GG" seasons (GG18, GG19 … GG23 and on) — each pairing a matching pool with themed rounds for open-source software, Ethereum infrastructure, climate, and ecosystem-specific tracks. Across dozens of rounds since 2019 the program has routed **tens of millions of dollars** in matching capital to public-goods builders, making it one of the most consequential funding experiments in the space. Live round details and results are published on [gitcoin.co](https://gitcoin.co/). The program is deliberately opinionated about _what_ it funds: it targets the work that markets systematically under-price, which is exactly where quadratic matching has the most bite.

## Allo Protocol and the 2025 refocus

Under the hood, rounds are settled by **Allo Protocol** — an open-source, modular set of contracts that let any community _pool_ capital and _allocate_ it through a pluggable strategy (quadratic funding, direct grants, or custom rules), with a recipient registry and flexible payout logic. Allo's contracts remain deployed and forkable; the [Allo documentation](https://docs.allo.gitcoin.co/) is the reference. Allo originally powered **Grants Stack**, Gitcoin's hosted Manager / Explorer / Builder apps — but in a candid 2025 decision Gitcoin [announced it would sunset Grants Stack and the Grants Lab business unit by end of May 2025](https://gov.gitcoin.co/t/focusing-gitcoins-future-sunsetting-grants-stack-eol-may-2025/20333), citing a structural gap between the software division's ~$3M annual cost and roughly $1M of revenue. The point of the wind-down was to protect the treasury runway and refocus on the _Grants Program_ itself rather than on maintaining a separate software product — a rare, public example of a DAO cutting a beloved-but-unsustainable line of work to defend its core mission and its [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## GTC and DAO governance

**GTC** is Gitcoin's governance token. It carries no claim on protocol revenue — it exists to distribute stewardship of the DAO and its treasury. In practice much of the day-to-day steering runs through _stewards_: delegates who hold or are delegated GTC and shepherd budgets, workstreams, and the shape of each Grants season through the [governance forum](https://gov.gitcoin.co/) and token votes. That delegation-heavy model is a live example of the [liquid-democracy](/wiki/dao-governance/concepts/voting/voting-and-delegation) pattern — expertise pools into active stewards — with the familiar caveat that voting power can quietly re-concentrate in a handful of large delegates.

## Sybil resistance: the identity problem QF can't dodge

Quadratic funding rewards the _number_ of backers — which makes it a magnet for [Sybil attacks](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos): split one donor into a hundred fake identities and the quadratic match multiplies rather than dilutes. Gitcoin's answer is **Human Passport** (formerly Gitcoin Passport), a stamp-based proof-of-personhood layer that scores how likely an account is to be a unique human before its donation counts toward the match. Later rounds also moved to **connection-oriented cluster matching (COCM)**, which discounts donations from tightly-clustered, collusive-looking groups. The identity layer is not optional bolt-on polish — it is the precondition that makes quadratic funding safe at all, the same lesson quadratic _voting_ runs into on-chain.

## How Caper approaches this

Gitcoin and [Caper](/wiki/foundations/what-is-a-caper) are aimed at the same failure — good work going unfunded — but from opposite ends. Gitcoin pools _external_ sponsor capital and splits it by quadratic match, which forces it to solve identity first: the mechanism only works if it can tell one human from a hundred wallets. Caper skips that problem rather than solving it. A caper raises its _own_ capital directly, through a bonding curve into a shared [treasury](/wiki/governance/execution), and members then allocate that treasury through governance-approved payout and investment [proposals](/wiki/governance/proposals). Because [voting weight](/wiki/governance/voting) is earned from stake _and_ participation — not from the count of accounts — splitting yourself across wallets buys nothing, so no separate proof-of-personhood layer is needed. And the same earned weight fixes each member's pro-rata claim on the treasury at [exit](/wiki/governance/execution), so the people directing where money goes are the ones whose own exit value moves with the result. It is a narrower tool than a public-goods matching round — one organization funding its own mandate rather than an ecosystem-wide commons — but it removes the Sybil surface that quadratic funding has to spend so much effort defending.

## References

- [Gitcoin — Fund What Matters](https://gitcoin.co/) — the Grants Program and live rounds.
- [Gitcoin governance forum](https://gov.gitcoin.co/) — GTC governance, stewards, and workstream budgets.
- [Introducing Grants Stack & Allo Protocol](https://gov.gitcoin.co/t/introducing-gitcoin-grants-stack-allo-protocol-product-overviews-part-1-of-2/12664) — product overview and the quadratic-funding design.
- [Focusing Gitcoin's Future: Sunsetting Grants Stack (EoL May 2025)](https://gov.gitcoin.co/t/focusing-gitcoins-future-sunsetting-grants-stack-eol-may-2025/20333) — the 2025 refocus decision and its financials.
- [Allo Protocol documentation](https://docs.allo.gitcoin.co/) — the open-source allocation contracts.

## Giveth (GIV)

URL: https://caper.network/wiki/daos/public-goods/giveth
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Name** | Giveth (GIV) |
| **Type** | [Public-goods / donation-platform DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) |
| **Founded** | Second half of 2016, by Griff Green, Jordi Baylina and other members of the Ethereum White Hat Group ([Giveth history](https://github.com/Giveth/giveth-docs/blob/HEAD/whatisgiveth/history.md)); the [Giveth GitHub organisation](https://github.com/Giveth) dates from 15 November 2016 |
| **Tokens** | **GIV** (1bn minted, ERC-20) · **gGIV** (wrapped GIV, used in the GIVgarden) · **rGIV** (non-financial reputation token) |
| **Governance** | Three venues: [conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) in the GIVgarden (1hive Gardens on Gnosis Chain) · rGIV reputation voting on an Aragon deployment · GIV/GIVpower token voting on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (`giv.eth`) |
| **Products** | giveth.io donation platform (zero platform fee) · GIVbacks donor rewards · GIVpower project curation · [quadratic-funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) rounds · DeVouch attestations |
| **Chains** | Ethereum mainnet, Gnosis Chain, Optimism, Polygon (the [GIVbacks-eligible set](https://docs.giveth.io/givethmatchingpool)) |
| **Notable for** | The MiniMe token contract; the July 2017 Parity multisig white-hat rescue; running the OSS quadratic-funding rounds for [Gitcoin](/wiki/daos/public-goods/gitcoin-dao)'s GG24 |
| **Status** | 🟢 Active — most recent Snapshot proposal opened 29 July 2026 (checked 2 August 2026) |

**Giveth** is a donation platform and a DAO built around one deliberately awkward economic idea: that the person who _gives_ money away should be rewarded for it. Where [Gitcoin](/wiki/daos/public-goods/gitcoin-dao) concentrates on allocating a matching pool well and [Protocol Guild](/wiki/daos/public-goods/protocol-guild) on paying a fixed set of maintainers, Giveth takes the demand side: it charges no platform fee on donations, then pays donors back in its own token, and lets token holders stake to decide which projects that reward flows to most generously. The result is a public-goods DAO whose governance surface is unusually wide — three separate voting venues, a working-group budget cycle, and an attestation layer — and one of the longest continuously-running organisations in the sector, with an origin story that predates the word "DAO" being used the way it is now.

## From the White Hat Group to a donation platform

Giveth was founded in the second half of 2016 by **Griff Green**, **Jordi Baylina** and other members of the Ethereum White Hat Group — the same people who had just spent the summer working through the fallout of The DAO. Their first output was infrastructure rather than a product: the [MiniMe token](https://medium.com/giveth/the-minime-token-open-sourced-by-giveth-2710c0210787) contract, a [Vault](https://medium.com/giveth/the-vault-contract-open-sourced-by-giveth-fe2261f7b91b) contract, and a [MilestoneTracker](https://github.com/Giveth/milestonetracker), all open-sourced ([Giveth history](https://github.com/Giveth/giveth-docs/blob/HEAD/whatisgiveth/history.md)). MiniMe — an ERC-20 that keeps a historical record of every holder's balance, so a snapshot at any past block can be read on demand — became a standard building block for token voting across the ecosystem.

The group's most-cited moment came on **19 July 2017**, during the Parity multisig incident. By Giveth's own account, its developers used the same vulnerability an attacker was exploiting to drain 500 at-risk wallets into a secure account before the attacker could reach them, rescuing 47,000 ETH in the first pass and over **$208 million** of crypto in total, then rebuilt secure wallets and returned the funds to their owners by 31 July, declining donations for the work. The same year the team declared itself a _Decentralized Altruistic Community_ and reorganised on [holacratic](https://www.holacracy.org/) lines — circles, weekly governance meetings — a structure that survives today as the DAO's Working Groups and Chapters.

The consumer product arrived in two waves. The original 2017 DApp eventually shipped as **Giveth TRACE** in July 2021; a rewritten platform launched as **Giveth.io** in March 2021 with peer-to-peer donations on mainnet and xDai (now Gnosis Chain). The token economy — announced by Green at The DAOist in Paris that July — followed as the **GIVeconomy**.

## The GIVeconomy: GIV, GIVstream and GIVbacks

**1 billion GIV** were minted at the launch of the GIVeconomy. Only **100 million** were liquid immediately; the remaining **900 million** were committed to the **GIVstream**, a continuous release running until **23 December 2026** ([GIVeconomy docs](https://docs.giveth.io/giveconomy)). Anyone who claims GIV from any part of the economy also opens a stream of further GIV that drips out over the remaining term — a vesting design that ties reward size to how early you participated rather than to a cliff schedule, and one that is now within months of fully unlocking.

**GIVbacks** is the demand-side mechanism. Donate at least **$5** in an eligible token to a _verified_ project and Giveth returns **50% to 80% of the USD value of the donation** in GIV, with the exact percentage set by the receiving project's GIVpower rank. Rounds last two weeks and each round has **1 million GIV** available; if donations exceed that budget, every donor is scaled down proportionally rather than the round closing early ([GIVbacks docs](https://docs.giveth.io/givbacks)). Giveth itself takes **no platform fee** on donations, so GIVbacks is the platform's entire economic pitch to a donor: give, and get a claim on the platform's governance back.

## GIVpower: paying people to curate

The supply-side counterpart is **GIVpower**, and it is the part of Giveth most worth studying as a governance mechanism. Staking GIV in the GIVfarm mints GIVpower **1:1**. Stakers may then lock for between **1 and 26 rounds** of two weeks each — up to a year — and locking multiplies both the staking APR and the GIVpower by `√(1 + N)`, where _N_ is the number of rounds locked. Ten rounds gives a multiplier of about **3.32**; the maximum 26-round lock gives about **5.20** ([GIVpower docs](https://docs.giveth.io/givpower)).

That is a square-root time-lock curve, and the contrast with the linear-decay curve of [vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) is the interesting part: a square root pays most of its bonus in the first few rounds and flattens after, so it buys commitment without making the longest lock overwhelmingly dominant. Holders spend GIVpower by **boosting** up to **20 projects** at a time. Ranks are recomputed each GIVbacks round from the _average_ GIVpower behind a project across the previous round, and the rank sets the donor reward: the top-ranked project yields up to **80% GIVbacks**, an unranked verified project **50%**.

So GIVpower is a [curation market](/wiki/economics/curation-markets) in which the curated good is a discount on somebody else's donation. It gives stakers a reason to research projects that has nothing to do with a proposal vote, which is a rare answer to [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy): the work is continuous, the reward is continuous, and no ballot has to be scheduled for any of it to happen.

## Three governance venues, one DAO

Giveth splits decisions across three systems rather than routing everything through one contract ([governance process](https://docs.giveth.io/governanceprocess)).

**The GIVgarden** runs on [conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) via 1hive's **Gardens** framework on Gnosis Chain, and is where treasury requests land. Members wrap GIV into **gGIV** and stake it behind proposals; conviction accrues the longer a stake sits. Its published parameters are a **30-day** conviction growth, a **2.50%** spending limit per proposal, **5%** minimum conviction, a **5,000 GIV** action deposit and a **10,000 GIV** challenge deposit, with a **7-day** settlement period. Non-financial questions use **Tao voting** — binary, delegable, with quiet-ending protection against last-minute flips — at **90%** support required. Challenged proposals escalate to **Celeste**, a decentralised court, as the final backstop ([GIVgarden docs](https://docs.giveth.io/givgarden)).

**rGIV** is a non-financial reputation token held by DAO members, voted on an Aragon deployment with plain yes/no mechanics and a five-day window. Only rGIV holders may propose or vote there, which keeps operational decisions inside the contributor body rather than the token market. That venue looks dormant in practice: the client URL the governance docs publish for it, `optimism.aragon.blossom.software`, returns NXDOMAIN as of 2 August 2026, so the live governance load is carried by the GIVgarden and Snapshot.

**Snapshot** carries community-wide signalling and budget ratification in the `giv.eth` space, where GIV held _and_ GIV staked in GIVpower both count toward voting power. As of 2 August 2026 the space has run **73 proposals** for **315 followers**, with a five-day voting period ([snapshot.org/#/giv.eth](https://snapshot.org/#/giv.eth)). Two things stand out in the live data. First, a documentation gap: the governance docs state the quorum is **1 million GIV**, while the space's own Snapshot configuration returns a default quorum of **10 million** — a tenfold difference between what the docs tell a prospective voter and what the voting client enforces. Second, turnout: recent proposals close with roughly **10 to 29 voting addresses** apiece, including a July 2026 request for 8.5M GIV to extend GIVpower rewards to February 2027 that drew ten. Voting _power_ is in the hundreds of millions and quorum is never the binding constraint; the number of distinct humans is. That is the same concentration pattern documented across [token-weighted DAOs](/wiki/dao-governance/concepts/voting/token-weighted-voting), and it holds even where the token is explicitly earned by giving money away.

## Working Groups, Seasons and the Advice Process

Operationally the DAO is split into **Working Groups** — currently Dapp, GIVeconomy, DAO Ops, Quadratic Funding and Fundraising — each owning its own budget, goals and contributors, plus skill-based **Chapters** (Development, Design, Comms & Marketing, Product, devOps) that cut across them and hold no budget of their own ([DAO structure](https://docs.giveth.io/daostructure)). Working Groups run in **Seasons** of three or six months; at each boundary a lead posts what the group achieved and what it plans next, with goals framed at three ambition levels — **SHRINK, SUSTAIN and GROW** — and GIV holders vote on which groups to fund. It is a clean, legible instance of the [working-group](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups) pattern, and the three-scope framing is a neat trick for budget votes: the electorate picks an ambition level rather than haggling over a single number.

Before anything reaches a vote it must clear the **Advice Process**: every legitimate proposal starts on the [Giveth forum](https://forum.giveth.io/) and must sit open for feedback for a **minimum of five days**. A proposal may shorten or skip that window in a financial emergency, but only with a written disclaimer explaining why — and the docs warn plainly that doing so lowers its chance of passing. Conduct is governed by a signed **Community Covenant**, which is also the reference document Celeste rules against when a GIVgarden proposal is challenged.

## Quadratic funding, and running GG24's OSS rounds

Giveth has run [quadratic-funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) rounds on its own platform since 2023, matching donations to verified projects out of a pool held by the `donation.eth` multisig, a **7-of-15** signer set managed by core contributors ([matching-pool docs](https://docs.giveth.io/givethmatchingpool)). Matching-fund distributions are ratified on Snapshot after the fact rather than executed automatically, which puts a human ratification step between the QF calculation and the payout.

In October 2025 Giveth operated the **open-source software rounds of Gitcoin's GG24** — the first round of "Gitcoin 3.0", which spread roughly $1.8M across six domains using six different allocation mechanisms at once. Giveth ran two of them (Developer Tooling & Infrastructure, and Interop Standards, Infra & Analytics) against a **$300,000** matching pool, drawing **$36,657** in crowdfunding from **1,286 unique donors** across **3,042 donations** ([GG24 OSS QF retrospective](https://gov.gitcoin.co/t/gg24-oss-qf-on-giveth-retrospective/24890)). The grantee count depends which Gitcoin document you read: the [results thread](https://gov.gitcoin.co/t/gg24-oss-quadratic-funding-results/24782) lists **55** projects in the tooling round and **23** in the interop round — 78 in total — while the retrospective counts **64** funded projects. Every other figure agrees exactly across the two: $29,739 + $6,918 in donations, 2,361 + 681 individual donations, and 200,000 + 100,000 USDC of matching.

The retrospective is candid about what those numbers mean. The crowdfunding-to-matching ratio came in at **12.22%**, below GG23's 15.88% and GG22's 19.43% — every dollar of matching pulled in fewer donor dollars than the round before. Donor _count_ beat three comparable 2025 Giveth rounds, but donations per donor fell to 2.36, and the round's much tighter eligibility (64 projects, against 235–496 historically) is named as a cause alongside a general slowdown in public-goods funding. That slowdown is the same one visible in the [pause of Optimism's Retro Funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) in January 2026, and it is the backdrop against which every funder in this section is now operating.

## DeVouch: attestations as a legitimacy layer

**DeVouch** is Giveth's answer to the question every grants platform eventually hits — not "is this donor a real person" but "is this project what it claims to be". It is built on the [Ethereum Attestation Service](https://attest.org/): recognised _Attester Groups_, defined as sets of addresses holding the same attestation from the same issuing authority, publish **vouches** and **flags** against projects, and DeVouch indexes those signals across [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), Giveth and [Optimism](/wiki/daos/networks/optimism-collective) Retro Funding in one place ([DeVouch docs](https://docs.giveth.io/devouch/what-is-devouch)). Anyone may attest, but only groups on the indexed list are surfaced — Optimism's RetroPGF badgeholder schema is the worked example, and new groups are added through the public repository.

It is a deliberately different shape from the identity-side approaches catalogued under [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos): rather than scoring the wallet that donates, DeVouch scores the grantee, and it does so with reusable, portable, public attestations instead of a platform-private review queue. For a funder deciding whether a project deserves a matching multiplier, that is the cheaper half of the problem to attack.

## Published as machine-readable grant data

Giveth is one of the few grant programmes whose rounds are published in a standard machine-readable shape rather than only as a website. It is one of three systems carried by [DAOstar](/wiki/dao-governance/tooling/analytics/daostar)'s OpenGrants gateway, which aggregates grant programmes under the [DAOIP-5](https://github.com/metagov/daostar/blob/main/DAOIPs/daoip-5.md) grants-management schema alongside Octant and the Stellar Community Fund. Read from [the public gateway API](https://grants.daostar.org/api/v1/grantPools?system=giveth) on **9 August 2026**, Giveth publishes **10 grant pools** – among them Giving Season, Meta Pool APAC and a $250,000 Buidl on Polygon round – each carrying its funding size in a structured `totalGrantPoolSize` field, plus an `io.giveth.systemMetadata` extension for the fields the schema does not cover. That is what makes a Giveth round directly comparable with an [SCF or Octant round](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) without scraping either, and it is the practical payoff of a funder doing the unglamorous work of publishing to someone else's schema.

## Where Giveth sits

Among the public-goods funders in this directory, Giveth occupies the retail-donor end. [Gitcoin](/wiki/daos/public-goods/gitcoin-dao) is a mechanism laboratory that allocates matching pools; [Protocol Guild](/wiki/daos/public-goods/protocol-guild) is a time-weighted split contract for a known set of maintainers; [MolochDAO](/wiki/daos/public-goods/molochdao) is a small, ragequit-protected grant committee. Giveth is the one trying to make the _ordinary donation_ economically attractive, and to fund itself by governing who benefits from that subsidy.

The design deserves its scrutiny in both directions. It is a genuine experiment in paying for attention to public goods continuously rather than in scheduled votes, and GIVpower is one of the better-specified curation mechanisms running in production. But the honest reading of its own numbers is that it has not escaped the pattern: participation concentrates, turnout is a handful of addresses, and the GIVstream that funded the whole reward economy runs out in December 2026. What Giveth does next — with the stream exhausted and the crowdfunding ratio falling across the sector — is the more informative thing to watch than anything in its documentation.

## MolochDAO

URL: https://caper.network/wiki/daos/public-goods/molochdao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | MolochDAO |
| **Type** | Minimalist public-goods grants DAO (Ethereum) |
| **Launched** | 2019 |
| **Funds** | Ethereum public goods — core infrastructure & Eth2 development grants |
| **Signature mechanism** | [Ragequit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — burn shares for a pro-rata slice of the guild bank |
| **Membership** | Shares (vote + economic) and loot (economic only), via tribute proposals |
| **Legacy** | [Moloch framework](https://github.com/MolochVentures/moloch) → MetaCartel Ventures, The LAO, RaidGuild; [DAOhaus](https://daohaus.club) |
| **Name** | After "Moloch," the personification of coordination failure ([Meditations on Moloch](https://slatestarcodex.com/2014/07/30/meditations-on-moloch/)) |
| **Source** | [MolochVentures/moloch](https://github.com/MolochVentures/moloch) · [whitepaper](https://github.com/MolochVentures/Whitepaper) |

**MolochDAO** is the minimalist Ethereum grants [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), launched in 2019, whose few-hundred-line contracts and signature **ragequit** exit became the design ancestor of a whole generation of DAOs. Where [The DAO](/wiki/dao-governance/concepts/fundamentals/history-of-daos) of 2016 was large, complex, and catastrophic, Moloch was deliberately the opposite: a "minimum viable DAO" that funds [Ethereum public goods](https://github.com/MolochVentures/moloch) and gives any member a clean way out. Its contracts were forked into [investment, service, and grant DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos) across the industry.

## A minimum-viable DAO

Moloch was conceived to fund the coordination that markets underprovide — Ethereum core infrastructure and, at the time, Eth2 development — and to do it with as little contract surface as possible. Membership and grants run through **tribute proposals**: an applicant offers tokens (or a grantee requests treasury funds) and existing members vote to admit or fund them, with new members receiving _shares_ that confer both voting and economic rights. All assets sit in a shared **guild bank** ledger. The whole design was small enough to audit by reading it — a direct reaction to the sprawling, exploitable complexity that had sunk The DAO. [The Moloch whitepaper](https://github.com/MolochVentures/Whitepaper) framed the mission as defeating the coordination failures starving Ethereum public goods.

## Ragequit: the exit primitive

Moloch's lasting contribution is **ragequit**, the original DAO [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). Membership is split into _shares_ (voting + economic) and _loot_ (economic only, no vote). Every passed proposal enters a **grace period** before it can be processed, and during that window any member can ragequit: [the contract burns their shares and loot and atomically transfers them a pro-rata portion of every token in the guild bank](https://github.com/MolochVentures/moloch). Because the exit is available after a vote passes but before it executes, a member who dislikes an outcome can leave with their share rather than fund a decision they opposed — a structural cap on [majority capture](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) of shared funds. A later _guild kick_ lets members convert a bad actor's shares to non-voting loot and force a ragekick.

## The name and the thesis

The DAO takes its name from **Moloch**, the ancient deity later reimagined — via Allen Ginsberg's _Howl_ and Scott Alexander's essay ["Meditations on Moloch"](https://slatestarcodex.com/2014/07/30/meditations-on-moloch/) — as the personification of _coordination failure_: the god to whom rational actors sacrifice a shared good because no one can unilaterally stop the race to the bottom. Public-goods funding is the archetypal Molochian trap — everyone benefits from Ethereum infrastructure, so everyone waits for someone else to pay. MolochDAO's wager was that a small pool with a credible exit could get members to commit funds anyway, precisely because ragequit meant no one was ever locked in.

## The Moloch family

Moloch's real footprint is its descendants. The v2 standard — [designed collaboratively with MetaCartel and ConsenSys's The LAO](https://github.com/MolochVentures/moloch) — extended the framework from single-token grants to holding and investing an arbitrary portfolio, powering the first [venture DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos): **MetaCartel Ventures** (the first v2 deployment) and [**The LAO**](/wiki/daos/investment/the-lao), a legally-wrapped, for-profit investment DAO. Service collectives like [RaidGuild](https://www.raidguild.org) run on the same contracts, and [DAOhaus](https://daohaus.club) turned "summoning" a Moloch DAO into a no-code app, later shipping Moloch v3 ("Baal"). The through-line in all of them is the ragequit guarantee Moloch established: pooled capital plus a credible, individual exit.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) is a direct descendant of Moloch's core instinct — a member should never be captive — but it recouples the exit to demonstrated participation. In Moloch, ragequit is gated to the grace period after a specific proposal passes, and both votes and the ragequit share track flat 1:1 shares. In a caper, the treasury [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is _always_ available — any member, any time, no proposal window to wait for — and, verified in the contract, both a member's [voting weight](/wiki/governance/voting) and their exit share scale with the same metric: stake weighted by participation, not stake alone. So Moloch's "never locked in" guarantee is preserved, while the passive whale who never shows up carries less weight and claims a smaller slice than the member who actually governs.

## Protocol Guild

URL: https://caper.network/wiki/daos/public-goods/protocol-guild
Updated: 2026-08-03

| Protocol Guild |  |
| --- | --- |
| Type | Collective funding mechanism for Ethereum L1 R&D maintainers |
| Launched | 2022 (pilot); Cayman Islands entity incorporated 2024 |
| Token | **None.** No governance token, no supply, nothing to buy |
| Members | 184 at end of 2025 (186 at start; 43 added, 45 removed) |
| Allocation | Time weight: `SQRT((start_date − months_inactive) × full_or_part_time)` |
| All-time inflows | $183m, valued at time of donation (through 2025) |
| 2025 distributions | $12.4m to members; median $62k per member over 12 months |
| Primary funding | The 1% Pledge — projects donate 1% of native token supply (~83% of all funding) |
| Governance | [Agora](https://www.agora.xyz/) DAO (mainnet), migrated Q4 2025 from Moloch V3 |
| Contracts | [Splits](https://splits.org/) immutable 4-year vesting → pass-through wallet → Split v2.1 |
| Docs | [protocol-guild.readthedocs.io](https://protocol-guild.readthedocs.io/en/latest/index.html) |

**Protocol Guild** is a collective funding mechanism for the people who maintain Ethereum's base layer. It describes itself as [three components](https://protocol-guild.readthedocs.io/en/latest/index.html): an eligibility framework, a member registry, and a set of onchain donation contracts, designed so that "Ethereum's layer 1 R&D to be funded in the same way it is produced: a commons of peers and their collaborative effort over time."

It earns a place in this directory by being the structural opposite of almost everything else in it. Protocol Guild has **no token**. There is no supply to distribute, no market to price it, no holders to court, and no [token-weighted vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) to win. It has ~184 beneficiaries and $183m of lifetime inflows, and the beneficiaries _cannot vote on the money_. That last point is not an oversight. It is the design.

## The money is deliberately ungovernable

Every DAO treasury in this wiki shares a property so basic it usually goes unnamed: a vote can move the funds. That is what a treasury _is_ — a pot, and a process for deciding where it goes. Nearly every failure catalogued in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) is downstream of it. If a vote can move the pot, then capturing the vote captures the pot, and everyone who might want the pot has a reason to try.

Protocol Guild removes the pot. Donations go to an [immutable vesting contract](https://explorer.splits.org/accounts/0x25941dc771bb64514fc8abbce970307fb9d477e9/) that releases funds linearly, block by block, over four years. The docs are unusually blunt about what that word means ([onchain architecture](https://protocol-guild.readthedocs.io/en/latest/02-onchain-architecture.html)):

> Here, "irrevocably" means donations cannot be stopped or otherwise redirected during the vest by anyone, be it the donor or Protocol Guild membership.

The membership page states the limit again from the members' side ([membership](https://protocol-guild.readthedocs.io/en/latest/01-membership.html)):

> Governance does not include any control over any vesting funds. e.g. members can't vote to cancel or change the timeline of vesting funds

So the members govern the mechanism — who is eligible, which contracts to use, how long vests should be, where to fundraise, what cut the legal entity takes — but they cannot govern the money already in flight. A donor cannot claw it back. A member majority cannot redirect it. There is no proposal that reaches it. What the members can do is decide _who is on the list_, and a formula does the rest.

## Time weight: a formula instead of a vote

Each member's share of the Split contract is computed, not negotiated ([time weight](https://protocol-guild.readthedocs.io/en/latest/01-membership.html#time-weight)):

```
time_weight = SQRT((start_date − months_inactive) × full_or_part_time)
split_share = (time_weight / total_time_weights) × 100
```

The inputs are all facts about contribution, and none of them are money:

- **`start_date`** — when the member began contributing to Ethereum L1 R&D. Earlier means a larger share; the mechanism pays retroactively for history it did not fund at the time.
- **`months_inactive`** — tracked breaks. Existing members may take up to 3 months off without triggering a membership change.
- **`full_or_part_time`** — 1.0x for full-time (at least 40 hr/wk), 0.5x for partial (20–40 hr/wk). There is no third tier.
- **`SQRT`** — compresses the range, "to not overly privilege long-term members over newer contributors." The same square-root instinct that drives [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding), applied to tenure rather than to donor counts.

Weights are republished onchain each quarter. The effect the docs highlight is that the formula dilutes its own incumbents: "Existing contributor weights get 'diluted' as newcomers show up." Adding a member costs every current member a slice of every future distribution — which is exactly the incentive the Guild wants its curators to feel, because the curators _are_ the members.

## Self-curation, and why the curators are the beneficiaries

Protocol Guild calls this **self-curation**: the membership selects its own beneficiary set. There is no grants council, no badgeholder cohort, no external reviewers — the structure that [retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) depends on and that [Optimism](/wiki/daos/networks/optimism-collective) paused in January 2026. The docs defend the choice on four grounds, and the fourth is the sharpest:

> It is incentive compatible that curators (Guild members) are drawn from the beneficiaries (Guild members). Adding beneficiaries removes future vested value from existing members. They will more carefully consider potential members and their contributions. An external council would not feel this constraint so directly.

They also argue that an external council is a capture surface of its own — "In the worst case, their goal is to maintain their position as curators - not to accurately curate the membership" — and that a curating body would need its own nomination and removal machinery, "more time, overhead, and bandwidth taken from the actual work of core protocol stewardship."

The counterweight against a self-dealing cartel is stated as an obligation rather than a hope: "The mechanism must accept all legitimate contributors... This prevents the set from ossifying or getting captured." The enforcement is social and procedural, not cryptographic. Additions and removals are [pull requests](https://github.com/protocolguild/documentation) against a public repo, open at least a week, merged on rough consensus. Removals are supposed to be self-removals. Peer removal exists for members who stop contributing and go unresponsive — and the docs note that **to date it has never been used**.

Eligibility is narrow on purpose: continuous contribution for at least 6 months before inclusion, open source under an [OSI-approved license](https://opensource.org/licenses), a regular presence in R&D venues like [ethresear.ch](https://ethresear.ch) and AllCoreDevs. The frame the docs offer is "strictly necessary and existential software required to produce blocks and advance the chain" — which is why MEV-Boost and light clients are excluded.

## Funding: the 1% Pledge

The ask is a social norm rather than a protocol rule: projects built on Ethereum donate **1% of their native token supply** to Protocol Guild, vesting over four years. Per the [2025 annual report](https://www.protocolguild.org/blog/20260129-annual-report-2025), pledge projects "account for roughly 83% of PG's total funding to date" — 16 named signatories through 2025, including [EigenLayer](/wiki/daos/staking/eigenlayer), Ether.fi, Taiko, Puffer, PWN DAO, EthStorage, INTMAX, Shape, Yodl and Ascend.

The 2025 numbers, from the Guild's own reporting:

- **All-time inflows: $183m** valued at time of donation, of which **$7.2m** arrived during 2025.
- **Outflows: $12.4m** distributed to maintainers in 2025, up from $10m in 2024. **Median $62k per member** over the trailing 12 months.
- **309,183 donations from 6,202 unique donors** in 2025. Average donation $23; _median donation $0.01_ — "we received tens of thousands of micro donations on L2s." A single donation accounted for $4,047,396 of the year's $7.2m.
- Top 2025 donors: Puffer, Starknet, Optimism RPGF, EnterDAO and LayerZero.

The gap between $183m of inflows and $12.4m of annual outflows is the four-year vest doing its job: the mechanism converts lumpy, sentiment-driven token donations into a slow, predictable stream, and no one — donor or member — can accelerate or reverse it.

## Where governance does live

Protocol Guild is not ungoverned; its governance is fenced. The mainnet Split contract doubles as the membership registry, and a DAO ratifies changes to it quarterly. That DAO [migrated in Q4 2025](https://www.protocolguild.org/blog/20260129-annual-report-2025) from a [Moloch V3](/wiki/daos/public-goods/molochdao) deployment (via [DAOhaus](/wiki/dao-governance/tooling/frameworks/daohaus)) to [Agora](/wiki/dao-governance/tooling/voting/agora), which also took over ownership of the Split contracts from the Guild's [6/10 Safe multisigs](/wiki/dao-governance/tooling/treasury/safe) — the report names "reducing multisig dependencies" as a key 2025 goal.

The two proposal types are calibrated to their stakes ([architecture docs](https://protocol-guild.readthedocs.io/en/latest/02-onchain-architecture.html)):

- **Split updates** — member additions, removals, weight changes — run quarterly and need a simple majority plus **33% quorum**, with a 7-day voting period and 2-day grace period.
- **Split distributions** — pushing already-vested funds out to members — run weekly as "scoped proposals" requiring a simple majority and **no quorum**.

The asymmetry is the tell. Changing who gets paid is a real decision with a real quorum. Paying out is a formality, so it is built to be unblockable — no quorum means no-shows cannot strand a distribution, the [phantom-quorum failure](/wiki/dao-governance/concepts/analysis/how-daos-fail) that jams so many token DAOs. Multisig signers are not disclosed publicly and are rotated regularly.

The [Cayman entity](https://protocol-guild.readthedocs.io/en/latest/04-entity-%26-operations.html) takes **10% of vested funds** to cover legal and operating costs, swapping to stablecoins monthly against a $200k operating reserve and a $100k claims reserve, plus two operations contributors at $12.5k and $10.5k per month. It "aims to receive sufficient funding to cover the above, but not accumulate beyond that" — and the membership sets the percentage, which is precisely the kind of decision that _is_ inside governance scope.

## Live tensions

Two things worth watching, both from the Guild's own 2025 report rather than from critics:

**Membership shrank for the first time.** 186 members at the start of 2025, 184 at the end — 43 added against 45 removed. The report calls this "the first year that Protocol Guild's membership has decreased since its inception," and expects the number to stay "relatively stable around this level." For a mechanism whose legitimacy rests on the registry tracking reality, a decline is evidence the curation is honest, not evidence of decay. But it also means the denominator of a formula that dilutes incumbents has stopped growing.

**Time-weighting itself is under review.** The ops team "invested substantial effort into exploring different funding distribution methods other than the current time weighting mechanism," culminating in a **team impact ranking** draft proposal "focused on output and performance over pure tenure/time-weighting." Members at Berlinterop discussed "introducing impact weighting, as well as capping team weights and the number of client slots."

That is the load-bearing question for the whole design. Tenure is objective, cheap to verify, and nearly impossible to game — which is why it can be a formula and therefore why it needs no vote. Impact is what everyone actually wants to pay for, and it is subjective, contestable, and needs a judge. Adopting impact weighting would import exactly the discretionary decision-making that the current mechanism exists to avoid, and the argument for self-curation ("local actors have the most domain knowledge") is also the argument that these particular people could survive it. It is unresolved.

## How Caper approaches this

Protocol Guild and [Caper](/wiki/foundations/what-is-a-caper) answer the same question — how do you stop a treasury from becoming something to fight over? — and they answer it from opposite ends.

Protocol Guild's answer is to make the money unreachable by any vote. It works, and it is the cleanest answer in this wiki. It also only works because of what Protocol Guild is: a funding conduit with no other purpose. There are no decisions to make, so nothing is lost by making decisions impossible. Nobody needs to vote on _what to build_, because the members are already building it somewhere else and are paid from elsewhere too.

A caper cannot take that route, because a caper is a group that has to actually decide things — fund this, invest in that. Its treasury has to be reachable by [proposals](/wiki/governance/proposals), so the fight is live in a way the Guild's never is. Caper's answer is not to remove the vote but to remove the trap: `exit` is a [public method](/wiki/governance/execution) on the contract, so a member who dislikes where the treasury is going leaves with their share without needing anyone's permission — the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) as a contract function rather than a governance grant.

The two designs rhyme on one point. Both refuse to let a claim be bought. Protocol Guild's share is a function of contributed time and nothing else — no amount of money buys a larger `time_weight`. Caper's exit share is the same number as its vote weight, `(t · v) / (V · T)`, and `v` is a [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) proof-of-vote token: it is minted only by voting and cannot be transferred, so a member who never participates has `v = 0` and the formula returns zero regardless of holdings. (Verified against the contract source, `contracts/logic/src/lib.rs`.)

**Two honest qualifications.** First, Caper's weight is not purely earned: `t` — tokens held — is a multiplicative factor, so capital still counts, and a caper's claim is a blend of stake and participation in a way a Guild member's is not. Protocol Guild's allocation is the more radical of the two: it contains no capital term at all. Second, the Guild does not need an exit right because it has no shared pot to be trapped in — each member's claim vests to their own address on a schedule nobody can alter. Caper's exit is doing work that Protocol Guild's architecture makes unnecessary. That is a point for the Guild, within its narrow scope.

The transferable lesson runs the other way, toward every DAO that is neither: if your treasury _must_ be governable, then the question the Guild sidesteps is one you have to answer — what happens to the member who loses the vote?

## See also

- [DAO contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — the broader problem of paying people who build a commons
- [Retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) — the external-curation model Protocol Guild explicitly rejects
- [Gitcoin DAO](/wiki/daos/public-goods/gitcoin-dao) and [the Optimism Collective](/wiki/daos/networks/optimism-collective) — the two largest funders that chose councils and rounds instead
- [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) — what treasuries do when a vote _can_ reach them
- [Rage quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — the alternative answer to the same question
- [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) — the failure catalogue this design is built against

## References

- [Protocol Guild documentation](https://protocol-guild.readthedocs.io/en/latest/index.html) — the primary source for the eligibility framework, registry and contracts
- [1. Membership](https://protocol-guild.readthedocs.io/en/latest/01-membership.html) — eligibility, self-curation, time weight, governance scope
- [2. Smart Contract Architecture](https://protocol-guild.readthedocs.io/en/latest/02-onchain-architecture.html) — vesting, pass-through wallet, Split v2.1, DAO, multisigs
- [3. Donate](https://protocol-guild.readthedocs.io/en/latest/03-donate.html) — the 1% Pledge and vesting options
- [4. Entity & Operations](https://protocol-guild.readthedocs.io/en/latest/04-entity-%26-operations.html) — Cayman entity, the 10% cut, reserves
- [Protocol Guild Annual Report 2025](https://www.protocolguild.org/blog/20260129-annual-report-2025) (29 Jan 2026) — inflows, outflows, membership changes, Agora migration
- [Protocol Guild Annual Report 2024](https://www.protocolguild.org/blog/20250205-annual-report-2024) (5 Feb 2025)
- [The Protocol Guild Pledge](https://www.protocolguild.org/blog/20240130-protocol-guild-pledge) (30 Jan 2024)
- [Splits: Protocol Guild funds Ethereum core developers using Splits](https://splits.org/blog/protocol-guild/)
- [Protocol Guild Dune dashboard](https://dune.com/protocolguild/protocol-guild) — live donation and distribution data

## $CAR (SHL0MS)

URL: https://caper.network/wiki/daos/social/shl0ms-car
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Artist** | SHL0MS (pseudonymous) |
| **Type** | Conceptual crypto-art project · collective NFT auction (2022) |
| **Object** | 2015 Lamborghini Huracán (bought for just under $250,000) |
| **Detonated** | 2 February 2022, an undisclosed U.S. desert |
| **Supply** | 999 fragment NFTs — 888 sold at public auction, 111 held back for the team and backer |
| **Blockchain** | [Ethereum (ERC-721)](https://opensea.io/collection/car999); 4K videos stored on [Arweave](https://www.arweave.org) |
| **Proceeds** | Seeded 0xBELISK, a public-art treasury |
| **Related** | [ConstitutionDAO](/wiki/daos/social/constitutiondao), [Nouns DAO](/wiki/daos/social/nouns-dao), [PleasrDAO](/wiki/daos/investment/pleasrdao) |

**$CAR** is a 2022 conceptual crypto-art project by the pseudonymous artist [SHL0MS](https://www.shl0ms.com/selected-works/car) in which a [Lamborghini Huracán](https://www.thedrive.com/news/44435/artist-blows-up-lamborghini-huracan-to-sell-videos-of-shrapnel-as-nfts) — the definitive "when Lambo" symbol of crypto wealth — was detonated in the desert, its wreckage sorted into 999 fragments, and each fragment filmed in 4K and sold as an NFT. Destroying the object that crypto culture treats as the finish line, then re-minting its shrapnel as fine art, made $CAR one of the most spectacular works of crypto-native conceptual art: a quarter-million-dollar supercar blown up as an act of institutional critique, and re-issued as a single collection _collectively owned_ by the 888 people who won its pieces at auction.

It is filed here alongside [ConstitutionDAO](/wiki/daos/social/constitutiondao) and [Nouns](/wiki/daos/social/nouns-dao) as a landmark of on-chain cultural coordination — but with an important distinction the popular retelling tends to blur: $CAR was not a crowd that pooled money to _buy_ a car. It was a privately financed artwork whose destroyed body was then _distributed_ across hundreds of holders. That difference is the subject of a section below.

## The object: destroying "when Lambo"

In crypto vernacular, _"when Lambo?"_ is shorthand for _when do I get rich?_ — the Lamborghini standing in for the moment a speculative bet pays off. SHL0MS chose the car precisely because it is that meme made metal. He described the piece to [Fortune](https://fortune.com/2022/02/22/nft-artist-blew-up-lamborghini-protest/) as "a more general criticism of greed and short-termism in crypto" — not an attack on the technology, but on "people simply engaging with crypto because it's a way for them to make money off other people as quickly as possible." Blowing up the trophy, rather than driving it, turns the ultimate crypto flex into a comment on the short-sightedness it represents.

The car itself was a used [2015 Huracán](https://www.autoevolution.com/news/artist-shl0ms-blows-up-real-lamborghini-huracan-turns-wreckage-into-nfts-182458.html), acquired for just under $250,000. The full production — logistics, explosives, and a multi-camera film crew — reportedly cost close to [$1 million and involved a team of around 100 people](https://www.theblock.co/post/134923/artist-blows-up-lamborghini-to-make-nfts-in-protest-against-crypto-culture).

## The detonation

On **2 February 2022**, at an undisclosed desert location in the United States, the Huracán was destroyed by a controlled explosive charge — not crushed or demolished. The blast was set by a [federally licensed explosives engineer](https://www.theblock.co/post/134923/artist-blows-up-lamborghini-to-make-nfts-in-protest-against-crypto-culture) after roughly two weeks of testing, including detonating a separate practice vehicle, and was tuned to _fractionalize_ the car rather than obliterate it — so that recognizable parts survived to become individual objects. The engineer reportedly called it the most challenging detonation of his career. The event was captured in [4K](https://hypebeast.com/2022/2/shl0ms-destroyed-lamborghini-huracan-nft), and the roughly **999 recovered pieces** were then catalogued and each filmed as its own rotating video.

Conscious of the optics of destroying a car to make a point about waste, the team also [purchased carbon credits](https://overstandard.dk/shl0ms-blows-up-lamborghini-to-protest-crypto-greed/) said to more than offset the estimated climate impact of the blast.

## 999 fragments, 888 owners

Each of the 999 fragments became an NFT: a 4K video of a single piece of shrapnel rotating against black, with the physical fragment's attribution recorded in the token's [metadata](https://www.shl0ms.com/selected-works/car). The tokens are **ERC-721** on [Ethereum](https://opensea.io/collection/car999) (contract `0xa80617371a5f511bf4c1ddf822e6040acaa63e71`), with the video files stored permanently on [Arweave](https://www.arweave.org). The recovered physical wreckage was kept in storage rather than shipped to buyers. Of the 999, **888 were sold to the public and 111 were reserved** for the team and the project's backer.

The supply is one of the few claims here that can be settled without trusting a marketplace listing. Calling `totalSupply()` on the collection contract `0xa80617371a5f511bf4c1ddf822e6040acaa63e71` at Ethereum block 25,730,773 returns `0x3e7` — **999** exactly, with `name()` and `symbol()` both returning `CAR`. The fragment count is not an approximation carried forward from press coverage: the edition was minted whole and has never been added to or burned from.

The auction was unusually rigorous for what critics dismissed as a stunt. It ran as a **24-hour "gasless" auction** on the project's own site, with the [smart contracts open-sourced on GitHub](https://github.com/shl0ms/CAR-contracts). Bids were placed in wrapped ETH (wETH), one bid per wallet, starting at 0.01 ETH; the top 888 bids each won a fragment, and an anti-sniping rule extended the auction by ten minutes whenever the leading ranks shifted in the final stretch. A bid was invalidated if the wallet's wETH balance ever fell below it. The sale was [originally scheduled for 24–25 February 2022 but postponed](https://hypebeast.com/2022/2/shl0ms-destroyed-lamborghini-huracan-nft) — the "world events" being Russia's invasion of Ukraine that week — and run in early March. On the secondary market the collection has since traded around [235 ETH in lifetime volume](https://opensea.io/collection/car999) across several hundred owners.

## Crowdfunded, or collectively owned?

$CAR is often described as a "crowdfunded" art project, and it is worth being precise about what that means here. The _car was not bought by a crowd or a DAO._ Backing for the acquisition and production came from a [single private entity plus SHL0MS's own proceeds](https://www.theblock.co/post/134923/artist-blows-up-lamborghini-to-make-nfts-in-protest-against-crypto-culture) from earlier work. The collective element enters at the other end: 888 members of the public each bought a piece of the destroyed car, so ownership of the (former) Lamborghini ended up _distributed_ across hundreds of wallets. $CAR is a story of collective _ownership_, not collective _funding_.

That distinction is exactly what separates it from its shelf-mates here. [ConstitutionDAO](/wiki/daos/social/constitutiondao) was the archetypal crowdfund — thousands of people pooling ~$47M _to buy_ a copy of the U.S. Constitution — and [PleasrDAO](/wiki/daos/investment/pleasrdao) is a collector group that pools capital to acquire culturally significant works. $CAR inverts the pattern: the object is acquired privately, destroyed, and only then fractionalized into hundreds of separately owned tokens — closer to a physical enactment of [fractional](/wiki/daos/investment/the-lao) NFT ownership than to a treasury vote. The one structure that does resemble a shared treasury is the aftermath: proceeds were directed to **0xBELISK** (also styled OBELISK), an art organization SHL0MS formed to fund public installations, seeded — as [one analysis put it](https://smol.news/p/destruction-is-creation-an-ode-to) — by the $CAR sale.

## SHL0MS and crypto-dadaism

SHL0MS (X handle [@SHL0MS](https://x.com/SHL0MS), whose display name is a single cuneiform glyph) is a pseudonymous conceptual artist who describes his practice as ["crypto-dadaism"](https://www.allships.co/article/interview-shl0ms) and gives interviews behind a pixelated face filter to preserve anonymity. His recurring method is _destruction as creation_: taking an iconic object, physically fracturing it, and bridging the physical and digital by filming the pieces to a high standard and issuing them on-chain.

$CAR's direct predecessor was [FNTN](https://www.allships.co/article/interview-shl0ms) (late 2021), a re-creation of Marcel Duchamp's readymade "Fountain" urinal that was smashed in a live ritual and sold as roughly 150 video shards — a piece with a genuinely participatory streak, since the shapes of the shards depended on who showed up to break it. He is also known for [sunset // sunrise](https://nftnow.com/art/shl0ms-viral-end-of-gmail-sunsetting-hoax-and-conceptual-art/), the viral "Sunsetting Gmail" hoax, and a body of on-chain conceptual works. Taken together, the work is money-art in the dadaist tradition: designed to provoke a reaction to value, ownership, and spectacle rather than to decorate.

## Reception and legacy

$CAR drew unusually broad coverage across art, crypto, and mainstream automotive press — [Fortune](https://fortune.com/2022/02/22/nft-artist-blew-up-lamborghini-protest/), [The Block](https://www.theblock.co/post/134923/artist-blows-up-lamborghini-to-make-nfts-in-protest-against-crypto-culture), [Hypebeast](https://hypebeast.com/2022/2/shl0ms-destroyed-lamborghini-huracan-nft), nft now, and [The Drive](https://www.thedrive.com/news/44435/artist-blows-up-lamborghini-huracan-to-sell-videos-of-shrapnel-as-nfts) among them — and went viral on Twitter. Its significance rests on several things at once: the raw spectacle of detonating a supercar as an art gesture; the conceptual sharpness of destroying crypto's own status symbol to critique crypto's excesses; the literalization of NFT fractional ownership as 999 physically separate objects; and the craft of its provenance layer (permanent Arweave storage, per-fragment metadata, open-source auction contracts).

It also attracted the obvious critiques. Some read it as spectacle that destroys value in order to sell value, and [The Drive](https://www.thedrive.com/news/44435/artist-blows-up-lamborghini-huracan-to-sell-videos-of-shrapnel-as-nfts) noted that certain "recovered" parts looked suspiciously clean for pure blast debris, implying some post-detonation disassembly. Both readings — as institutional critique and as elaborate provocation — are arguably the point of a dadaist work. Either way, $CAR endures as the reference example of what crypto-native conceptual art can look like at full scale, and as a vivid, uncomfortable illustration of the "when Lambo" mindset it set out to detonate.

Its coordination lesson generalizes beyond art. The interesting on-chain primitive $CAR exercised was not funding but _shared ownership and a proceeds treasury_ — hundreds of strangers holding pieces of one thing, with the sale's value pooled toward a common purpose. That is the same coordination problem the rest of this wiki circles: how a group of people who don't know each other can jointly own, fund, and govern something on-chain. Caper's answer to the funding-and-treasury half of that question is a [caper](/wiki/foundations/what-is-a-caper) — a shared, always-liquid treasury with an [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) — a different shape from a one-off art drop, but pointed at the same instinct SHL0MS turned into a spectacle.

## The film

The canonical video is SHL0MS's own **$CAR film** — the detonation and the fragments, in 4K:

- [The reveal film](https://twitter.com/SHL0MS/status/1494446592463720448) (SHL0MS on X, February 2022) — the official detonation-and-fragments film.
- [car.shl0ms.com](https://car.shl0ms.com) — the project's own site, which hosted the film and the gasless auction.
- [shl0ms.com/selected-works/car](https://www.shl0ms.com/selected-works/car) — the artist's portfolio page framing the work and linking the film.
- ["They blew up this Lambo to make NFTs!"](https://www.youtube.com/watch?v=e9GQK7KoYUg) (VINwiki) — a third-party explainer with footage and context.

## References

- SHL0MS, [CAR — selected works](https://www.shl0ms.com/selected-works/car) (artist's own project page: 999 filmed fragments, Arweave storage, per-fragment metadata).
- [car.shl0ms.com](https://car.shl0ms.com) — the official $CAR auction site.
- [shl0ms/CAR-contracts](https://github.com/shl0ms/CAR-contracts) — open-source smart contracts for the gasless auction and NFT token.
- Fortune, ["An NFT artist blew up a $250,000 Lamborghini in protest"](https://fortune.com/2022/02/22/nft-artist-blew-up-lamborghini-protest/) (2022) — interview, message, dates, team, proceeds.
- The Block, ["Artist blows up Lamborghini to make NFTs"](https://www.theblock.co/post/134923/artist-blows-up-lamborghini-to-make-nfts-in-protest-against-crypto-culture) — funding structure, detonation, ~$1M cost.
- Hypebeast, ["SHL0MS Destroyed a Lamborghini Huracán for NFTs"](https://hypebeast.com/2022/2/shl0ms-destroyed-lamborghini-huracan-nft) — 4K capture, auction start price, postponement.
- The Drive, ["Artist Blows Up a Lamborghini Huracán to Sell Videos of the Shrapnel as NFTs"](https://www.thedrive.com/news/44435/artist-blows-up-lamborghini-huracan-to-sell-videos-of-shrapnel-as-nfts) — Ethereum, team size, skeptic's read.
- ALLSHIPS, [interview with SHL0MS](https://www.allships.co/article/interview-shl0ms) — "crypto-dadaism," FNTN, artist philosophy.
- smol.news, ["Destruction Is Creation"](https://smol.news/p/destruction-is-creation-an-ode-to) — analysis tying $CAR proceeds to the 0xBELISK treasury.
- OpenSea, [CAR by SHL0MS (car999)](https://opensea.io/collection/car999) — collection, contract address, secondary-market data.
- PR Newswire, [official press release](https://www.prnewswire.com/news-releases/conceptual-artist-shl0ms-detonates-a-lamborghini-huracan-301485915.html) (2022).

## ApeCoin DAO

URL: https://caper.network/wiki/daos/social/apecoin-dao
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Name** | ApeCoin DAO _(dissolved 2025)_ |
| **Type** | NFT-ecosystem / community DAO governing the [APE](https://apecoin.com/) token, tied to the Bored Ape Yacht Club and Yuga Labs orbit (Ethereum) |
| **Token** | APE — 1,000,000,000 fixed supply, non-mintable and non-burnable; launched March 2022 |
| **Administration** | The Ape Foundation, with an elected _Special Council_ ("the Board") overseeing its administrators |
| **Governance** | Ape Improvement Proposals (AIPs) debated on the ApeCoin forum, then ratified by [Snapshot](https://snapshot.org/#/apecoin.eth) token-weighted vote |
| **Status** | Dissolved by [AIP-596](https://www.coindesk.com/markets/2025/06/06/yuga-labs-proposes-scrapping-apecoin-dao-launching-apeco) (June 2025) — treasury, IP, and contracts transferred to **ApeCo**, a Yuga Labs-controlled company |
| **Related** | [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail), [Exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [Treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [ConstitutionDAO](/wiki/daos/social/constitutiondao), [The Sandbox DAO](/wiki/daos/social/the-sandbox-dao) |

**ApeCoin DAO** was, for three years, one of the largest and most-watched consumer DAOs in crypto — the community that governed the [APE](https://apecoin.com/) token and its share of the Bored Ape Yacht Club ecosystem built by [Yuga Labs](https://en.wikipedia.org/wiki/Yuga_Labs). It is also the clearest case study of a very 2025 ending: rather than being drained by an exploit or fading into [quiet abandonment](/wiki/dao-governance/concepts/analysis/how-daos-fail), in June 2025 its own token-holders voted — by a reported **99.66%** — to [dissolve the DAO entirely](https://www.ainvest.com/news/apecoin-dao-dissolves-99-66-vote-apeco-transition-2506/) and hand its treasury, intellectual property, and operations to **ApeCo**, a centralized company run by Yuga Labs. A DAO voluntarily voting itself back into a corporation is rare enough to be worth studying closely.

## The APE token and the Yuga orbit

**APE** launched in March 2022 with a fixed supply of **one billion** tokens — the smart contract permits neither minting nor burning — positioned as the shared utility and governance token for the wider Bored Ape ecosystem: BAYC and Mutant Ape (MAYC) NFTs, the [Otherside](https://apecoin.com/) metaverse, and later ApeChain. Per the launch allocation, roughly **47%** went to the DAO ecosystem fund (its treasury), **15%** was airdropped to BAYC/MAYC holders, **15%** to Yuga Labs, **14%** to launch contributors and investors, **8%** to the four BAYC founders, and **1%** to the Jane Goodall Legacy Foundation ([apecoin.com](https://apecoin.com/)). Crucially, ApeCoin was launched as a token _with_ a DAO attached rather than a protocol that produced fees — the DAO's job was to steward a treasury and fund ecosystem work, not to govern a revenue-generating machine, which shaped both its politics and its eventual undoing.

## How the DAO governed itself

Only APE holders were members. Ideas moved through the **Ape Improvement Proposal (AIP)** pipeline: drafted and debated on the ApeCoin forum, then put to a token-weighted [Snapshot](https://snapshot.org/#/apecoin.eth) vote. Implementation was handled by the **Ape Foundation**, a Cayman-registered administrator, with a five-seat elected **Special Council** (the DAO's "Board") supervising the Foundation's administrators — a [legal-wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures) pattern common to large token DAOs. In January 2025 the DAO even passed [AIP-582](https://cryptoslate.com/yuga-moves-to-kill-apecoin-dao-transfer-168m-in-assets-to-new-entity/) (~93% in favor) to move governance on-chain via **ApeChain**, its Arbitrum-based layer. Yet turnout on most proposals stayed low, and by 2025 core stakeholders — Yuga included — openly described governance as stagnant, a critique that set up the dissolution vote.

## AIP-596: the DAO votes itself out of existence

On 5 June 2025, Yuga Labs CEO Greg Solano filed the proposal that became **AIP-596, "Sunsetting the DAO and Launching ApeCo."** His framing was blunt: what "started with promise has devolved into sluggish, noisy, and often unserious governance theater" that funded ["vanity proposals and low-impact initiatives"](https://decrypt.co/323902/bored-ape-creator-yuga-labs-wants-kill-apecoin-dao) ([CoinDesk](https://www.coindesk.com/markets/2025/06/06/yuga-labs-proposes-scrapping-apecoin-dao-launching-apeco)). The proposal transferred all DAO and Foundation assets — reported at roughly **169 million APE (~$168M at the time)** — plus intellectual property and administrative control to **ApeCo**, a new Yuga-controlled entity focused on three pillars: ApeChain, the Bored Ape Yacht Club, and Otherside ([CryptoSlate](https://cryptoslate.com/yuga-moves-to-kill-apecoin-dao-transfer-168m-in-assets-to-new-entity/)). It committed to fund the APE staking contract through March 2026 and set aside 10 million APE for transition costs, but otherwise **nullified every prior AIP** not already executed, dissolved all working groups and elections, and shut down the forum. Voting closed on 26 June 2025 with a reported **99.66% in favor** ([AInvest](https://www.ainvest.com/news/apecoin-dao-dissolves-99-66-vote-apeco-transition-2506/)). The ApeCoin forum has since gone offline — a fitting epilogue for a governance body that voted to end itself.

## How Caper approaches this

ApeCoin DAO's ending exposes two structural gaps that made a near-unanimous self-dissolution the path of least resistance. First, there was **no clean per-member exit**: a holder who disliked the direction could sell APE on the open market, but had no way to redeem a proportional share of the DAO's _treasury_ — so the rational move for dissenters was to disengage rather than fight, which is exactly the dynamic our [failure-modes](/wiki/dao-governance/concepts/analysis/how-daos-fail) page identifies. Second, low real engagement meant a founder-authored proposal could clear the bar with overwhelming numbers and thin participation. [Caper](/wiki/foundations/what-is-a-caper) is built against both. Every caper's `exit()` lets a member redeem a pro-rata slice of the treasury at any time, with no proposal or quorum, and that redemption share equals their exact [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — a blend of the governance stake a member holds and the participation they have actually shown, the latter earned as non-transferable [vote tokens](/wiki/governance/voting) minted one per vote. A member who wants out leaves with their fair share instead of quietly abandoning the treasury to whoever remains — and because voice is participation-weighted, capturing a caper takes sustained, earned involvement, not a single well-timed vote.

## BonkDAO (BONK)

URL: https://caper.network/wiki/daos/social/bonkdao
Updated: 2026-08-02

|  |  |
| --- | --- |
| **Name** | BonkDAO — the token-holder governance body of [BONK](https://www.bonkcoin.com/), the Solana community memecoin |
| **Type** | Community / cultural DAO governing a memecoin treasury and its ecosystem spending (Solana) |
| **Token** | BONK (SPL, mint `DezXAZ8z…B1pPB263`) — launched 25 December 2022 with 100 trillion tokens, ~**88.0 trillion** circulating after burns, ~$255m market cap ([CoinGecko](https://www.coingecko.com/en/coins/bonk), 2 August 2026) |
| **Distribution** | No private sale and no venture round — half the supply airdropped to Solana users, artists, developers and NFT communities at launch |
| **Governance** | Bonk Improvement Proposals (BIPs) voted token-weighted on [Realms](https://realms.today/), the front end for Solana's [SPL Governance](/wiki/dao-governance/tooling/frameworks/spl-governance) program — quorum 1% of supply, six-day voting period, **no execution timelock** |
| **Notable event** | [BIP #76, July 2026](https://www.coindesk.com/markets/2026/07/07/bonk-faces-usd20-million-treasury-drain-after-attacker-spends-usd4-million-to-pass-malicious-proposal) — an attacker bought quorum for ~$4.4m and voted ~$20m out of the treasury |
| **Related** | [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy), [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [ApeCoin DAO](/wiki/daos/social/apecoin-dao), [Nouns DAO](/wiki/daos/social/nouns-dao) |

**BonkDAO** is the governance body that spends the treasury of [BONK](https://www.bonkcoin.com/), the community memecoin launched on Solana on Christmas Day 2022. It is worth a directory entry for a reason that has nothing to do with memes: in July 2026 BonkDAO became the clearest worked example of a treasury whose _market price_ was published in its own governance settings. Its quorum was fixed at 1% of token supply, so anyone willing to buy 1% of BONK could pass a proposal alone — and on 6 July 2026 someone spent about **$4.4 million** doing exactly that and voted roughly **$20 million** out of the treasury ([CoinDesk](https://www.coindesk.com/markets/2026/07/07/bonk-faces-usd20-million-treasury-drain-after-attacker-spends-usd4-million-to-pass-malicious-proposal)). No contract was broken. The vote was valid.

## An airdrop that became an ecosystem

BONK launched on **25 December 2022** with an initial supply of **100 trillion** tokens and no private sale, no venture allocation, and no team round. Half of that supply was airdropped across the Solana community — traders, NFT collectors, artists, developers and contributors — during a period when Solana activity had collapsed in the wake of the FTX failure, which is most of why the token attached itself to the chain's identity so quickly ([bonkcoin.com](https://www.bonkcoin.com/)). A share of the launch supply was set aside as a DAO-controlled treasury; that treasury is the thing BonkDAO votes on.

What grew on top of it is unusual for a memecoin. BONK is now the settlement token for a cluster of consumer products — a swap venue, spot and perpetual trading, a Telegram trading bot, and the [LetsBonk](https://letsbonk.fun/) token launchpad — several of which route a slice of fees into buybacks and burns. Supply has fallen from 100 trillion at launch to roughly **88.0 trillion** circulating, with a market capitalisation near **$255 million** as of 2 August 2026 ([CoinGecko](https://www.coingecko.com/en/coins/bonk)). Developer documentation for the ecosystem sits at [build.bonkcoin.com](https://build.bonkcoin.com/).

The gap between that product surface and the DAO's governance surface is the story. BONK acquired an ecosystem, a burn mechanism and, by its own count, over a million holders; its DAO kept the governance configuration of a 2022 community project.

## How BonkDAO governs

Proposals are filed as **Bonk Improvement Proposals** and voted token-weighted on [Realms](https://realms.today/), the standard Solana governance front end built on the [SPL Governance](/wiki/dao-governance/tooling/frameworks/spl-governance) program. Realms is a capable framework — it supports councils, multiple vote thresholds, and configurable execution delays — but those protections are _per-realm settings_, not defaults, and BonkDAO's realm was configured without them.

The three parameters that mattered in July 2026:

- **Quorum: 1% of token supply** — 879.95 billion BONK. Because BonkDAO's real turnout ran far below that, quorum was not a participation floor at all; it was the whole electorate, and it was purchasable on the open market.
- **Voting period: six days**, with the proposal visible in public the entire time. Visibility only helps if someone is watching, and roughly 18,000 members were not.
- **Execution timelock: none.** A passed instruction executed immediately, so there was no window in which the community could have cancelled a transfer it had just noticed ([Halborn](https://www.halborn.com/blog/post/explained-the-bonkdao-hack-july-2026)).

None of these are Realms defects. They are the choices a DAO makes when its governance is set up in a week and never revisited as the treasury grows — which is the general failure pattern catalogued under [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

Every element of that configuration is a per-realm setting rather than a framework default, which is what makes it a design decision the DAO owned. The part that generalises past this one DAO – a participation floor denominated in tokens, guarding a treasury denominated in dollars, with an exchange rate between them that moves without any vote – is treated in general on [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design).

## BIP #76: the treasury bought for a fifth of its value

On **30 June 2026** an anonymous wallet filed **BIP #76 — "Sowellian BonkDAO"**, presented as a governance-renewal plan that would install new members and a council and "rebuild the community". Its operative instruction sent **4,426,104,450,305 BONK** from the treasury to an address the proposer controlled. Over 4–5 July the same actor bought just over 1% of BONK supply on Bybit and Binance, part-funded by borrowing against DeFi collateral, for roughly **$4.4 million** — an amount sized to clear the quorum line and little more.

The proposal passed on **6 July 2026** with **882.38 billion** BONK in favour against the 879.95 billion threshold, cleared by about 0.3%. **Seven wallets** voted out of more than 18,000 members — a turnout of about **2.9%** — and the buyer held roughly **99.878%** of everything cast. With no timelock, execution followed the tally. BonkDAO [confirmed the loss publicly](https://news.bitcoin.com/bonkdao-treasury-loses-20m-in-malicious-governance-attack-bonk-slides-8/), said it had identified the exchange wallets used to accumulate the stake, and began working with exchanges, bridges, the Solana Foundation and law enforcement; at least one exchange suspended BONK transfers while the funds moved ([CryptoSlate](https://cryptoslate.com/bonkdaos-estimated-20m-drain-exposes-a-serious-security-fault-line-for-memecoin-treasuries/)).

The full technical account — the attack families it belongs to, the defences it defeated, and how it compares with Beanstalk, Steem and Compound Prop 289 — is in [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks). The participation side of it is treated in [Voter apathy and governance participation](/wiki/dao-governance/concepts/analysis/voter-apathy).

## What it changed, and what it didn't

As of August 2026 the reform list circulating around BonkDAO and the wider Solana ecosystem is the expected one: mandatory execution timelocks on treasury instructions, quorum scaled to the value at risk rather than to a fixed share of supply, multisig or council sign-off on large transfers, and anomaly review before execution ([crypto.news](https://crypto.news/the-bonk-governance-attack-how-a-dao-lost-20-million-in-one-proposal/)). These remain proposals rather than shipped configuration, and recovery of the drained tokens is unresolved.

The transferable lesson is narrower than "memecoin DAOs are unserious". BonkDAO's quorum was a number chosen when the treasury was worth little and the token was a joke; it was never re-priced as the treasury grew into eight figures. Any DAO whose quorum is denominated in _tokens_ while its treasury is denominated in _dollars_ has the same exposure, and the exchange rate between the two moves without anyone voting on it. The general treatment of that problem sits under [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management); the mechanics of the vote itself under [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) and [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle).

## How Caper approaches this

Caper does not solve governance capture, but it prices it differently, because voting weight on a [caper](/wiki/foundations/what-is-a-caper) is not a function of tokens held. Each ballot is credited `(t·v)/(V·T)` — the voter's token balance `t` multiplied by their vote tokens `v`, over the vote-token supply `V` times circulating supply `T`. Vote tokens are minted one per ballot cast, and a ballot snapshots `v` _before_ minting the token it earns, so a wallet voting for the first time contributes exactly zero weight to the proposal it is voting on. Buying the token is one factor of two; the other has to be accumulated by turning up, over time, to earlier votes.

Two further details cut against the buy-then-vote shape. The tally credits each ballot `min(held_at_vote, live_balance)`, and anyone may permissionlessly re-clamp that figure downward during a challenge window after voting closes — so stake that arrives for one vote and leaves afterwards loses its credit rather than keeping it. And the pass rule is a share of _weight actually cast_, not a fixed slice of supply: a proposal carries when its leading option takes `1.5 / option_count` of cast weight and that option is not a "no". There is no supply-denominated quorum number to buy, because there is no supply-denominated quorum. Details in [Voting](/wiki/governance/voting) and [Proposals](/wiki/governance/proposals); the exit path, which pays out at that same weight, in [Trading](/wiki/markets/trading).

## ConstitutionDAO

URL: https://caper.network/wiki/daos/social/constitutiondao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | ConstitutionDAO |
| **Type** | Single-purpose ("flash") crowdfunding DAO (Ethereum) |
| **Active** | November 2021 — roughly one week |
| **Goal** | Win a first-printing copy of the U.S. Constitution at [Sotheby's](https://www.sothebys.com/) |
| **Raised** | ~$47M in ETH from ~17,000 contributors (median ~$217) |
| **Crowdfunding rail** | [Juicebox protocol](https://juicebox.money/#/p/constitutiondao) |
| **Outcome** | Outbid by Ken Griffin (~$43.2M); dissolved and refunded |
| **Token** | $PEOPLE — a redeem-only refund token, "no rights, governance, or utility" |
| **Site** | [constitutiondao.com](https://www.constitutiondao.com) · [Juicebox project](https://juicebox.money/#/p/constitutiondao) |
| **Related** | [$CAR (SHL0MS)](/wiki/daos/social/shl0ms-car), [Nouns DAO](/wiki/daos/social/nouns-dao), [PleasrDAO](/wiki/daos/investment/pleasrdao) |

**ConstitutionDAO** was the canonical _single-purpose_ (or "flash") [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao): an organization that formed in days around one concrete goal — buying a rare first-printing copy of the U.S. Constitution at auction — raised roughly **$47 million** in ETH from about **17,000 contributors**, lost the sale, and then dissolved and refunded its backers. Its founders called it ["a beautiful experiment in a single-purpose DAO."](https://www.constitutiondao.com) It remains the industry's most-cited example of how fast a [crowdfunding DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) can assemble a treasury — and a case study in the operational problems that speed leaves unsolved.

## The one-week raise

In November 2021 an ad-hoc group crowdfunded the bid entirely through the [Juicebox protocol](https://juicebox.money/#/p/constitutiondao), a no-code Ethereum funding rail: contributors sent ETH to the project's Juicebox contract and received $PEOPLE tokens in return. In under a week it took in roughly **$47 million** worth of ETH; [the median contribution was about $217](https://en.wikipedia.org/wiki/ConstitutionDAO), and the campaign drew an estimated 17,000 people — many making their first-ever on-chain transaction. The speed was the point: a single, legible goal plus an open funding contract let a leaderless crowd out-raise most professionally organized funds in days, without a legal entity, a token sale roadmap, or a governance framework in place first.

## The auction and the loss

At the [Sotheby's](https://www.sothebys.com/) auction on 18 November 2021 ConstitutionDAO was outbid by Citadel founder [Ken Griffin, whose winning bid totaled about $43.2 million](https://en.wikipedia.org/wiki/ConstitutionDAO). A structural handicap shaped the loss: because the DAO's treasury sat in a fully public on-chain wallet, rival bidders could see exactly how much it held, and it had to hold funds back for insurance, storage, and display of a fragile document — so it could not simply bid its entire balance. The transparency that made the raise trustless also made its bidding strategy legible to a single well-capitalized competitor.

## Dissolution, refunds, and the gas problem

Having lost, the organizers [made full refunds available](https://www.constitutiondao.com) — contributors could _claim_ their $PEOPLE or _redeem_ it back to ETH. But the refund exposed a hard limit of naïve on-chain crowdfunding: at 2021 gas prices the fixed cost of a transaction did not scale with contribution size, so [some backers paid more in Ethereum fees to donate and then reclaim than they had given](https://en.wikipedia.org/wiki/ConstitutionDAO), and weeks later a large share of the funds still sat unredeemed. The episode became a standard reference for the [treasury and operations](/wiki/dao-governance/concepts/treasury/dao-treasury-management) problems — gas, custody, coordination, wind-down — that a purpose-built DAO has to solve, not assume away.

## $PEOPLE and the afterlife

The $PEOPLE token was never a governance share — the official site is explicit that it carries ["no rights, governance, or utility other than redeeming them for ethereum,"](https://www.constitutiondao.com) at a fixed 1 ETH : 1,000,000 $PEOPLE ratio, and that the DAO "cannot and will not endorse any future plans for the token." In other words, it was a refund IOU, not a claim on an ongoing organization. Even so, a community kept it trading as a memecoin long after dissolution — a reminder that a token can outlive the entity that issued it, and that "what does this token actually entitle you to?" is the first question a [DAO's tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) has to answer.

It is the counterexample to [PleasrDAO](/wiki/daos/investment/pleasrdao), the collector DAO that _won_ its trophies and fractionalized them into working, tradeable shares — where ConstitutionDAO's token became a refund IOU, PleasrDAO's became a live claim on the asset.

## How Caper approaches this

ConstitutionDAO proved a DAO can crowdfund a treasury around a single goal at astonishing speed — but its token was a pure refund IOU with no standing rights, and the only "exit" was a one-time, all-or-nothing dissolution vote after the mission failed. A [caper](/wiki/foundations/what-is-a-caper) keeps the fast, single-transaction raise but makes the token a durable claim rather than a receipt. Funding flows through a continuous [bonding curve](/wiki/markets/bonding-curve) into a [treasury](/wiki/markets/raising-funds) the holders govern by [proposal](/wiki/governance/proposals), and — verified in the contract — every member holds a standing [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): they can redeem their tokens and vote record for a treasury share sized by their canonical vote weight at any time, individually, without waiting for the whole organization to wind down. If a caper's mission stalls, no group refund vote is needed — each member simply takes their share.

## Decentraland DAO

URL: https://caper.network/wiki/daos/social/decentraland-dao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Decentraland DAO |
| **Type** | Metaverse / virtual-world DAO (governs a 3D world and its land economy) |
| **Launched** | February 2020, alongside Decentraland’s public mainnet |
| **Governance assets** | MANA (ERC-20), LAND & Estates (ERC-721), NAMEs, and legacy Wearables — each converts to voting power |
| **Infrastructure** | [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) for gasless voting; an [Aragon](/wiki/dao-governance/tooling/frameworks/aragon) Agent holds the treasury; a DAO Committee multisig enacts binding proposals |
| **Treasury seed** | 222,000,000 MANA on a 10-year vesting contract that started 19 Feb 2020 and vests every second |
| **Notable for** | The canonical example of a DAO that governs a live consumer product — a virtual world — rather than a DeFi protocol |
| **Related** | [The Sandbox DAO](/wiki/daos/social/the-sandbox-dao) — the other large metaverse DAO, paused in 2026, [ApeCoin DAO](/wiki/daos/social/apecoin-dao), [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) |

The **Decentraland DAO** is the governance body of [Decentraland](https://decentraland.org/), a browser-based 3D virtual world whose land, names, and wearables are on-chain assets. It is one of the few DAOs whose remit is not a financial protocol but a _consumer product_: the DAO owns the smart contracts behind the world’s land economy and steers how the world itself evolves. That makes it a useful counterpoint to the DeFi-heavy [ecosystem directory](/wiki/daos/dexs/uniswap-dao) — a working answer to what “community-owned” looks like when the thing being owned is a place people log in to, not a lending market.

## A DAO that owns a world’s land economy

Decentraland describes its DAO as “the decision-making tool for MANA, NAMEs and LAND holders.” Concretely, the DAO controls a specific, bounded set of on-chain levers, per its [documentation](https://docs.decentraland.org/dao/dao/what-is-the-dao/):

- The **LAND and Estate** smart contracts — the ERC-721 registries for every parcel and bundle of parcels in the world.
- A fund of **MANA and other tokens** earmarked for community [grants](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation).
- The curated lists that shape the world in practice: **banned names**, **Points of Interest**, and the **Catalyst node** operators that serve the world’s content.

A revealing limit sits at the centre of this: **the DAO does not own the MANA token contract itself**. MANA was distributed by a TokenSale contract that [self-destructed at deployment](https://docs.decentraland.org/dao/dao/what-is-the-dao/), permanently fixing the supply and putting it beyond any vote. The DAO governs what happens _inside_ the world and how the treasury is spent — it cannot mint the currency. That is a deliberate design choice, and a sharper separation of powers than many token-DAOs bother to make.

## Voting power from four kinds of asset

Most DAOs derive [voting power](/wiki/dao-governance/concepts/voting/token-weighted-voting) from a single fungible token. Decentraland instead aggregates **voting power (VP)** across everything a member holds in the world, per its [voting-power rules](https://docs.decentraland.org/dao/dao/what-is-the-dao/):

- **1 MANA = 1 VP** (wrapped and unwrapped balances both count).
- **1 LAND = 2,000 VP** — land is weighted far above liquid tokens, tying governance weight to a stake in the world’s scarce real estate.
- **1 Estate = 2,000 VP per parcel** it contains.
- **1 NAME = 100 VP**.
- **Legacy Wearables** by rarity: Uncommon 1, Rare 5, Epic 10, Legendary 100, Mythic 1,000 VP.

VP is read from **wallet balances at the moment the proposal is created**, so a member cannot buy in mid-vote to swing a result — the same snapshot logic Snapshot uses generally. Holders who do not want to vote directly can **delegate** their VP to another community member through Decentraland’s Snapshot space. The effect is that a large landowner carries structural weight a small MANA holder does not: this is capital-and-property-weighted governance, with all the [concentration questions](/wiki/dao-governance/concepts/analysis/how-daos-fail) that raises, made unusually legible by the land component.

## Snapshot to vote, a multisig to enact

Decentraland runs the [hybrid governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) model most large DAOs land on. Proposals are drafted from templates at [governance.decentraland.org](https://governance.decentraland.org/), and the votes are cast on [Snapshot](https://docs.snapshot.box/) — gasless signed messages, with the proposal, ballots, and result all pinned to [IPFS](https://ipfs.tech/) so the record is tamper-evident without touching gas.

Because a Snapshot result is only a signal, binding proposals are enacted on Ethereum by a **DAO Committee** — a multisig whose members are themselves elected by DAO vote — which executes the approved action. Watching the Committee is a **Security Advisory Board (SAB)**, a separate multisig of trusted key-holders that can intervene on security grounds. Underneath both, the treasury lives in an [Aragon Agent](https://blog.aragon.org/decentraland-secures-treasury-with-aragon/), the smart-contract account that actually holds funds and interacts with Ethereum on the DAO’s behalf. It is a clean, layered version of the trusted-executor pattern — and, like every such pattern, it asks members to trust that the Committee will honour the vote.

## The DAO Fund

The DAO was seeded with a **10-year vesting contract worth 222,000,000 MANA**, started on **19 February 2020**; the MANA [vests every second](https://docs.decentraland.org/dao/dao/the-dao-fund/), so the fund grows continuously rather than unlocking in cliffs. On top of the vesting stream, the treasury earns a running income: a **2.5% fee** on primary-market sales through the Decentraland Marketplace, plus a share of the **2.5%** secondary-market fee on OpenSea sales of LAND, Estates, NAMEs, and wearables. Current balances are published on the DAO’s [transparency dashboard](https://governance.decentraland.org/transparency/).

Sitting alongside the DAO is the **Decentraland Foundation**, the project’s legally accountable arm, which holds the trademarks and the off-chain obligations a purely on-chain body cannot carry. The split — an on-chain [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) the DAO spends by vote, and a [legal foundation](/wiki/dao-governance/concepts/membership/dao-legal-structures) that owns the IP — is a common shape for consumer-facing DAOs that need a real-world counterparty.

## How Caper approaches this

Decentraland’s governance is capital-and-property weighted and enacted by trusted multisigs: your say scales with how much MANA and LAND you hold, and a Snapshot result only takes effect once the DAO Committee chooses to execute it. A [caper](/wiki/foundations/what-is-a-caper) makes two different bets. First, the decisive part of governance weight is **earned, not bought**. Voting mints a [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens), non-transferable proof-of-vote token, and a member’s [vote weight](/wiki/governance/voting) is a function of both their token stake _and_ that accumulated record — so a well-funded buyer cannot simply purchase control the way they could accumulate LAND. (Weight still scales with stake; the earned record is the factor money can’t rent, not a replacement for holding.) Second, there is **no multisig standing between the vote and the outcome**: a passed [PAYOUT or INVEST](/wiki/governance/proposals) proposal is [executed by the contract itself](/wiki/governance/execution) on [Radix](https://www.radixdlt.com/), with an execution delay that lets a dissenting member take their [participation-weighted exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) before the action lands.

The honest trade-off: Decentraland’s Aragon-plus-multisig stack is battle-tested and gives its Committee human discretion to catch mistakes, which a fully on-chain caper forgoes. What a caper offers in return is that the passing vote _is_ the transfer, and the factor that decides who governs cannot be bought on a secondary market.

## References

- Decentraland, [What is the DAO](https://docs.decentraland.org/dao/dao/what-is-the-dao/) — the contracts and lists the DAO controls, and the voting-power rules.
- Decentraland, [The DAO Fund](https://docs.decentraland.org/dao/dao/the-dao-fund/) — the 222M MANA vesting contract and marketplace fee income.
- Decentraland, [Governance dApp](https://governance.decentraland.org/) and [Transparency dashboard](https://governance.decentraland.org/transparency/).
- Aragon, [Decentraland secures its treasury with Aragon](https://blog.aragon.org/decentraland-secures-treasury-with-aragon/) — the Aragon Agent holding the DAO’s funds.

## Friends With Benefits (FWB)

URL: https://caper.network/wiki/daos/social/friends-with-benefits
Updated: 2026-08-03

| Organization | **Friends With Benefits (FWB)** – a token-gated cultural community, widely described as the first social DAO |
| --- | --- |
| Category | Social / membership DAO (non-DeFi) |
| Founded | September 2020 by [Trevor McFedries](https://en.wikipedia.org/wiki/Trevor_McFedries) (co-founder of Brud, the studio behind virtual influencer Lil Miquela) |
| Membership | A written application _plus_ holding the token: [75 FWB for a Global Member, 5 FWB for a Local Member](https://fwb.help/about) |
| Token | **$FWB** – a freely [tradeable ERC-20](https://coinmarketcap.com/currencies/friends-with-benefits/); the same asset gates access and carries governance weight |
| Backers | [a16z-led ~$10M round, October 2021](https://a16zcrypto.com/posts/article/investing-in-friends-with-benefits-a-dao/) (~$100M valuation; Spark Capital, Pace Capital) |
| Today | A product org – [“Friends With Builders”](https://www.coindesk.com/tech/2025/04/18/friends-with-benefits-grows-up), CEO Greg Bresnitz |
| Website | [fwb.help](https://fwb.help/) |
| Status | 🟢 Active |

**Friends With Benefits** is widely considered the [first social DAO](https://a16zcrypto.com/posts/article/investing-in-friends-with-benefits-a-dao/) – not a protocol, an investment club, or a collector, but a cultural community you join by holding a token. Where [The LAO](/wiki/daos/investment/the-lao) pools capital to _invest_ and [PleasrDAO](/wiki/daos/investment/pleasrdao) pools capital to _collect_, FWB pools _people_: the treasury and the token exist to fund a scene – events, a city network, editorial, and creative projects – rather than to buy an asset or back a venture. It rounds out the non-DeFi archetypes catalogued in [types of DAOs](/wiki/dao-governance/concepts/fundamentals/types-of-daos), alongside the failed one-shot crowdfund ([ConstitutionDAO](/wiki/daos/social/constitutiondao)) and the NFT-native creative org ([Nouns](/wiki/daos/social/nouns-dao)).

## The social-DAO thesis: a community you buy into

FWB started in [September 2020](https://a16zcrypto.com/posts/article/investing-in-friends-with-benefits-a-dao/) as a token-gated Discord server: to get in you both wrote an application the community reviewed and held enough $FWB to signal, in the founders' words, [“meaningful ownership in the DAO.”](https://a16zcrypto.com/posts/article/investing-in-friends-with-benefits-a-dao/) That pairing – a human gate and a capital gate – is the whole social-DAO idea. Members share governing power over a community treasury and capture the upside of what the group makes together, which is meant to align artists, writers, and builders around a common scene rather than a common trade.

By the time a16z led its round the DAO had grown to [nearly 2,000 members](https://a16zcrypto.com/posts/article/investing-in-friends-with-benefits-a-dao/) and had already spun up a token-gated events app, an NFT gallery, a web3 editorial publication, a virtual music studio, and global parties. The token is the membership card, the vote, and the speculative asset all at once.

## What the token gates

Access is tiered by holdings. A [Global Member holds 75 FWB](https://fwb.help/about) for unrestricted access to the whole ecosystem; a [Local Member holds 5 FWB](https://fwb.help/about) for a lighter tier scoped to FWB Cities and events. On top of the balance requirement sits the application, so the token alone is necessary but not sufficient. The most visible output is IRL: local city chapters and the annual [FWB FEST](https://www.forbes.com/sites/digital-assets/2023/08/10/crypto-clubs-throwing-summer-parties-inside-the-friends-with-benefits-dao-festival/), a multi-day gathering (its fifth edition runs July 31–August 2, 2026) that turns the online membership into a physical scene. In that sense FWB is a bet that a tradeable token can bootstrap real belonging.

## From social club to product org

After the 2021 bull market the FOMO faded, and FWB has spent 2024–2025 [deliberately growing up](https://www.coindesk.com/tech/2025/04/18/friends-with-benefits-grows-up): under CEO Greg Bresnitz it reframed itself from an events-and-hype community into an organization that ships products in music, film, and culture with the crypto tucked [“under the hood.”](https://www.coindesk.com/tech/2025/04/18/friends-with-benefits-grows-up) The flagship is [Friends With Builders](https://www.coindesk.com/tech/2025/04/18/friends-with-benefits-grows-up), a cohort program run with roughly twenty infrastructure partners (AWS, Alchemy, thirdweb, QuickNode, Filecoin, Base, World and others) to help creative technologists ship early-stage products – a pivot from throwing parties to incubating them. It is a candid answer to a hard question every social DAO faces: once the market cools, what is the token actually _for_?

## How Caper approaches this

FWB makes the tension in a token-gated community explicit: the same $FWB that grants access and a vote is a [freely tradeable ERC-20](https://coinmarketcap.com/currencies/friends-with-benefits/), so status has a spot price. A well-funded newcomer can simply buy the balance the tier requires (the application aside), and an early member can sell their standing to the highest bidder. Belonging and voice ride on the market, not on anything earned inside the community.

A [caper](/wiki/foundations/what-is-a-caper) keeps the capital side liquid but splits the governance side off from it. Holding and trading a caper's token happens on its [bonding curve](/wiki/markets/bonding-curve) like any other asset – but a caper's decisive governance weight comes from a [soulbound proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens) that is minted one-per-vote, is non-transferable, and cannot be bought. Vote weight combines _held tokens_ and _that earned record_ – `w = (t·v) / (V·T)` – and the same quantity sets your [exit share](/wiki/markets/trading) of the treasury (verified against `contracts/logic/src/lib.rs`). Capital still counts, but a bag alone can't capture a caper the way it can meet an FWB tier: the part that can't be bought is the part you have to show up for. It is a different answer to FWB's own question – the token stays a market, but the community's voice is earned, not purchased.

## Nouns DAO

URL: https://caper.network/wiki/daos/social/nouns-dao
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | Nouns DAO |
| **Type** | On-chain NFT / collector DAO (Ethereum) |
| **Launched** | 8 August 2021 |
| **Membership** | One Noun = one irrevocable member = one vote |
| **Issuance** | Perpetual auction — one Noun every 24 hours, forever |
| **Governance** | Fork of [Compound Governor](https://docs.compound.finance/v2/governance/), fully on-chain |
| **IP** | [CC0](https://creativecommons.org/public-domain/cc0/) — all Noun art is public domain |
| **Exit** | Fork / [ragequit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)-style redemption (V3, 2023) |
| **Site** | [nouns.wtf](https://nouns.wtf) · [docs](https://docs.nouns.wtf/) · [governance](https://www.nouns.camp/) |

**Nouns DAO** is a fully on-chain NFT DAO launched on Ethereum on 8 August 2021. It is the canonical example of an _auction-funded_, [fully on-chain](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) organization: instead of a fixed token sale, a smart contract mints and auctions exactly one NFT — a "Noun" — every 24 hours, forever, and routes 100% of the proceeds into a treasury the Noun holders themselves govern. Every Noun is generated deterministically on-chain from a fixed trait set, so the collection has no pre-mint, no team allocation, and no external issuer. Its combination of perpetual issuance, one-member-one-vote governance, and public-domain art has made it one of the most-studied [collector-DAO](/wiki/dao-governance/concepts/fundamentals/types-of-daos) designs in the industry.

## The perpetual auction

The [Nouns Auction House](https://docs.nouns.wtf/protocol/deployments) contract is a self-sufficient generation-and-distribution engine. Each day it settles the previous auction, mints the next Noun, and opens a fresh 24-hour English auction for it; the highest bidder receives the Noun and **100% of the winning ETH bid is deposited directly into the [Nouns treasury](https://docs.nouns.wtf/)** — there is no founder cut on the auction itself (a small share of Nouns is periodically directed to the founding "Nounders" as a separate reward). Because supply grows by exactly one unit per day and demand sets the clearing price, the treasury is funded continuously by genuine buy-side interest rather than by a one-off raise. This makes Nouns a live experiment in whether a DAO can bootstrap and sustain a large treasury purely from ongoing primary issuance.

## One Noun, one vote

Governance runs on a fork of [Compound](/wiki/daos/lending/compound-dao)'s Governor contracts, adapted so that voting power comes from Nouns rather than a fungible token. Each Noun is an **irrevocable member** of the DAO and carries exactly one vote in every proposal, so the design is flat [one-member-one-vote](/wiki/dao-governance/concepts/voting/token-weighted-voting) rather than continuous [token-weighting](/wiki/dao-governance/concepts/voting/token-weighted-voting) — a whale must actually hold many distinct daily NFTs to accumulate power. Proposals move fully on-chain through the standard [propose → vote → queue → execute](/wiki/dao-governance/concepts/voting/proposal-lifecycle) lifecycle, and passed proposals can spend treasury ETH without any off-chain multisig in the loop. Nouns holders have used this to fund hundreds of proposals — from open-source software and films to real-world brand campaigns.

## CC0 and the derivative ecosystem

All Noun artwork is released under [CC0](https://creativecommons.org/public-domain/cc0/), placing it in the public domain with no rights reserved. Anyone may use, remix, or commercialize the imagery without permission — a deliberate bet that giving away the intellectual property maximizes the brand's spread and, in turn, the demand feeding the daily auction. This has seeded a wide ecosystem of derivative projects, sub-treasuries, and real-world activations, and made Nouns a reference point in debates about [open-source and CC0 licensing](https://a16zcrypto.com/posts/article/introducing-nft-licenses/) for on-chain brands.

## Forking: exit rights at treasury scale

In 2023 Nouns shipped a **fork mechanism** as part of its V3 governance upgrade — a treasury-scale implementation of [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights). When holders of at least 20% of the Nouns signal a fork, dissenting members can split off into a new "fork DAO," leaving with their **proportional share of the treasury's ETH and assets**, inside which they can then exit and claim funds at any time. The first fork in mid-2023 saw a large minority leave with a corresponding slice of the treasury; a [second fork followed in 2024](https://blockworks.co/news/nouns-fork-two-dao-treasuries-spending). Nouns thereby became the most prominent case study for a live tension in DAO design: an exit right protects minorities from [majority capture](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), but it also lets holders arbitrage any gap between a token's market price and its redeemable treasury value — the same dynamic that later surfaced in [GnosisDAO's 2026 redemption vote](https://forum.gnosis.io/t/gip-150-should-gnosisdao-let-gno-holders-redeem-their-pro-rata-share-of-the-treasury/12263). To give the on-chain organization legal standing, Nouns has since adopted a [DUNA](https://docs.nouns.wtf/) (Decentralized Unincorporated Nonprofit Association) wrapper — see [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures).

## How Caper approaches this

Nouns and [capers](/wiki/foundations/what-is-a-caper) share the instinct that a member should never be captive: both fund a treasury from ongoing on-chain buying and both give holders a way out. The difference is the shape of the exit. A Nouns fork requires coordinating a 20% threshold and spinning up an entire fork DAO to leave with a share of assets. A caper builds the exit into the base layer — any holder can [redeem individually at any time](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), burning their tokens and vote record for a share of the [treasury](/wiki/markets/raising-funds) sized by their canonical vote weight, with no coordination threshold and no separate organization to stand up. And where Nouns funds its treasury through a daily NFT auction, a caper funds its through a continuous [bonding curve](/wiki/markets/bonding-curve) that also gives every holder a live price to [sell against](/wiki/markets/trading) between exits.

## The Sandbox DAO (SAND)

URL: https://caper.network/wiki/daos/social/the-sandbox-dao
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Name** | The Sandbox DAO _(paused 2026)_ |
| **Type** | Metaverse / gaming community DAO steering grants and platform proposals for [The Sandbox](https://www.sandbox.game/), the voxel world owned by [Animoca Brands](https://www.animocabrands.com/animoca-brands-acquires-pixowl) |
| **Token** | SAND — 3,000,000,000 fixed supply ([ERC-20](https://etherscan.io/token/0x3845badade8e6dff049820680d1f14bd3903a5d0) on Ethereum, bridged to Polygon), plus LAND NFTs as voting power |
| **Governance** | Sandbox Improvement Proposals (SIPs) debated on [forum.sandboxdao.com](https://forum.sandboxdao.com/) and voted on [Snapshot](https://snapshot.org/#/s:sandboxdao.eth) (space `sandboxdao.eth`), reviewed by a Council |
| **Membership bar** | 5 SAND or 1 [LAND](https://www.sandboxdao.com/); 1 LAND counts as 4,500 SAND of voting power |
| **Lifetime** | 39 SIPs between May 2024 and February 2026; [SIP-39](https://snapshot.org/#/s:sandboxdao.eth/proposal/0xd4e77cc75434f71ac27e78cd62f92ec07e0cee59cc673c68f2a1949d56d99a4f) paused the DAO effective 25 February 2026, dormant from 1 April 2026 |
| **Related** | [Decentraland DAO](/wiki/daos/social/decentraland-dao), [ApeCoin DAO](/wiki/daos/social/apecoin-dao), [Voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy), [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) |

**The Sandbox DAO** was the community-governance layer of [The Sandbox](https://www.sandbox.game/), a voxel metaverse platform whose developer Pixowl was [acquired by Animoca Brands in August 2018](https://www.animocabrands.com/animoca-brands-acquires-pixowl) for roughly US$4.9m. It ran from May 2024 to February 2026, funded 38 proposals with more than 3 million SAND, and then voted itself into dormancy. It is one of the cleanest public records of a corporate-sponsored DAO's full arc — launch, activity, decay, pause — because every vote is still readable on-chain.

Its value to anyone studying DAO governance is not the metaverse. It is the turnout curve: the DAO's first proposals drew over a thousand voters, and the proposal that shut it down drew 33.

## From studio subsidiary to DAO

SAND launched in 2020 as the platform's ERC-20 currency, with a [fixed 3 billion supply](https://docs.sandbox.game/en/owners/sand) used for purchases, staking, and — eventually — governance. The DAO itself came later. The Sandbox described the plan as [progressive decentralization](https://sandboxgame.medium.com/progressive-decentralization-sips-and-the-sandbox-dao-0335307f8098): a staged handover rather than an immediate one, with Phase One putting SIPs to a community vote while staff kept running operations, Phase Two loosening that dependency, and Phase Three intended as full community control.

Voting opened on 28 May 2024 with a [25 million SAND treasury](https://cointelegraph.com/news/the-sandbox-launches-dao-25m-sand-treasury). The first batch was constitutional: SIP-1 introduced the DAO, SIP-2 established The Sandbox Foundation, and SIP-3 set its initial budget. It never reached Phase Three.

## How the voting worked

Governance was off-chain and token-weighted, run in the [sandboxdao.eth Snapshot space](https://snapshot.org/#/s:sandboxdao.eth). The mechanics were unusually legible for a corporate-adjacent DAO:

- **Eligibility:** 5 SAND or a single LAND plot made you a member. Voting power summed SAND and LAND holdings across Ethereum and Polygon, with [1 LAND converted to 4,500 SAND](https://www.sandboxdao.com/) of weight — a deliberate tilt toward landowners over token holders.
- **Cadence:** a new batch of SIPs went live every other Wednesday, each open for a 14-day voting period.
- **Quorum:** 30,000,000 voting power, with weighted voting across Yes / No / Abstain.
- **Delegation:** holders could [delegate voting power](https://www.sandboxdao.com/delegation) without moving tokens, the standard Snapshot pattern (see [delegated voting](/wiki/dao-governance/concepts/voting/voting-and-delegation)).
- **Council review:** a Council including co-founder Sebastien Borget and Animoca chairman Yat Siu reviewed every SIP and [could veto proposals](https://cointelegraph.com/news/the-sandbox-launches-dao-25m-sand-treasury) on grounds of legality, misalignment, or redundancy.

That last item matters more than it reads. A veto held by the sponsoring company's founders is a hard ceiling on how decentralized the DAO could become, whatever the phase roadmap promised — the same structural tension covered under [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) and [security councils](/wiki/dao-governance/concepts/fundamentals/security-councils).

## What it actually funded

SIPs fell into categories the DAO framed as [Game Content, Sandbox for Good, NFT, and Platform](https://sandboxgame.medium.com/progressive-decentralization-sips-and-the-sandbox-dao-0335307f8098). In practice the spending mix was grants, events, and marketing rather than protocol parameters:

- **Causes:** SIP-4 funded carbon capture with Net Zero Company; SIP-5 supported the Red Cross.
- **Platform features:** SIP-6 (Magic Palette design tool), SIP-16 (in-game inventory filter), SIP-21 (window sizing options for the game client).
- **Programs:** SIP-11 funded the Ambassador Program, [SIP-25 established the Sandbox DAO Grants Program](https://www.sandboxdao.com/proposals), and SIP-27 elected Domain Allocators to steer it.
- **Cross-DAO:** SIP-20 set up a collaboration framework whose first phase was participating in [ApeCoin DAO](/wiki/daos/social/apecoin-dao) governance — one metaverse DAO delegating attention to another, months before both wound down.

By its own accounting in [SIP-39](https://snapshot.org/#/s:sandboxdao.eth/proposal/0xd4e77cc75434f71ac27e78cd62f92ec07e0cee59cc673c68f2a1949d56d99a4f), the DAO distributed more than 3 million SAND across 38 SIPs, drew members from more than 20 countries, and generated roughly 8,000 forum posts across 500 threads.

## The turnout collapse

Every SIP is public on Snapshot, which makes participation decay measurable rather than anecdotal. Voter counts, first proposal to last:

| Proposal | Date | Voters |
| --- | --- | --- |
| SIP-3 — Initial Budget for the DAO | May 2024 | 1,161 |
| SIP-11 — Ambassador Program | Aug 2024 | 830 |
| SIP-19 — UGC Platform Development Team | Jan 2025 | 251 |
| SIP-27 — Domain Allocator Election | Apr 2025 | 187 |
| SIP-35 — Magic Realms | Aug 2025 | 91 |
| SIP-38 — Art Commission Grant | Dec 2025 | 31 |
| SIP-39 — Pausing The Sandbox DAO | Feb 2026 | 33 |

Participation fell roughly 97% over twenty months while the Snapshot space kept accumulating followers — over 14,000 by the end. Voting _power_ did not fall with it: SIP-3 cleared with about 40 million voting power and SIP-39 with about 70 million. Fewer people were voting, and the ones who stayed carried more weight each.

The decision to wind the DAO down was therefore made by 33 addresses. That is not a scandal — it is the ordinary end state of token-weighted, low-stakes governance, and the reason [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) is a structural risk rather than a community-management problem. A quorum denominated in tokens rather than voters will keep clearing long after the electorate has left.

## SIP-39: pausing the DAO

[SIP-39, "Pausing The Sandbox DAO"](https://snapshot.org/#/s:sandboxdao.eth/proposal/0xd4e77cc75434f71ac27e78cd62f92ec07e0cee59cc673c68f2a1949d56d99a4f), opened on 11 February 2026 and closed on 25 February 2026. It passed with roughly 56.1 million voting power for, 6.3 million against, and 7.6 million abstaining, from 33 voters.

The proposal was candid about why. The DAO's mandate had drifted from where the platform was going with "The Sandbox 3.0", and — the more concrete problem — operating costs were invoiced in USD and EUR while the treasury was denominated in SAND, so a falling SAND price meant selling steadily more of the treasury to cover the same fixed bills. This is the [treasury-denomination mismatch](/wiki/dao-governance/concepts/treasury/dao-treasury-management) that has caught many DAOs holding a single volatile native asset against fiat liabilities.

What "paused" means in practice: no new funding or grant SIPs are accepted, curated, or put to a vote; no new governance initiatives, elections, or mandates; existing SIPs with signed contracts run to completion or settle under their notice terms while uncontracted ones are closed out; and responsibility for finance, assets, and contracts transfers to The Sandbox and The Sandbox Foundation. The transition ran to 31 March 2026, with dormant mode from 1 April 2026. In the [forum discussion](https://forum.sandboxdao.com/t/sip-39-pausing-the-sandbox-dao/3552), the team put the remaining treasury at about US$4.4m USDC of the roughly US$6.8m originally received, with a maintenance budget of US$44,400 to preserve assets during the pause.

Contributors in that thread were not persuaded that a pause is reversible. One drew the comparison directly to [ApeCoin DAO](/wiki/daos/social/apecoin-dao), which had been [dissolved into a Yuga Labs company](https://www.coindesk.com/markets/2025/06/06/yuga-labs-proposes-scrapping-apecoin-dao-launching-apeco) eight months earlier; another described the pause as "a way to quietly make the DAO fade away". Reactivation is possible in principle — it would take a SIP, and SIPs are exactly what the pause stops.

## What DAO builders can take from it

Three things generalize beyond the metaverse sector:

- **A grants DAO next to a company is a budget line, not a polity.** The Sandbox DAO never governed the product — it allocated a company-funded pot toward events, causes, and feature requests. When the sponsor's strategy changed, there was no independent mandate to defend, which is why the pause passed almost unopposed.
- **Token-denominated quorum hides voter flight.** Because quorum was 30 million voting power rather than a headcount or a share of holders, the DAO kept clearing its bar while 97% of its voters left. Any DAO that wants participation to be a real constraint has to measure it as one — see [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).
- **A treasury in your own token is a short position on your own fortunes.** Fixed obligations in fiat against a reserve in SAND meant the DAO's spending power fell exactly when its ecosystem needed it most. Compare [Decentraland DAO](/wiki/daos/social/decentraland-dao), which faces the same structural exposure through MANA, and the diversification arguments under [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## How Caper approaches this

The uncomfortable part of a pause is what it does to the people who stayed. Once no new SIPs can be raised, a member's only remaining lever is to sell into whatever market exists for the token — the governance surface simply closes, and nothing about the treasury is claimable by them.

Caper's design does not depend on the DAO being open for business. A member calls `exit` directly: it pays out a share of the treasury computed as their canonical vote weight — _(governance tokens held × vote tokens held) / (total vote supply × circulating supply)_ — burns their vote tokens, and sells their governance tokens back into the bonding curve for XRD. No proposal, no quorum, no council review, and no dependency on anyone else still voting. A caper that goes quiet is one its members can still leave with something, which is the point of an [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) as distinct from a market. See [what is a caper](/wiki/foundations/what-is-a-caper) and [the bonding curve](/wiki/markets/bonding-curve).

## Yield Guild Games (YGG)

URL: https://caper.network/wiki/daos/social/yield-guild-games
Updated: 2026-08-11

| Name | Yield Guild Games (YGG) |
| --- | --- |
| Type | Gaming guild DAO — play-to-earn / Web3-gaming coordination |
| Founded | 2020 — Gabby Dizon, Beryl Li, and pseudonymous co-founder "Owl of Moistness" |
| Token | YGG (ERC-20, Ethereum) — 1,000,000,000 max supply, fully minted; governance + vault staking |
| Structure | Main DAO + game/regional SubDAOs (YGG SEA, YGG Japan, IndiGG); YGG Vaults for staking |
| Signature model | Scholarships — the guild owns the game NFTs, "scholars" play them and share the yield |
| 2024→ | Guild Protocol / Onchain Guilds — soulbound guild badges + achievement SBTs |
| Governance | [Snapshot space `yieldguild.eth`](https://snapshot.box/#/s:yieldguild.eth) — one-token-one-vote on the YGG ERC-20; **one proposal in its history** (November 2021) |
| Status | Active DAO; publishing arm YGG Play sunset 31 July 2026 (yggplay.fun no longer resolves), pivoting to an "AI data economy" |

**Yield Guild Games (YGG)** is the canonical _gaming-guild DAO_: a decentralized organization that pools capital to buy the NFTs a blockchain game requires, then lends those assets to players who cannot afford them and shares the in-game yield. It is the first ecosystem-directory entry whose members coordinate around _playing games together_ rather than around a protocol, a treasury, a collectible, or a research portfolio — the [gaming/guild archetype](/wiki/dao-governance/concepts/fundamentals/types-of-daos) that [social](/wiki/daos/social/friends-with-benefits), [venture](/wiki/daos/investment/the-lao), and [collector](/wiki/daos/investment/pleasrdao) DAOs do not cover.

YGG grew out of the Philippines during the 2020–21 pandemic, when co-founder Gabby Dizon began lending his [Axie Infinity](https://academy.binance.com/en/articles/what-is-yield-guild-games-ygg) game assets to unemployed players so they could earn income they otherwise had no capital to unlock. Formalized as a DAO in 2020 (Dizon, [Beryl Li, and "Owl of Moistness"](https://iq.wiki/wiki/yield-guild-games)), YGG became the defining institution of the play-to-earn era — and, as that era boomed and then collapsed, a live case study in what happens to a guild when the game economies it depends on stop paying out.

## The scholarship model

YGG's original mechanism is the **scholarship**. Play-to-earn games like Axie Infinity required a player to own NFTs (a team of Axies) before they could earn — a capital barrier that priced out exactly the players in emerging markets who most wanted the income. YGG's DAO treasury bought those NFTs at scale and lent them to _scholars_, who played and returned a share of what they earned.

The split is three-way: the [scholar keeps the majority of what they earn](https://academy.binance.com/en/articles/what-is-yield-guild-games-ygg) (commonly ~70%), and the remainder is divided between the guild and a _community manager_ — a mentor responsible for recruiting, training, and supporting a cohort of scholars. That human layer, not the token, was the guild's real product: a recruitment-and-training pipeline that turned idle treasury NFTs into productive, income-generating players. By August 2021 YGG had [over 4,700 scholars who had collectively earned more than $8.6 million](https://coinbureau.com/review/yield-guild-games).

The model's fragility is the same as its strength: scholar income is only as durable as the underlying game's token economy. When Axie's rewards token depreciated through 2022, scholar earnings fell with it, and the guild's asset-lending thesis had to broaden beyond any single game — the pressure that later pushed YGG toward being infrastructure rather than a single guild.

## Token, Vaults, and SubDAOs

The **YGG token** is an Ethereum ERC-20 with a [maximum supply of 1,000,000,000](https://tokenomist.ai/yield-guild-games), allocated roughly 45% to community programs, 22.4% to investors, 15% to founders, 13.3% to the treasury, 2.5% to the public sale, and 1.75% to advisors. That cap is fully minted: `totalSupply()` on `0x25f8087ead173b73d6e8b84329989a8eea16cf73` returns exactly 1,000,000,000 × 1018, read at Ethereum block 25,730,773. Its July 2021 [IDO on SushiSwap’s MISO sold out in 31 seconds](https://coinbureau.com/review/yield-guild-games), raising roughly $12.5 million. The token confers governance rights — holders can submit and vote on proposals over strategy, investments, and treasury use — on a one-token-one-vote basis, meaning voting power tracks the freely transferable, purchasable YGG balance.

**YGG Vaults** are the staking primitive. Each [vault represents the reward stream from one or all guild revenue sources](https://medium.com/yield-guild-games/yield-guild-games-whitepaper-four-big-takeaways-d3e44172609b); stakers receive rewards in proportion to the tokens they stake and the revenue the assigned source generates. It is a way to route real, activity-derived yield back to token holders rather than emitting fresh inflation.

**SubDAOs** compartmentalize the guild. A [SubDAO](https://web.archive.org/web/20260222213610/https://www.yieldguild.io/YGG-Whitepaper-English.pdf) is a specialized branch organized around either a specific game or a specific region — game SubDAOs concentrate the operational know-how of one title's economy, while regional SubDAOs such as _YGG SEA_ (Southeast Asia), _YGG Japan_, and _IndiGG_ (India) localize recruitment, language, and community. Each can carry its own leadership and, in some cases, its own sub-token, letting local operators who understand a game or market run semi-autonomously under the main DAO.

## From asset guild to Guild Protocol

YGG's most consequential turn is the move from _owning the assets_ to _issuing the reputation_. With its [Guild Protocol Concept Paper (September 2024)](https://medium.com/yield-guild-games/onchain-guilds-a-web3-primitive-3bc282c36cfb), YGG reframed itself as infrastructure any guild can build on — "Onchain Guilds," which YGG calls "a web3 primitive, serving as the building blocks for guilds across the ecosystem."

An Onchain Guild has three parts: a **member list** verified onchain and an **SBT given to members upon joining**; a **multi-sig treasury wallet** whose earnings are "distributed evenly among guild members permissionlessly and trustlessly through a smart contract"; and **activities** (quests) that earn reputation. The load-bearing element is the [soulbound token](/wiki/dao-governance/concepts/membership/soulbound-tokens): YGG-issued, non-transferable badges that signal guild membership and record achievements. Since 2022, YGG has issued these achievement SBTs through its questing programs — the _Guild Advancement Program (GAP)_ and Superquests — "to recognize and reward in-game excellence as well as community contributions."

This is the same intuition behind [Vitalik Buterin’s "soulbound" proposal](/wiki/dao-governance/concepts/membership/soulbound-tokens): some things — reputation, membership, contribution history — should not be transferable, because their whole value is that they were _earned_ by a specific participant. YGG applies it to _guild reputation_. Notably, though, it stops short of applying it to _governance_: YGG's own votes still ride the buyable YGG token, so a member's soulbound reputation and their voting power live in two separate places.

## The publishing detour and the AI-data pivot

As play-to-earn cooled, YGG tried to become a game _publisher_. It launched **YGG Play** and, on [October 15, 2025](https://playtoearn.com/news/ygg-play-launchpad-debuts-mid-october-with-lol-lands-lol-token), opened the YGG Play Launchpad with $LOL, the token of its first in-house game _LOL Land_ — a browser board game on the Abstract chain in what YGG branded the "casual degen" genre (short-session games with real token stakes). LOL Land drew [over 630,000 monthly users and multi-million-dollar revenue](https://messari.io/report/ygg-ygg-play-and-lol-land-launch) at its peak, and by YGG's own accounting the publishing arm [crossed $9 million in lifetime revenue by the end of Q1 2026](https://yieldguild.io/news/an-update-on-ygg-and-our-next-chapter-sunsetting-ygg-play) across nine signed games.

It did not last. On [July 6, 2026](https://yieldguild.io/news/an-update-on-ygg-and-our-next-chapter-sunsetting-ygg-play), YGG announced it was sunsetting the YGG Play business unit, citing the "10/10 crash" — the October 10, 2025 macro shock that triggered "the largest liquidation in crypto history, wiping out over $19 billion" in leveraged positions inside 24 hours — and concluding that "YGG Play simply cannot be commercially sustainable in this climate." The human cost was stated plainly in the same post: **35 people** across the unit's functions, with YGG publishing a talent contact address to place them.

Unusually for a crypto wind-down, the sunset was published as a _dated operational schedule_ and then executed on it. The [sunset guide of July 8](https://yieldguild.io/news/ygg-play-sunset-guide-important-dates-next-steps-and-faqs) set out the sequence: purchases and quests disabled 9 July at 3:00 PM SGT; _LOL Land_ and _Waifu Sweeper_ playable but unpurchasable until 31 July; the YGG Play platform, the Launchpad (`app.yggplay.fun`) and Community Questing (`community.yggplay.fun`) shut down 31 July; two third-party titles, GIGACHADBAT and Ragnarok Breaker, handed to their studios (Delabs Games and Planetarium Labs) on 1 August; and the 2026 YGG Play Summit cancelled outright. Holders were told to unstake $YGG and redeem in-game point balances before the 31 July snapshot, after which balances would be converted to $YGG and pushed to the associated wallet with no support available. The deadline held: as of this revision `yggplay.fun` and `www.yggplay.fun` both return a Cloudflare error 1000 ("DNS points to prohibited IP") — the domain's records are gone, not merely parked — and YGG's own announcement now lives on the parent domain, [yieldguild.io/news](https://yieldguild.io/news/an-update-on-ygg-and-our-next-chapter-sunsetting-ygg-play).

The next chapter is the **AI data economy**: a B2B pipeline built on gaming datasets, aimed at the [$3.9 billion AI training-dataset market](https://yieldguild.io/news/an-update-on-ygg-and-our-next-chapter-sunsetting-ygg-play) YGG cites from Grand View Research, on the argument that models trained on sterile logic need records of human irrationality and that games are where people make complex split-second decisions at volume. The existing "YGG Alerts" channel was rebranded AI Alerts and pointed at remote AI-training work in the Philippines, which YGG says drew 27,000 applications in its first five days. The same post disclosed the balance sheet behind the decision: a treasury of **$20.6 million** at the end of Q1 2026, of which **$6.2 million** sat in stablecoins, T-bills and large-cap tokens, and a restructuring that "extended our operating runway to four years."

The arc is the honest lesson of the whole play-to-earn era compressed into one organization: a guild built on games that paid, that had to keep reinventing what it _was_ — asset lender, then reputation infrastructure, then publisher, now data business — each time the ground under the previous model gave way. The durable residue is the guild network and the soulbound reputation layer; the yield-bearing thesis proved cyclical.

## One proposal in five years

Everything in the section above — retiring two of the organization's own games, shutting three of its domains, releasing 35 people, cancelling its flagship event, and redirecting a $20.6 million treasury into a different industry — was announced by the company. None of it was voted on by the token holders the [whitepaper](https://web.archive.org/web/20260222213610/https://www.yieldguild.io/YGG-Whitepaper-English.pdf) describes as governing YGG.

That is checkable rather than rhetorical. YGG's [official Snapshot space is `yieldguild.eth`](https://snapshot.box/#/s:yieldguild.eth) — self-described "Official YGG snapshot," created 6 October 2021, with a single `erc20-balance-of` strategy over the YGG ERC-20 and 224 followers. Queried through [Snapshot's public GraphQL hub](https://hub.snapshot.org/graphql), its `proposalsCount` is **1**. The one proposal is ["Create YGGSPL subDAO?"](https://snapshot.box/#/s:yieldguild.eth/proposal/0xce706de1e834b7a912dd1fa1cecd93612b321fe83da44cc9e2df384ef643842b), opened 8 November 2021 and closed 16 November 2021: 74 voters, 621,186.75 YGG in favour, zero against. That winning side is **0.062%** of the token's 1,000,000,000 supply. The only other space carrying the name, `yggdao.eth`, has never held a proposal at all.

So a guild that issues [soulbound reputation badges](/wiki/dao-governance/concepts/membership/soulbound-tokens) to tens of thousands of members has, in four and a half years, put exactly one question to a token vote — and the largest decisions in its history were not among them. This is the failure mode a proposal count never shows on a dashboard: not a contested vote lost, not a delegate cartel, and not deliberate [governance minimization](/wiki/dao-governance/concepts/fundamentals/governance-minimization) either, but [a governance venue that simply never convened](/wiki/dao-governance/concepts/analysis/voter-apathy). The DAO label survived; the practice of using it did not. Read alongside [ApeCoin DAO's dissolution vote](/wiki/daos/social/apecoin-dao) and [the Aragon Association winding itself up](/wiki/daos/infrastructure/aragon-dao), it is a third way a DAO stops being one — and the hardest to see, because nothing ever happens.

## How Caper approaches this

YGG and [Caper](/wiki/foundations/what-is-a-caper) converge on one idea and diverge on where they put it. Both treat a **soulbound, non-transferable token** as the honest record of participation — YGG issues them as guild badges and achievement SBTs, and Caper mints a "Soulbound proof-of-vote token" (verified against `contracts/core/src/caper_dao.rs`: `DIVISIBILITY_NONE`, non-transferable via a depositor rule locked to the DAO itself, minted one per vote).

The difference is what that soulbound token _controls_. In YGG the SBT is reputation; governance power still rides the buyable YGG balance, so a large enough purchase buys votes. In Caper the earned token is _decisive in the weight itself_: voting power and exit share are both `compute_vote_weight = (t · v) / (V · T)` (in `contracts/logic/src/lib.rs`) — where `t` is a member's [held caper stake](/wiki/markets/bonding-curve), `v` their earned soulbound votes, `V` the total soulbound-vote supply, and `T` tokens in circulation — and `exit()` reuses the exact same helper before burning the vote tokens. That means the part of influence a buyer cannot simply purchase is folded straight into both the vote and the payout.

This is not "your bag doesn't count" — `t` is a multiplier, so stake still matters. It is that a big enough bag _alone_ can't capture control, because `v` has to be earned by showing up and can't be bought or transferred. YGG proved soulbound reputation is worth issuing; Caper puts it on the critical path of who actually decides.

The section above adds the other half of the lesson. A governance venue that is never convened is indistinguishable, from the outside, from one that does not exist — so Caper does not keep a separate venue at all: a caper's [proposals](/wiki/governance/proposals) and its treasury are the same component, and the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is available on any block without anyone scheduling a vote. Where YGG's members had one proposal in five years to express a view, a Caper member who disagrees does not need a proposal to act.

## Aave GHO

URL: https://caper.network/wiki/daos/stablecoins/aave-gho
Updated: 2026-08-03

| Project | GHO (Aave) |
| --- | --- |
| Category | Decentralized overcollateralized stablecoin · CDP |
| Chain | Ethereum + multichain via cross-chain messaging |
| Launched | [12 July 2023](https://www.pymnts.com/cryptocurrency/2023/aave-introduces-gho-stablecoin/), after an Aave governance vote |
| Stablecoin | GHO — USD-pegged, native to the Aave protocol, minted against Aave V3 collateral |
| Governance token | AAVE · stkAAVE (staked in the Safety Module) earns a GHO borrow-rate discount |
| Governance | **Maximally governed** — the borrow rate is a fixed value set by [Aave governance vote](https://governance.aave.com/), not a utilization curve; facilitator mint caps, the discount, and GSM assets are all governance parameters |
| Primary sources | [aave.com/docs](https://aave.com/docs/developers/gho) · [governance.aave.com](https://governance.aave.com/) |

**GHO** is a decentralized, [overcollateralized stablecoin native to the Aave protocol](https://aave.com/docs/developers/gho): borrowers mint it against collateral supplied to Aave V3, and it holds a US-dollar peg backed by that collateral rather than by fiat reserves. What makes GHO worth cataloguing here is not the peg mechanics but the _control surface_: nearly every lever that governs GHO — the interest rate borrowers pay, how much any given contract may mint, the discount stakers receive, which assets can defend the peg — is a live decision of the [Aave DAO](https://governance.aave.com/). That places GHO at the **maximally-governed pole** of the [DAO governance spectrum](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) — the exact opposite of [Liquity’s ungovernable BOLD](/wiki/daos/stablecoins/liquity), and a clean case study in treating governance itself as monetary policy.

## The facilitator model

GHO is not minted by a single vault. Instead, Aave governance approves **facilitators** — contracts that can [trustlessly mint and burn GHO](https://aave.com/docs/developers/gho) up to a governance-set `bucketCapacity`. The original facilitators were the _Aave V3 Ethereum Market_ (where users borrow GHO against supplied collateral) and a _FlashMinter_; later additions include the GHO Stability Module. Each facilitator’s bucket is a hard, governance-owned ceiling on how much GHO it can bring into existence, so the total supply is bounded by an explicit ledger of votes rather than by market demand alone.

This is a deliberately different answer to “who decides how much stablecoin exists?” than an algorithmic issuer gives. Where [Liquity](/wiki/daos/stablecoins/liquity) lets any borrower mint against ETH under fixed immutable rules, GHO’s supply is gated by a governance-maintained set of facilitators and caps that can be raised, lowered, or revoked by proposal.

## An interest rate set by vote

The defining feature: GHO’s borrow rate is **a fixed number chosen by Aave governance**, not a curve that floats with utilization. Holders vote a rate based on the peg and market conditions, and the protocol charges it uniformly. To make routine adjustments without a full multi-day vote each time, governance delegates a bounded lever to **GHO Stewards**, who can [change the borrow rate by at most 500 bps per two-day period, up to a 25% APR ceiling](https://aave.com/docs/developers/gho), and raise the borrow cap toward a 100M threshold — a guarded, rate-limited delegation rather than open discretion.

Layered on top is a **staker discount**: users who stake AAVE in the Safety Module (stkAAVE) receive a reduction on their GHO borrow rate, applied per staked token up to a per-token GHO cap. The discount rate is itself a governance parameter. The rate a borrower actually pays is therefore a function of three governed inputs — the base rate, their stkAAVE balance, and the per-stkAAVE cap — a striking contrast to a purely mechanical fee.

## The GHO Stability Module and the governed peg

When the peg drifts, GHO does not rely solely on redemption arbitrage. The **GHO Stability Module (GSM)** lets users [swap GHO 1:1 for governance-approved tokens](https://aave.com/docs/developers/gho) (such as major fiat-backed stablecoins), with exposure caps, dynamic fee strategies, and oracle-based price-freeze protections — all governance-configured. If GHO trades above peg, minting and selling into the GSM pushes it down; below peg, buying and burning pulls it up. Because _which_ assets back the GSM and at what caps are votes, the peg backstop is a governance instrument, not a fixed algorithm.

Aave has continued to extend this surface: 2025 brought [stkGHO, anti-GHO, and a savings variant (sGHO)](https://oakresearch.io/en/analyses/innovations/aave-2025-three-horsemen-of-gho-stkgho-anti-gho-sgho) as governance-shaped ways to hold and stabilize GHO, each adding another parameter set the DAO maintains.

## Where it sits on the governance spectrum

GHO and [Liquity’s BOLD](/wiki/daos/stablecoins/liquity) are the two poles of the same design question, and reading them together is the point. Liquity protects a stablecoin by making its rules _immutable_ — no vote can touch the borrow rate or the peg logic, so there is nothing to capture. GHO protects a stablecoin by making its rules _maximally responsive_ — the DAO can retune the rate, the mint caps, and the peg backstop as markets move. Each buys something and pays for it: immutability buys credible neutrality at the cost of adaptability; governance buys adaptability at the cost of a standing [governance attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) and a dependence on votes turning out. The [post-vote-escrow turn](/wiki/daos/lending/pendle-finance) elsewhere in this directory is a third answer again — retiring a governance lever once it has served its purpose.

## How Caper approaches this

Caper is a treasury-and-governance protocol, not a stablecoin issuer, so the honest contrast is about _who_ holds the parameters and whether a dissenter has an exit. On Aave, a borrower or AAVE holder who dislikes a governance-set GHO rate has no structural recourse beyond selling their position — the vote binds everyone who stays. In a [caper](/wiki/foundations/what-is-a-caper), the treasury _is_ the governed object, and two things differ. First, a member’s [vote weight](/wiki/governance/voting) is `(held × votes) / (vote_supply × circulation)` — a product of tokens held and a **soulbound, non-transferable record of having actually voted**, so a large bag alone cannot capture the control surface the way it can accumulate stkAAVE. Second, when you lose a parameter fight you can [exit with your share of the treasury](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) rather than only sell into the market — the majority cannot trap you in a policy you fought. (Mechanics verified against `compute_vote_weight` and `exit` in `contracts/logic/src/lib.rs`; framed at the outcome level, no invented features.)

## Ethena (USDe)

URL: https://caper.network/wiki/daos/stablecoins/ethena
Updated: 2026-08-03

| Name | Ethena (USDe / sUSDe) |
| --- | --- |
| Type | Synthetic-dollar issuer · delta-neutral stablecoin protocol |
| Token | ENA (governance) · sENA (locked ENA) |
| Products | USDe (synthetic dollar), sUSDe (staked savings asset), USDtb (RWA-backed stablecoin) |
| Governance | Ethena Foundation · committee-delegated DAO (Risk Committee) |
| Status | 🟢 Active |
| Founded | 2024 (public mainnet Feb 2024; ENA launched Apr 2024) |
| Website | [ethena.fi](https://ethena.fi) · [docs.ethena.fi](https://docs.ethena.fi) |

**Ethena** issues [USDe](https://ethena.fi), a dollar-denominated _synthetic_ asset that reaches its peg not through fiat in a bank account but through a hedged portfolio of crypto collateral. Ethena's own documentation describes USDe as backed by "a portfolio of assets held by the protocol" and states that it "derives its relative peg stability from holding a diversified portfolio of backing assets and hedging the price-change risk of any volatile holdings" ([docs.ethena.fi](https://docs.ethena.fi)). That design makes Ethena a distinct archetype in the stablecoin directory: not an over-collateralised CDP like [Sky (Maker)](/wiki/daos/stablecoins/sky-dao), [Liquity](/wiki/daos/stablecoins/liquity), or [Aave's GHO](/wiki/daos/stablecoins/aave-gho), and not the immutable, ungoverned float of [Reflexer's RAI](/wiki/daos/stablecoins/reflexer-rai), but a _governed trading operation_ whose stability depends on a live basis trade.

By mid-2026 USDe had grown into one of the largest dollar-like assets in crypto — supply in the multiple billions and cumulative protocol revenue past $250M ([CoinGecko](https://www.coingecko.com/en/coins/ethena)) — while ENA, the governance token, traded well below its 2024 launch high. That gap between a large, working product and a lightly-valued governance token is itself the interesting governance story.

## How USDe holds its peg

USDe is **delta-neutral** by construction. Per the protocol docs, "volatile assets, such as spot crypto and tokenised commodities, are paired with a corresponding short derivatives position so that the combined position is delta-neutral and its dollar value remains relatively stable" ([docs.ethena.fi](https://docs.ethena.fi)). Each USDe is backed by a portfolio that has included staked ETH ([Lido](/wiki/daos/staking/lido-dao)'s stETH), BTC, liquid stablecoins, and real-world assets; the price risk of the volatile leg is hedged with short perpetual-futures and futures positions held at centralised exchanges and off-exchange custodians.

The mechanism is a classic **cash-and-carry basis trade**: long spot, short the perp, collect the funding the market pays to hold that short. It removes directional price exposure but introduces different risks — funding rates can turn negative, exchange counterparties can fail, and collateral must be custodied somewhere. Those are not background details: _which_ exchanges, custodians, and collateral are permitted is exactly what Ethena's governance decides.

## sUSDe — the savings asset and its yield

Holders who stake USDe receive **sUSDe**, described by Ethena as "the protocol's autonomously and permissionlessly created globally accessible savings asset." sUSDe is a reward-accruing wrapper: "the USDe value of sUSDe grows on its own" as protocol revenue is added to the pool. Ethena lists the revenue sources as "funding and basis spread… lending revenue… real-world asset yield… liquid stablecoin rewards" ([docs.ethena.fi](https://docs.ethena.fi)).

Crucially, the yield is _path-dependent on funding markets_. When perpetual funding is richly positive, sUSDe has paid double-digit APYs; when funding compresses or turns negative, yield falls. Ethena's design caps the downside for stakers — "sUSDe can only accrue positive or flat rewards while staking USDe; periods of negative protocol revenue are not passed on to sUSDe" — and pushes that cost onto the Reserve Fund instead.

## The Reserve Fund

Ethena's solvency backstop is the **Reserve Fund**: "a pool of assets held by the protocol as an additional margin of safety for USDe." When "protocol revenue would otherwise be negative… the Reserve Fund is designed to bear that cost" ([docs.ethena.fi](https://docs.ethena.fi)). It absorbs negative-funding regimes and other stress so that the peg and staker yields are insulated from short bursts of loss.

The Reserve Fund is where product design and governance meet the balance sheet: its size, composition, and drawdown rules are governed decisions, and the market treats it as the number that says whether USDe can survive a sustained negative-funding stretch. It is the analogue of a CDP protocol's surplus buffer or a [DAO treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management)'s runway — but here it directly underwrites a live trading book.

## Governance: ENA, sENA, and the committee model

**ENA** is Ethena's governance token; locking it mints **sENA**, a liquid receipt that earns rewards and remains usable across DeFi. Rather than voting line-by-line on operations, Ethena runs a **committee-delegated** DAO: "the vast majority of decisions (other than those which the committees deem outside the scope of their remit) are delegated by the DAO to the relevant committees" ([docs.ethena.fi](https://docs.ethena.fi)).

The central body is the **Risk Committee**, whose "mandate is to generally identify, evaluate, and manage risk within the ecosystem," staffed by rotating members on fixed terms, with proposals subject to a multi-day deliberation window before they take effect ([gov.ethenafoundation.com](https://gov.ethenafoundation.com)). In practice the committee steers the levers that make or break a delta-neutral dollar: the whitelist of exchanges and custodians, the collateral mix, hedge venues, and Reserve Fund policy. This makes Ethena a near-opposite pole to RAI's ungovernance — here, _who sits on the committee governing where billions of collateral rests is close to the whole ballgame_.

## USDtb, BUIDL, and institutional distribution

Alongside USDe, Ethena issues **USDtb**, a more conservative stablecoin backed primarily by [BlackRock's tokenised money-market fund BUIDL](https://www.theblock.co/post/331013/ethenas-much-anticipated-usdtb-stablecoin-backed-by-blackrocks-buidl-token-goes-live) and issued via Anchorage Digital, with 24/7 atomic swaps into BUIDL built with [Securitize](https://www.theblock.co/post/358799/ethena-labs-securitize-enable-24-7-atomic-swaps-between-usdtb-and-blackrocks-tokenized-fund). In June 2026 BlackRock and Ethena [deepened that collaboration](https://www.theblock.co/post/405670/blackrock-ethena-partnership-usde), giving institutions on BlackRock's Aladdin platform greater access to Ethena's products and adding a $100M liquidity facility through Securitize.

The two-product split is itself a governance statement: USDe carries the basis-trade yield and its risks; USDtb is the RWA-backed, distribution-friendly instrument for institutions that want a tokenised dollar without the hedge. Both live under the same DAO and committee structure.

## How Caper approaches this

Ethena is the clearest case for why _who holds decisive influence_ matters. Its "stablecoin" is not immutable code — it is a governed trading book, and the committee that sets the exchange whitelist, collateral mix, and Reserve Fund policy effectively directs where billions of dollars of backing sit. Capture that committee and you capture the protocol.

A [caper](/wiki/foundations/what-is-a-caper) draws the line differently. The bonding-curve collateral that backs a caper's token is held in a protocol-controlled vault and is **never** movable by a governance vote — governance acts only on a separate treasury, and only through typed `PAYOUT`/`INVEST`/`VOTE` proposals, so the reserve that underwrites redemptions can't be voted away. And the decisive slice of voting weight is earned, not bought: the canonical weight is `w = (t · v) / (V · T)` (verified in `contracts/logic/src/lib.rs`, `compute_vote_weight`), where `v` is a _soulbound_ proof-of-vote token — zero-divisibility, non-transferable, minted one per ballot cast — and [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) redemption reuses that same weight before burning the tokens. Holdings still count (`t` is a multiplier, so this is not "bagless"), but a well-funded newcomer cannot simply buy a controlling share of the influence that steers the treasury. Where Ethena concentrates consequential control in an elected committee over a live book, a caper keeps its collateral untouchable and makes control something you accrue by participating.

## References

- [Ethena documentation — USDe backing, delta-neutral design, sUSDe, Reserve Fund, governance](https://docs.ethena.fi)
- [Ethena Foundation governance forum](https://gov.ethenafoundation.com)
- [The Block — BlackRock's Aladdin adds deeper support for Ethena's stablecoin products (June 2026)](https://www.theblock.co/post/405670/blackrock-ethena-partnership-usde)
- [The Block — USDtb, backed by BlackRock's BUIDL, goes live](https://www.theblock.co/post/331013/ethenas-much-anticipated-usdtb-stablecoin-backed-by-blackrocks-buidl-token-goes-live)
- [CoinGecko — Ethena (ENA) market data](https://www.coingecko.com/en/coins/ethena)

## Frax Finance

URL: https://caper.network/wiki/daos/stablecoins/frax-finance
Updated: 2026-07-19

|  |  |
| --- | --- |
| **Name** | Frax Finance (Frax DAO) |
| **Type** | Full-stack DeFi protocol — stablecoin issuer, liquid-staking, lending, DEX and an OP-Stack Layer 2 (Fraxtal) |
| **Founded** | 2020 (Sam Kazemian, Travis & Stephen Moore); FRAX stablecoin launched 20 Dec 2020 |
| **Governance token** | FRAX (renamed from FXS in the April 2025 [North Star](https://gov.frax.finance/t/fip-428-frax-north-star-proposal-v2/3652) upgrade) — originally [100,000,000 fixed max supply](https://docs.frax.finance/fxs-and-vefxs/frax-share-fxs-distribution) with halving emissions |
| **Governance model** | [veFXS/veFRAX](https://docs.frax.finance/fxs-and-vefxs/vefxs) — vote-escrow (lock up to 4 years for up to 4× voting weight), non-transferable |
| **What it governs** | Protocol parameters, collateral policy, and [gauge weights](https://docs.frax.finance/fxs-and-vefxs/gauge) that direct token emissions to pools |
| **Links** | [frax.finance](https://frax.finance/) · [docs](https://docs.frax.finance/) · [governance forum](https://gov.frax.finance/) · [@fraxfinance](https://x.com/fraxfinance) |

**Frax Finance** is one of DeFi's oldest and most restlessly-redesigned protocols. It launched on 20 December 2020 with the first [fractional-algorithmic stablecoin](https://docs.frax.finance/): a dollar token (**FRAX**) that was only _partially_ backed by hard collateral, with the remainder held to peg by an algorithm that minted and burned a second, volatile [governance token](/wiki/dao-governance/concepts/treasury/dao-tokenomics) (**FXS**). Where [Maker/Sky](/wiki/daos/stablecoins/sky-dao) over-collateralised and Terra went fully algorithmic, Frax sat deliberately in between — and, unlike Terra, survived the 2022 stablecoin collapse. Over five years it grew from that single idea into a full-stack ecosystem — liquid staking (frxETH), lending (Fraxlend), a DEX (Fraxswap), a wrapped-BTC (frxBTC) and its own OP-Stack rollup, [Fraxtal](https://docs.frax.finance/frax-v3-100-cr-and-more/fraxtal) — all steered by a single vote-escrow governance layer.

## The fractional-algorithmic stablecoin and AMOs

FRAX opened at a 100% **collateral ratio** (fully backed by USDC) and was designed to lower that ratio as the market showed confidence, letting the algorithm carry the uncollateralised slice; by 2022 the CR had fallen to roughly [82%](https://messari.io/report/frax-a-fractional-algorithmic-stablecoin). The protocol's signature invention arrived in late 2021: **[Algorithmic Market Operations](https://docs.frax.finance/) (AMOs)** — autonomous smart-contract controllers that put idle collateral to work (lending it, providing liquidity, running yield strategies) under one hard invariant: _an AMO may never break the FRAX peg_. AMOs turned the treasury from a static reserve into a programmable balance sheet. After the 2022 depeg contagion, veFXS holders reversed course entirely: [FIP-188](https://gov.frax.finance/t/fip-188-increase-cr-to-100/2147) (the "FXG vote", February 2023 — [~98% in favour](https://www.coindesk.com/markets/2023/02/22/frax-finance-votes-to-fully-collateralize-its-1-billion-stablecoin)) set FRAX on a path _back_ to a 100% collateral ratio, which the protocol reached over the following months — a governance decision to trade the capital-efficiency of the fractional model for the trust of full backing.

## veFXS: vote-escrow governance and the gauge system

Frax governs through a [Curve](/wiki/daos/dexs/curve-dao)-derived **vote-escrow** model. Locking FXS produces **veFXS**: one FXS locked for the maximum [four years](https://docs.frax.finance/fxs-and-vefxs/vefxs) yields 4 veFXS, and the balance decays linearly toward 1:1 as the lock runs down. veFXS is explicitly _"not a transferable token nor does it trade on liquid markets"_ — it is an account-bound weight, not an asset. Each veFXS carries one vote over protocol parameters and, crucially, over **[gauge weights](https://docs.frax.finance/fxs-and-vefxs/gauge)**: the weekly allocation of FXS emissions across pools that integrate FRAX. Cash flow earned across the stack (AMOs, Fraxlend, Fraxswap) is typically used to buy FXS from the market and distribute it to veFXS lockers as yield — tying governance rewards to protocol revenue. This is the same [vote-escrow](/wiki/dao-governance/concepts/voting/token-weighted-voting) primitive that made [Convex](/wiki/daos/lending/convex-finance) the kingmaker of the Curve Wars, and Frax was itself a major combatant, amassing a large [vlCVX position](https://tokenbrice.xyz/crv-wars-l2/) to steer Curve emissions toward its own pools.

## Fraxtal and the North Star governance overhaul

In February 2024 Frax launched **[Fraxtal](https://docs.frax.finance/frax-v3-100-cr-and-more/fraxtal)**, an [OP-Stack rollup](https://l2beat.com/scaling/projects/fraxtal) whose blockspace-incentive system (**Flox**) rewards users and developers with **FXTL points** for spending gas and deploying used contracts. The defining governance event came in 2025: [**FIP-428, the "North Star" proposal**](https://gov.frax.finance/t/fip-428-frax-north-star-proposal-v2/3652) — moved to a Snapshot vote on 18 March 2025 and executed on 29 April 2025 — collapsed the two-token branding and rewrote the tokenomics. FXS was renamed **FRAX** and made Fraxtal's gas token (replacing frxETH; the old ERC-20 became a `wFRAX` wrapper); veFXS became **veFRAX**; and the original FRAX stablecoin was renamed _"Legacy Frax Dollar"_, with frxUSD taking over as the flagship dollar. (For a contrasting stablecoin design that reaches its peg by hedging volatile collateral rather than over-collateralising, see [Ethena's USDe](/wiki/daos/stablecoins/ethena).) Most consequentially for holders, North Star retired FXS's [fixed 100M cap and halving schedule](https://docs.frax.finance/fxs-and-vefxs/frax-share-fxs-distribution) in favour of a **tail emission**: ~8% annual issuance declining 1%/year to a 3% floor over five years — turning a deflationary share into a mildly-inflationary network commodity to fund Fraxtal security and FXTL conversions. A DAO voting to re-issue its own supply schedule is one of the sharper live examples of governance reaching all the way down to a token's monetary policy.

## How Caper approaches this

Frax is a study in governance _doing real work_: veFXS lockers have voted the collateral ratio down and back up, redirected emissions pool by pool, and ultimately rewritten the token's own supply schedule. But its influence still rests on the [vote-escrow](/wiki/dao-governance/concepts/voting/token-weighted-voting) bargain — lock a transferable, tradable token to buy weight — which is exactly what let [Convex](/wiki/daos/lending/convex-finance) aggregate and rent that weight a layer up. A [caper](/wiki/foundations/what-is-a-caper) pursues the same end (coupling say to commitment) without the lock. Its [voting weight](/wiki/governance/voting) multiplies the caper tokens a member holds by the _participation_ they have earned, and that participation record is **soulbound** — non-transferable, so it cannot be pooled into a veToken, tokenised, or sold to a cartel. The same weight formula also fixes each member's [treasury exit share](/wiki/markets/bonding-curve), so the metric that decides your vote is the metric that decides your redemption — you cannot vote with weight you would not also cash out on. And because a caper has no emission gauges to steer — its tokens come from a bonding curve, not a weekly inflation vote — there is no emission stream for a Curve-style "war" to capture. This is a design contrast, not a claim of superiority; the mechanics are on the linked pages and verified against the contract.

## References

- [Frax Finance documentation](https://docs.frax.finance/) — ecosystem overview, the fractional-algorithmic design and AMOs (primary).
- [veFXS](https://docs.frax.finance/fxs-and-vefxs/vefxs) and [Gauges](https://docs.frax.finance/fxs-and-vefxs/gauge) — the vote-escrow lock, 4-year 4× weight, and gauge-weight emission control (primary).
- [FIP-428 — Frax North Star Proposal V2](https://gov.frax.finance/t/fip-428-frax-north-star-proposal-v2/3652) — the FXS→FRAX rename, veFRAX, Fraxtal gas token, and tail-emission plan (primary governance record).
- [FIP-188 — increase CR to 100%](https://gov.frax.finance/t/fip-188-increase-cr-to-100/2147) — the February 2023 "FXG" vote back to full backing (primary governance record).
- [Fraxtal](https://docs.frax.finance/frax-v3-100-cr-and-more/fraxtal) and [Fraxtal on L2BEAT](https://l2beat.com/scaling/projects/fraxtal) — the OP-Stack rollup, Flox incentives and FXTL points.

## Liquity

URL: https://caper.network/wiki/daos/stablecoins/liquity
Updated: 2026-08-03

| Project | Liquity |
| --- | --- |
| Category | Decentralized borrowing protocol · collateral-backed stablecoin |
| Chain | Ethereum |
| V1 launched | [5 April 2021](https://www.liquity.org/blog/liquity-goes-live-on-ethereum-mainnet) |
| V2 (BOLD) launched | [23 Jan 2025](https://www.liquity.org/blog/liquity-v2-is-live); [redeployed 19 May 2025](https://www.liquity.org/blog/liquity-v2-redeployment) |
| Stablecoins | LUSD (V1) · BOLD (V2) |
| Token | LQTY — 100M fixed supply, fee-capture/staking token, **not** a governance token in V1 |
| Governance | **Governance-minimised** — immutable core with no admin key; V2 adds a single narrow lever (LQTY-staked incentive voting) that cannot touch core parameters |
| Primary sources | [liquity.org](https://www.liquity.org/features/governance-free) · [docs.liquity.org](https://docs.liquity.org) · [GitHub](https://github.com/liquity/bold) |

**Liquity** is a decentralized borrowing protocol on Ethereum whose defining choice is the near-total _absence_ of governance. Where most DAO-adjacent protocols concentrate power in a token vote, Liquity's rules are fixed in immutable smart contracts with [no admin key and no way for anyone to alter the system](https://www.liquity.org/features/governance-free). That makes it the clearest real-world example of the **minimal-governance pole** on the [DAO governance spectrum](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) — a useful foil to the vote-escrow and treasury-heavy models catalogued elsewhere in this wiki, and a live case study in the tradeoff between adaptability and capture-resistance. Its closest sibling is [Reflexer’s RAI](/wiki/daos/stablecoins/reflexer-rai), which lands at the same immutable, ungoverned core from the opposite direction — deliberately removing governance rather than never granting it.

## Governance-free by design

Liquity V1 has [no admin key, no upgradability, and no token vote over its parameters](https://docs.liquity.org/liquity-v1/faq/general). Instead of humans voting on monetary interventions, the protocol adjusts its own borrowing and redemption fees algorithmically: a _base rate_ rises with redemption volume and decays over time, so fees respond to market pressure without a committee. The team's own framing is blunt — the design makes [“human interventions redundant”](https://www.liquity.org/features/governance-free).

Crucially, [the LQTY token is not a governance token](/wiki/dao-governance/concepts/treasury/dao-tokenomics): it captures protocol fee revenue and rewards Stability Pool depositors and front-end operators, but it grants no vote over the rules ([Liquity docs](https://docs.liquity.org/liquity-v1/faq/general)). This separates Liquity sharply from the one-token-one-vote norm — there is simply nothing to vote on, so a large LQTY holder cannot capture the protocol the way a whale can capture a token-weighted DAO.

## The mechanism

Liquity V1 issues **LUSD**, a USD-pegged stablecoin, against ETH collateral with an unusually low [110% minimum collateral ratio](https://docs.liquity.org/liquity-v1/faq/general) and **no ongoing interest** — borrowers pay a one-time fee (0.5%–5%) rather than a recurring rate. The peg is defended by three algorithmic backstops instead of a governance dial:

- **Redemptions at face value.** Anyone can always swap LUSD for $1 of underlying ETH, which arbitrages the price back toward the peg ([docs](https://docs.liquity.org/liquity-v1/faq/general)).
- **The Stability Pool.** LUSD deposited into the pool absorbs liquidated collateral, with depositors compensated in ETH plus LQTY — a permissionless, always-on liquidation engine that needs no keeper vote ([docs](https://docs.liquity.org/liquity-v1/faq/general)).
- **Fellow borrowers as backstop.** If the Stability Pool is ever exhausted, debt and collateral are redistributed across remaining borrowers, so the system stays solvent without an emergency governance action.

## Liquity V2 (BOLD): the smallest possible governance surface

[Liquity V2](https://www.liquity.org/blog/liquity-v2-is-live) launched in 2025 with a new stablecoin, **BOLD**, multiple collateral types (ETH and LSTs), and user-set interest rates. It keeps the immutability commitment — [core protocol parameters remain immutable after launch](https://github.com/liquity/V2-gov) — but adds _one_ narrowly scoped governance module, and nothing more.

Through [Protocol Incentivized Liquidity (PIL)](https://docs.liquity.org/v2-faq/lqty-staking), LQTY stakers vote on where to direct roughly **25% of protocol revenue** as liquidity incentives. Voting power is time-weighted (longer stakes weigh more), votes run in [weekly epochs starting Thursdays 00:00 UTC](https://www.liquity.org/blog/voting-in-liquity-v2), proposing a new initiative needs ≥0.01% of voting power plus a 100 BOLD fee, and initiatives below a 2% vote share for four consecutive epochs can be permissionlessly unregistered. This is explicitly a Curve-style incentive market — complete with [bribe markets](https://www.liquity.org/blog/bribe-markets-in-liquity-v2-strategic-value-for-lqty-stakers) echoing the [Convex/Votium vote-buying dynamic](/wiki/daos/lending/convex-finance) — but bolted onto an otherwise ungovernable base layer. The governance module [“has no control over any of the core protocol parameters”](https://github.com/liquity/V2-gov): it can only decide where the incentive budget flows.

The immutability commitment cuts both ways. When a [Stability Pool issue was found after the January 2025 launch](https://www.liquity.org/blog/liquity-v2-redeployment), the team could not patch in place — an immutable protocol has no upgrade switch — so V2 had to be _redeployed_ from scratch on 19 May 2025 after further audits. Governance-minimisation buys capture-resistance at the cost of adaptability; there is no committee to blame, and also no committee to fix a bug.

## Where it sits on the governance spectrum

Liquity matters to DAO design precisely because it is the extreme case. Most of this wiki's ecosystem entries — [Curve](/wiki/daos/dexs/curve-dao), [Convex](/wiki/daos/lending/convex-finance), and the wider vote-escrow cluster — answer “who decides?” by engineering ever-more-elaborate vote-weighting. Liquity answers it by [removing the attack surface](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): an immutable contract cannot be governance-captured, socially engineered into a malicious upgrade, or drained by a hostile proposal, because there is no privileged action to seize. The cost is rigidity — the parameters that suit 2021 are the parameters you keep, and fixing anything means shipping an entirely new protocol and migrating users. It is a deliberate bet that a small, fixed, well-audited rule set beats a flexible one that can be turned against its users. For the opposite pole — a stablecoin whose borrow rate, mint caps, and peg backstop are all live governance votes — see [Aave’s GHO](/wiki/daos/stablecoins/aave-gho).

## How Caper approaches this

Caper sits at the opposite pole from Liquity, and the contrast is instructive. Liquity protects a fixed monetary policy by making the protocol _ungovernable_; Caper makes governance the entire point but ties it to something a whale cannot cheaply buy. In a [caper](/wiki/foundations/what-is-a-caper) the treasury _is_ the governed object, and a member's [vote weight](/wiki/governance/voting) is `(held × votes) / (vote_supply × circulation)` — a product of tokens held and a **soulbound, non-transferable proof-of-participation** earned by actually voting over time (verified against `compute_vote_weight` in `contracts/logic/src/lib.rs` and the `DIVISIBILITY_NONE` vote token in `contracts/core/src/caper_dao.rs`). The same figure sets each member's pro-rata share of the treasury on exit, so a purely financial position can never dominate a record of showing up.

Both designs reject plutocratic one-token-one-vote — but from opposite directions. Liquity removes the decisions so they cannot be captured; Caper keeps every decision on-chain and anchors it to earned, un-rentable stake, so a fixed rule set isn't needed to stay capture-resistant. Liquity's immutability-vs-adaptability tradeoff is the price of having no governance at all; Caper accepts governance and spends its effort making that governance hard to buy.

## OlympusDAO (OHM)

URL: https://caper.network/wiki/daos/stablecoins/olympusdao
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Name** | OlympusDAO (OHM) |
| **Type** | Reserve-currency DeFi protocol & DAO — the pioneer of protocol-owned liquidity |
| **Token** | OHM (governance-wrapped as gOHM) |
| **Launched** | March 2021, by the pseudonymous founder “Zeus” |
| **Chain** | Ethereum |
| **Governance** | On-chain, gOHM-weighted |
| **Known for** | Bonding, protocol-owned liquidity, the “(3,3)” meme, a 2021–22 boom-bust |
| **Reinvented as** | Range Bound Stability + Cooler Loans |
| **Links** | [olympusdao.finance](https://www.olympusdao.finance/) · [docs](https://docs.olympusdao.finance/) |

**OlympusDAO** is a DeFi protocol and [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) on Ethereum, launched in March 2021 by a pseudonymous founder known as [“Zeus”](https://www.coindesk.com/policy/2021/12/05/olympus-dao-might-be-the-future-of-money-or-it-might-be-a-ponzi). It is built around **OHM**, a free-floating token backed by an on-chain treasury rather than pegged to the dollar. Olympus's lasting contribution to the field is **protocol-owned liquidity (POL)** — the idea, now widely copied, that a protocol should _own_ the reserves and market depth that back its token instead of renting them from mercenary liquidity providers. That single design choice reshaped how DAOs think about their [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and [tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics); the reflexive incentive scheme wrapped around it made Olympus one of the most-studied cautionary tales in the same breath.

## Bonding and protocol-owned liquidity

Most protocols bootstrap a market for their token by _liquidity mining_: paying outside providers in freshly minted tokens to deposit into a pool. The liquidity is rented — it leaves the moment a better yield appears, and the emissions dilute holders. Olympus's answer was **bonding**: the protocol sells OHM at a small discount in exchange for [liquidity-pool tokens and reserve assets](https://docs.olympusdao.finance/main/overview/pol/) such as DAI and LUSD, and keeps them. Over time the treasury comes to _own_ the liquidity backing OHM outright, so the depth cannot walk away. Olympus later packaged this as a service (“Olympus Pro”) that let other DAOs buy their own liquidity the same way, and the bonding-plus-rebasing template spawned a wave of imitators — the “OHM forks” — across the 2021 cycle.

## (3,3), rebasing, and the boom-bust

Bonding built the treasury; **staking** was meant to keep OHM off the market. Stakers received sOHM that rebased with a very high advertised APY, and the famous **“(3,3)”** meme framed staking as the cooperative, game-theoretically dominant move — if everyone stakes and nobody sells, the price holds. Six-figure APYs and that reflexivity drove OHM into four figures and the protocol's market capitalization into the [billions during 2021](https://www.coindesk.com/policy/2021/12/05/olympus-dao-might-be-the-future-of-money-or-it-might-be-a-ponzi), prompting a very public debate over whether Olympus was “the future of money or a Ponzi.” When the incentive to stake weakened, the same reflexivity ran in reverse: OHM fell more than 90% through 2022. It is a textbook study in [how token designs that pay for their own price fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) — the yield was denominated in the very token whose value it was supposed to support.

## The reinvention: Range Bound Stability and Cooler Loans

After the crash, Olympus kept the protocol-owned treasury and dropped the high-APY rebasing story. OHM v2 (October 2021) introduced the **gOHM** wrapper — a non-rebasing, [governance-bearing ERC-20](https://iq.wiki/wiki/olympus-dao) used for on-chain voting. The protocol then rebuilt around _backing_, not yield. **Range Bound Stability (RBS)** deploys the treasury to buy and sell OHM inside a defended price band, so the treasury itself provides the market depth. **[Cooler Loans](https://docs.olympusdao.finance/main/overview/cooler-loans)** let gOHM holders borrow stablecoins (USDS) against the reserves backing their tokens at a fixed **0.5% perpetual** rate — permissionless, immutable, and governed entirely by the contracts. The through-line across every era is the same: the protocol owns the assets that stand behind its token.

## How Caper approaches this

Olympus's durable insight was that a protocol should not rent the liquidity that backs its token — it should own it. But Olympus had to _buy_ that liquidity through bonding and then defend a floating “backing per token,” and the (3,3) reflexivity turned that into a boom-bust. A [caper](/wiki/foundations/what-is-a-caper) keeps the ownership and drops the discretion. Its [bonding curve](/wiki/markets/bonding-curve) _is_ the reserve: the XRD paid on every buy accrues into the curve's own inventory vault, and any holder's exit is priced by the same closed-form integral against that vault — so exit liquidity is structural rather than incentivized, with no rented LPs, no emissions to defend, and no floating backing ratio to game. There is no six-figure APY drawing capital in and no reflexive spiral when it leaves; the reserve that lets you sell back is the reserve your purchase created. (Verified against `contracts/logic/src/lib.rs`.)

## References

- [OlympusDAO — official site](https://www.olympusdao.finance/)
- [Olympus Docs — protocol overview (OHM, POL, RBS, Cooler Loans)](https://docs.olympusdao.finance/main/overview/intro/)
- [Olympus Docs — Protocol Owned Liquidity](https://docs.olympusdao.finance/main/overview/pol/)
- [Olympus Docs — Cooler Loans](https://docs.olympusdao.finance/main/overview/cooler-loans)
- [CoinDesk (Dec 2021) — “Olympus DAO Might Be the Future of Money (or It Might Be a Ponzi)”](https://www.coindesk.com/policy/2021/12/05/olympus-dao-might-be-the-future-of-money-or-it-might-be-a-ponzi)
- [IQ.wiki — Olympus DAO (history, OHM v2 / gOHM, bonding)](https://iq.wiki/wiki/olympus-dao)

## Reflexer (RAI)

URL: https://caper.network/wiki/daos/stablecoins/reflexer-rai
Updated: 2026-08-03

| Project | Reflexer Labs — issuer of **RAI**, a non-pegged, ETH-backed stable asset |
| --- | --- |
| Category | Decentralized stablecoin / autonomous monetary policy |
| Tokens | **RAI** (the stable asset) · **FLX** ([Reflexer Ungovernance Token](https://coingecko.com/en/coins/reflexer-ungovernance-token)) |
| Collateral | **ETH only** — a single, transparent collateral type by design |
| Launched | February 2021 (Ethereum mainnet) |
| Governance model | Staged **governance minimization** ("ungovernance") — powers removed on a schedule |
| Codebase | [GEB](https://docs.reflexer.finance) — Reflexer's fork of MakerDAO's multi-collateral contracts |
| Status | Reflexer Labs wound down active development; RAI contracts remain immutable and live on-chain |
| Notable fork | [HAI](https://hai-9.gitbook.io/hai-documentation/) — a multi-collateral RAI fork on Optimism |
| Links | [reflexer.finance](https://reflexer.finance/) · [GEB docs](https://docs.reflexer.finance) · [forum](https://community.reflexer.finance/) · [RAI on Etherscan](https://etherscan.io/token/0x03ab458634910aad20ef5f1c8ee96f1d6ac54919) |

**Reflexer** issues **RAI**, a decentralized stable asset that is deliberately _not_ pegged to the dollar. Users lock [ETH as the sole collateral](https://docs.reflexer.finance) and mint RAI against it; instead of chasing a fixed $1 target, RAI runs a [managed float](https://reflexer.finance/faq/) around a moving **redemption price** that started near $3.14 at launch. The system's job is not to hold a peg but to dampen volatility: an on-chain controller continuously nudges RAI's market price toward its redemption price without any human deciding the target. It is one of the most-cited experiments in [autonomous, minimally-governed money](https://www.coindesk.com/) — a foil to both custodial pegs and heavily-governed CDP stablecoins like [Aave's GHO](/wiki/daos/stablecoins/aave-gho).

## Autonomous monetary policy: the PID controller

Where [MakerDAO](/wiki/daos/stablecoins/sky-dao) sets its stability fee by governance vote, RAI hands that lever to an on-chain [PI (proportional–integral) controller](https://docs.reflexer.finance/faq). The controller reads the gap between RAI's market price and its redemption price and outputs a **redemption rate** — a per-second re- or de-valuation of the redemption price itself. When RAI trades above target, the rate makes holding RAI less attractive and minting it more so, pushing the market back down; when it trades below, the reverse. The integral term means the controller also weighs how long and how far the price has drifted, so the response is smoother than a naive one-shot correction. No governance vote sets the rate — the [controller runs autonomously](https://community.reflexer.finance/t/rai-controller-ungovernance/208), which is precisely the point: monetary policy without a monetary-policy committee.

## "Ungovernance": removing the governance itself

RAI's governance token is named the **Reflexer Ungovernance Token (FLX)**, and the name is the thesis. Rather than accumulate governance power, FLX holders were meant to _spend_ it down — steering a staged process that [removes governance capabilities on a published schedule](https://docs.reflexer.finance/ungovernance/governance-minimization-guide) until little discretionary control remains. FLX's residual job is that of a lender of last resort: if the system goes underwater, FLX is autonomously minted and auctioned in [debt auctions](https://docs.reflexer.finance) to recapitalize it, mirroring MKR's backstop role in Maker.

The published [governance-minimization guide](https://docs.reflexer.finance/ungovernance/governance-minimization-guide) lays out concrete stages. An early level stripped governance control over core mechanisms — liquidation, auctions, and the oracle relayer. A later level removed governance from the **SAFE Engine**, the **Accounting Engine**, and the protocol-token authorities, which permanently blocks governance from adding new collateral types (a large share of Maker's real-world governance surface). What is deliberately kept under community control is the hard-to-automate perimeter: [oracles and medianizers, PID-controller tuning, the stability-fee treasury, and saviour contracts](https://docs.reflexer.finance/ungovernance/governance-minimization-guide). The goal is not zero governance but the smallest governance surface a working stablecoin can run on.

## Status, legacy, and the HAI fork

Reflexer Labs has [wound down active development](https://help.defisaver.com/no-longer-available/reflexer), but the design is built to survive exactly that: RAI's contracts are immutable and continue operating on Ethereum without the team. The immutability-as-endgame idea reappears in [Liquity](/wiki/daos/stablecoins/liquity), whose V1 is similarly frozen and ungoverned — RAI and Liquity are the two canonical "governance can't touch the core" case studies in DeFi.

RAI's codebase also lives on through forks. The most prominent is [HAI](https://www.theblock.co/post/276100/stablecoin-protocol-hai-to-have-airdrop-ahead-of-mainnet-launch-on-optimism), a [multi-collateral RAI fork on Optimism](https://community.reflexer.finance/t/announcing-hai-a-multi-collateral-rai-fork-on-optimism/461) that reuses the same PI-controller machinery but anchors near $1 and accepts several collateral types (ETH, wstETH, and later OP) rather than ETH alone. RAI thus sits at one end of the DAO-industry's governance spectrum: a stablecoin whose founders' explicit aim was to make themselves, and eventually all governors, unnecessary.

## How Caper approaches this

RAI answers governance risk by _subtracting_ governance — automate monetary policy, then delete the levers so no one (not even a captured vote) can pull them. That is the right move for a single-purpose money machine. Most DAOs, though, exist precisely to keep deciding things — funding, hires, direction — so they can't ungovern their way out of capture. [Caper](/wiki/foundations/what-is-a-caper) takes the other route: keep governance, but change what a vote is _made of_ so control is harder to simply buy.

In the Caper contract, a member's weight is `w = (t · v) / (V · T)` — held tokens _t_ multiplied by an earned vote factor _v_, over total vote supply _V_ and circulating tokens _T_ (`compute_vote_weight`, verified in `contracts/logic/src/lib.rs`). The vote factor comes from a **soulbound, non-transferable** vote token (minted at `DIVISIBILITY_NONE`), and the same weight formula sets a member's treasury share on `exit()`. Capital still counts — a bigger bag is a larger multiplier — but the earned, un-purchasable record is a factor a whale can't acquire on a market. Where RAI removes the attack surface, Caper keeps the surface and makes a decisive slice of it unbuyable. See the wider [governance-models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) map for where each design sits.

## Sky (formerly MakerDAO)

URL: https://caper.network/wiki/daos/stablecoins/sky-dao
Updated: 2026-07-23

|  |  |
| --- | --- |
| **Name** | Sky (formerly MakerDAO) |
| **Type** | Protocol DAO (stablecoin / lending) |
| **Governance token** | SKY (migrated from MKR at 1:24,000) |
| **Stablecoins** | USDS (formerly / alongside DAI) |
| **Founded** | MakerDAO 2015; rebranded to Sky on 27 August 2024 |
| **Notable for** | Created DAI, the first widely-used decentralized stablecoin; the multi-year "Endgame" restructuring into subDAOs ("Stars") |
| **Primary sources** | [sky.money](https://sky.money/), [forum.sky.money](https://forum.sky.money/), [governance portal](https://vote.makerdao.com/) |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Uniswap](/wiki/daos/dexs/uniswap-dao), [ENS DAO](/wiki/daos/infrastructure/ens-dao) |

**Sky** — the protocol formerly known as **MakerDAO** — is one of the oldest and largest [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) in DeFi. It governs the issuance of decentralized, crypto-and-real-world-asset-collateralized stablecoins and is widely regarded as the original DeFi DAO, the project that proved a community could run a multi-billion-dollar monetary system through on-chain governance.

## DAI: the first decentralized stablecoin

MakerDAO launched **DAI** in 2017, the first widely-adopted stablecoin not backed by a centralized issuer's bank account but minted against on-chain collateral and held near $1 by an autonomous system of vaults, liquidations, and a governance-set stability fee. MKR holders governed every parameter — collateral types, fees, debt ceilings — making Maker the canonical demonstration of decentralized monetary governance. ([Sky / Maker documentation](https://docs.sky.money/))

## Endgame and the rebrand to Sky

In May 2022, co-founder Rune Christensen published **Endgame**, a multi-year plan to restructure the monolithic protocol into a modular network of semi-autonomous subDAOs. On 27 August 2024 the project rebranded from MakerDAO to **Sky**, introducing new tokens: the MKR governance token migrates to **SKY** at a 1:24,000 ratio, and DAI gains a sibling, **USDS**, that holders can optionally upgrade to. ([The Block](https://www.theblock.co/post/313235/makerdao-mkr-sky-dai-stablecoin-usds))

## The protocol today

By early 2026 the combined supply of DAI and USDS sits around $13 billion, with USDS having overtaken DAI in raw size. The collateral mix has shifted heavily toward **real-world assets** — roughly 40% short-term U.S. treasuries allocated through "Star" allocators, around a third USDC via the peg-stability module, and the balance in crypto — so that real-world-asset revenue now supplies the majority of protocol income, a near-complete inversion of its crypto-native origins. The Endgame "Stars" launch as subDAOs with their own tokens and governance; the first live Star, [Spark](https://spark.fi/) ([its own DAO page](/wiki/daos/lending/spark)) — a lending market built on Sky liquidity — has grown past $3 billion in deposits ([live figure on DeFiLlama](https://defillama.com/protocol/spark)). ([Sky governance forum](https://forum.sky.money/))

## Why it matters

Sky is the longest-running test of whether a DAO can manage a large, risk-bearing balance sheet — making it a continual reference point for [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management): diversification into yield-bearing real-world assets, governance-set rates, and the trade-off between decentralization and the operational discipline a multi-billion-dollar treasury demands.

## How Caper approaches this

Sky shows both the promise and the weight of a community-run treasury. A [caper](/wiki/foundations/what-is-a-caper) aims at the same on-chain, member-controlled treasury idea at a smaller, simpler scale: funds are [raised](/wiki/markets/raising-funds) into a shared vault that no single party can unilaterally spend, decisions [execute](/wiki/governance/execution) on-chain when a vote authorizes them, and members retain a direct claim on the treasury. The Caper pages describe those mechanics without the subDAO complexity.

## References

- [Sky](https://sky.money/) — official site.
- [Sky Governance Forum](https://forum.sky.money/).
- [The Block](https://www.theblock.co/post/313235/makerdao-mkr-sky-dai-stablecoin-usds) — MakerDAO rebrands to Sky; DAI optionally upgradeable to USDS.

## EigenLayer (EigenCloud)

URL: https://caper.network/wiki/daos/staking/eigenlayer
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Name** | EigenLayer (rebranded EigenCloud, 2025) |
| **Type** | Restaking protocol / shared-security "collective" on [Ethereum](https://ethereum.org/) |
| **Governance token** | EIGEN (airdrop claims May 2024; transferable 1 Oct 2024; initial supply 1,673,646,668.28466) |
| **Governance model** | EigenGov — a Protocol Council (3-of-5 Safe) ratifying [ELIPs](https://github.com/eigenfoundation/ELIPs) + a 9-of-13 community multisig backstop; on-chain **forking** of EIGEN as the last-resort slashing mechanism |
| **Secures** | AVSs (Actively Validated Services) via restaked ETH and staked EIGEN |
| **Notable for** | Pioneering [restaking](/wiki/daos/staking/rocket-pool); the forkable "universal intersubjective work token" that can slash a colluding majority without assuming an honest one |
| **Primary sources** | [eigencloud.xyz](https://www.eigencloud.xyz/), [docs.eigenfoundation.org](https://docs.eigenfoundation.org/), [blog.eigenfoundation.org](https://blog.eigenfoundation.org/) |
| **Related** | [Lido DAO](/wiki/daos/staking/lido-dao), [Rocket Pool](/wiki/daos/staking/rocket-pool), [DAO security & governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [Soulbound tokens](/wiki/dao-governance/concepts/membership/soulbound-tokens) |

**EigenLayer** — rebranded **EigenCloud** in 2025 — is a protocol on [Ethereum](https://ethereum.org/) that pioneered **restaking**: letting ETH stakers reuse their staked capital to extend Ethereum's economic security to other applications. It is stewarded by [Eigen Labs](https://www.eigenlayer.xyz/) and the [Eigen Foundation](https://docs.eigenfoundation.org/), and governed through the EIGEN token and a council-based framework called **EigenGov**. What makes it worth a place in a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) directory is not its size alone but a genuinely distinct idea about how a token can defend a network: EIGEN is designed to be **socially forkable**, so that a colluding majority can be slashed without the protocol ever assuming that most participants are honest.

## Restaking and shared security

Ethereum's validators secure the base chain by staking ETH. **Restaking** lets that same staked ETH (or a liquid-staking token such as [Lido](/wiki/daos/staking/lido-dao)'s stETH) also secure additional systems — called **AVSs** (Actively Validated Services): oracles, data-availability layers, bridges, rollups, coprocessors. Three roles make it work. **Restakers** deposit ETH or LSTs and delegate. Many deposit indirectly by holding a **liquid restaking token (LRT)** — a receipt like [ether.fi](/wiki/daos/staking/ether-fi)'s eETH, whose DAO is consistently among EigenLayer's largest single sources of restaked ETH. **Operators** run the software an AVS requires and are the parties actually slashed for misbehavior. **AVSs** define the work and the slashing conditions. The thesis is _pooled security_: a new service can rent a share of Ethereum's ~multi-billion-dollar trust set instead of bootstrapping its own token and validator set from zero. The protocol's own flagship AVS is **EigenDA**, a high-throughput data-availability service. ([EigenLayer overview](https://docs.eigencloud.xyz/products/eigenlayer/concepts/eigenlayer-overview); [Stage-1 mainnet launch](https://web.archive.org/web/20260606045731/https://blog.eigencloud.xyz/eigenlayer-stage-1-mainnet-launch/) (archived))

Restaking is not Ethereum-only: on Solana, [Jito](/wiki/daos/staking/jito)'s (Re)staking programs re-pledge staked assets to secure **Node Consensus Networks** — the same shared-security pattern governed by a different DAO.

## Two kinds of faults — and a token you can fork

EigenLayer's most-cited innovation is its answer to faults that Ethereum's consensus _cannot_ settle. It splits misbehavior into two classes. **Objective faults** are provable on-chain — a double-sign, an invalid state transition — and are punished by slashing the **restaked ETH** that a contract can adjudicate directly. **Intersubjective faults** are ones every honest observer can agree on but no contract can prove from the chain alone — an oracle reporting a price that was plainly false, say. These are backed not by ETH but by **EIGEN**.

The defining property is **forkability**. EIGEN exists in a transferable form and a staked, slashable form (**bEIGEN**). If a majority of EIGEN stakers collude to attest to a result the wider community agrees is wrong, the token can be **forked**: the ledger splits, the colluders' stake is slashed on the honest fork, and honest challengers are made whole — the market then decides which fork is canonical. Because the punishment is a social fork rather than an on-chain proof, security does _not_ require an honest majority. This is the same backstop that once played out manually when the Steem community forked to Hive to escape a hostile stake takeover, formalized here as an explicit on-chain mechanism. Eigen Labs describes EIGEN as a "universal intersubjective work token." ([Eigen Foundation docs](https://docs.eigenfoundation.org/); [Nethermind: EIGEN explained](https://www.nethermind.io/blog/eigenlayer-and-eigen-token-explained))

## The EIGEN token

EIGEN launched with an **initial supply of 1,673,646,668.28466** — a number that spells "1-Open-Innovation" on a phone keypad — with roughly **45% allocated to the community** (including a 15% stakedrop). Airdrop claims opened on **10 May 2024** while the token was still non-transferable, and EIGEN became **transferable on 1 October 2024**, debuting at a fully-diluted value around $6.4 billion. The staked form, bEIGEN, was upgraded in September 2024 to enable **Programmatic Incentives** — protocolized EIGEN rewards for stakers and operators. ([Eigen Foundation: initial supply](https://docs.eigenfoundation.org/eigen-token/key-info); [CoinDesk: EIGEN debuts](https://www.coindesk.com/business/2024/10/01/eigenlayers-eigen-token-debuts-at-651-fdv))

## Slashing and Operator Sets

Slashing went live on mainnet on **17 April 2025**, several years after launch and only after a deliberately staged rollout. AVSs now define custom slashing conditions and organize operators into **Operator Sets**, with **Unique Stake** allocation so a given slice of ETH is slashable by only one Operator Set at a time. Slashing is **opt-in** — operators are not automatically enrolled into any AVS's conditions. A later upgrade, **ELIP-006 Redistributable Slashing**, let AVSs _repurpose_ slashed funds (for lending or insurance reimbursement, for example) instead of burning them. ([Intro to slashing: AVS edition](https://web.archive.org/web/20260521051729/https://blog.eigencloud.xyz/intro-to-slashing-on-eigenlayer-avs-edition/) (archived); [eigenlayer-contracts releases](https://github.com/Layr-Labs/eigenlayer-contracts/releases))

How that penalty is actually assessed, and how it compares with the fixed schedules on Ethereum and Cosmos, is covered in [staking and slashing](/wiki/economics/staking-and-slashing).

## Protocol governance (EigenGov)

Upgrades to EigenLayer's core contracts flow through **ELIPs** (EigenLayer Improvement Proposals), reviewed and approved by a **Protocol Council** introduced on **4 December 2024**. The council operates a **3-of-5 [Gnosis Safe](/wiki/daos/networks/gnosisdao)** — two seats for the Eigen Foundation and three independent members drawn from across the ecosystem (Sigma Prime, Unit410, and security engineer Gonçalo Sa) — and executes changes through a **timelock enforcing a minimum 10-day delay** on any queued transaction. Sitting above it as a backstop is a **9-of-13 Community Multisig** of Ethereum-community members, who normally act as observers monitoring the council's queued actions and can intervene if something is wrong. It is an explicitly _council-and-multisig_ model rather than open [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) — the Foundation frames it as a staged path toward decentralization, not decentralization already achieved. ([Introducing the Protocol Council](https://blog.eigenfoundation.org/the-protocol-council/); [Technical architecture](https://docs.eigenfoundation.org/protocol-governance/technical-architecture); [ELIPs repository](https://github.com/eigenfoundation/ELIPs))

## EigenCloud and the 2025–2026 pivot

In 2025 the project rebranded to **EigenCloud**, positioning restaking-secured services — **EigenDA** (data availability), **EigenCompute**, and **EigenAI** — as a "verifiable cloud." The pivot came against a hard market backdrop: EIGEN fell roughly **91% across 2025**, shedding about $700 million in market capitalization. On **19 December 2025** the Eigen Foundation proposed a governance overhaul to tie token value to real usage: a new **Incentives Committee** (Foundation and Eigen Labs representatives, ratified by the Protocol Council) would adjust emissions without slow contract upgrades, steering rewards toward **"productive stake"** — tokens actively securing live services under genuine slashing risk, rather than idle restaked balances — and a fee model would route about **20% of AVS reward fees**, plus EigenCloud service fees, into EIGEN buybacks. ([CoinDesk, Dec 2025](https://www.coindesk.com/business/2025/12/19/foundation-behind-restaking-protocol-eigenlayer-plans-bigger-rewards-for-active-users))

## How Caper approaches this

EigenLayer's headline safeguard against a colluding majority is to **fork the token** — it deliberately refuses to assume that most holders are honest. A [caper](/wiki/foundations/what-is-a-caper) reaches for the same distrust of a bought majority with narrower, different tools. It does not fork; instead the _decisive_ governance factor is an earned, non-transferable record. A member's voting weight — and their treasury share at [exit](/wiki/governance/execution) — is `(t · v) / (V · T)`: their held stake `t` multiplied by `v`, [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) proof-of-vote tokens minted one per vote and locked to the account. Stake still counts — `t` is a multiplier, so this is not a "your bag doesn't matter" system — but the un-buyable factor `v` means acquiring the float on a market does not by itself acquire control. And where EigenLayer's ultimate backstop is exit-by-fork, a caper gives every member a standing exit: redeem at any time for a treasury share sized by that same (t·v)/(V·T) weight, so even a captured vote cannot seize the value dissenters are entitled to withdraw. These mechanics are verified against the caper contract and described neutrally on the [voting](/wiki/governance/voting-mechanisms) and [execution](/wiki/governance/execution) pages.

## References

- [EigenCloud](https://www.eigencloud.xyz/) — project site (formerly eigenlayer.xyz).
- [Eigen Foundation documentation](https://docs.eigenfoundation.org/) — token, governance, and the ELIP process.
- [Introducing the Protocol Council](https://blog.eigenfoundation.org/the-protocol-council/) — the 3-of-5 council and community multisig.
- [Key information on the initial EIGEN supply](https://docs.eigenfoundation.org/eigen-token/key-info).
- [Intro to slashing on EigenLayer](https://web.archive.org/web/20260521051729/https://blog.eigencloud.xyz/intro-to-slashing-on-eigenlayer-avs-edition/) — Operator Sets, Unique Stake, redistribution (Internet Archive; the EigenCloud blog itself now returns 404).
- [eigenfoundation/ELIPs](https://github.com/eigenfoundation/ELIPs) and [Layr-Labs/eigenlayer-contracts](https://github.com/Layr-Labs/eigenlayer-contracts) — proposals and core contracts.

## ether.fi (ETHFI)

URL: https://caper.network/wiki/daos/staking/ether-fi
Updated: 2026-07-19

| Project | ether.fi |
| --- | --- |
| Category | Liquid restaking protocol · DAO |
| Governance token | ETHFI (fixed supply 1,000,000,000) |
| Liquid restaking tokens | eETH · weETH (wrapped) |
| Restaking layer | [EigenLayer](/wiki/daos/staking/eigenlayer) |
| Voting | [Snapshot](https://snapshot.org/#/etherfi-dao.eth) (etherfi-dao.eth) · 4-day window · 1M ETHFI quorum |
| Stewardship | ether.fi Foundation (Proposer + Multi-Sig Committee) |
| Launched | Protocol 2023 · ETHFI airdrop 18 March 2024 |
| Status | 🟢 Active |
| Links | [ether.fi](https://ether.fi) · [docs](https://etherfi.gitbook.io/etherfi) · [governance forum](https://governance.ether.fi) · [DeFiLlama](https://defillama.com/protocol/ether.fi) |

## Overview

[ether.fi](https://ether.fi) is a non-custodial liquid _restaking_ protocol on Ethereum. A user deposits ETH and receives **eETH** (or its wrapped, DeFi-composable form **weETH**), a liquid token that represents a position which is staked on the beacon chain _and simultaneously restaked_ through [EigenLayer](/wiki/daos/staking/eigenlayer). Unlike custodial staking services, node-operation keys stay with the staker rather than the protocol, which ether.fi frames as its core "non-custodial" design (see the [protocol documentation](https://etherfi.gitbook.io/etherfi)).

By 2026 ether.fi had grown into the largest liquid restaking protocol and one of the largest liquid-staking protocols overall, second only to [Lido](/wiki/daos/staking/lido-dao) by total value locked — live figures are tracked on [DeFiLlama](https://defillama.com/protocol/ether.fi). Governance and the protocol treasury are directed by holders of the **ETHFI** token through the ether.fi DAO.

## From staking to restaking

ether.fi sits one layer beyond classic liquid staking. Protocols like [Lido](/wiki/daos/staking/lido-dao) (stETH) and [Rocket Pool](/wiki/daos/staking/rocket-pool) (rETH) issue a liquid receipt for ETH that is only validating Ethereum. ether.fi's eETH is _additionally_ restaked into [EigenLayer](/wiki/daos/staking/eigenlayer), where the same ETH secures actively validated services (AVSs) in exchange for extra rewards — and takes on the extra slashing surface that restaking introduces.

This makes ether.fi the reference example of the **liquid restaking token (LRT) archetype**: a governance-bearing DAO wrapped around a staking position whose risk and reward are a function of a _separate_ restaking market it does not itself control. Its [EigenLayer](/wiki/daos/staking/eigenlayer) dependency is why the two projects are tightly coupled in this directory — ether.fi is consistently among EigenLayer's largest single sources of restaked ETH.

## ETHFI: the governance token

**ETHFI** is the ether.fi DAO's governance and coordination token, [announced in March 2024](https://etherfi.medium.com/announcing-ethfi-the-ether-fi-governance-token-8cae7327763a). Key parameters from ether.fi's own announcement:

- **Fixed supply:** 1,000,000,000 ETHFI, with "no further issuance."
- **Initial circulating supply:** 115,200,000 ETHFI (11.52% of max supply) at launch.
- **Airdrops:** Season 1 distributed 6% of supply, claimable from 18 March 2024 over a 90-day window; Season 2 distributed a further 5% (snapshot 15 March 2024), with unclaimed Season 1 tokens rolling into Season 2. Whale wallets were subject to a 3-month vest.
- **Full distribution** is scheduled to complete by the end of 2030.

The announcement scopes what ETHFI actually decides: the **Grants Program**, "protocol longevity, vision, and key economic parameters, such as protocol fees," greenlighting of node operators and contributor permissions, and treasury-diversification activities. Holders can also stake ETHFI (receiving **sETHFI**) to earn incentives and unlock membership tiers via the [staking docs](https://etherfi.gitbook.io/etherfi/ethfi/ethfi-staking).

## How governance works

ether.fi's process is documented in the [official governance resources](https://governance.ether.fi/t/ether-fi-governance-official-resources/2140):

- **Discussion:** proposals are posted on the [Discourse forum](https://governance.ether.fi) "with context and discussion before and during the voting window."
- **Voting:** votes are cast on [Snapshot (etherfi-dao.eth)](https://snapshot.org/#/etherfi-dao.eth) with a **4-day window**. A vote can be opened at the same time a proposal is submitted.
- **Quorum & threshold:** "1M ETHFI is required for quorum in order for a vote to be valid," and a proposal "passes if it receives at least 1M ETHFI in approval votes."
- **Weight & delegation:** voting power is proportional to ETHFI (and sETHFI) held; holders can [delegate](https://vote.ether.fi/delegates) their voting power to others.

## The Foundation-and-multisig model

ether.fi separates _deciding_ from _executing_ through the [ether.fi Foundation](https://etherfi.gitbook.io/gov/ether.fi-foundation). A **Proposer** "submits proposals for the protocol changes and governance decisions, including treasury spend, initiating community votes for token holder approval." A **Multi-Sig Committee** then "implements these decisions, handles emergency actions, and ensures proposals align with the Foundation's objectives."

This is a distinct archetype from the fully on-chain [Governor](/wiki/daos/infrastructure/uma)-style DAOs elsewhere in this directory: the binding tally is an off-chain Snapshot vote, and a trusted multisig carries out the result. The Foundation states that "further governance mechanisms will be rolled out in phases," aiming toward "full decentralization with an ecosystem of active contributors" — a candid _progressive-decentralization_ posture rather than a claim of already-trustless execution. That gap between an off-chain vote and a multisig that executes it is exactly the failure mode this wiki catalogues in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## Governance in practice

Beyond parameter changes, the ether.fi treasury and its product surface (Stake, Liquid, and the Cash card) give holders real economic levers. Treasury-diversification and token-value questions — including proposals to deploy treasury toward ETHFI buybacks — have been brought to the DAO's [Snapshot](https://snapshot.org/#/etherfi-dao.eth), exercising the "key economic parameters" and "treasury diversification" mandate the token was given. Because these are Foundation-executed multisig actions rather than trustless on-chain execution, they are a live test of the phased-decentralization promise above.

## How Caper approaches this

ether.fi shows the standard shape of a large DeFi DAO: an off-chain Snapshot vote sets intent, and a Foundation multisig is trusted to carry it out. [Caper](/wiki/foundations/what-is-a-caper) narrows that trust gap in two places. First, [vote weight](/wiki/governance/voting-mechanisms) is a _product_ of what a member holds and how they have participated — so holdings still count, but a large bag alone cannot decide an outcome without the participation term. Second, a proposal's on-chain execution is bound to a settled, clamped winner, so what a multisig _could_ do is constrained by what the ledger tallied — the off-chain result and the on-chain action cannot diverge. It is a different point on the same design axis ether.fi is walking down in phases.

## Jito (JTO & JitoSOL)

URL: https://caper.network/wiki/daos/staking/jito
Updated: 2026-08-11

| Project | Jito (Jito Foundation / Jito Labs) |
| --- | --- |
| Tokens | JTO (governance) · JitoSOL (liquid staking) |
| Category | Liquid staking + MEV infrastructure DAO |
| Chain | Solana |
| Governance | Token-weighted (1 JTO = 1 vote) via Solana [SPL Governance (Realms)](https://docs.realms.today/); DAO multisig execution |
| JTO supply | 1,000,000,000 fixed; airdropped 7 Dec 2023 |
| Founded | 2022 |
| Website | [jito.network](https://www.jito.network/) |

**Jito** is the DAO that governs the dominant slice of Solana's [value-capture stack](/wiki/dao-governance/concepts/treasury/dao-treasury-management): the network's largest liquid-staking token (**JitoSOL**), the MEV-enabled validator client that most of Solana's stake runs, and the block-building marketplace that sequences much of its transaction flow. Where [Lido](/wiki/daos/staking/lido-dao) and [Rocket Pool](/wiki/daos/staking/rocket-pool) govern liquid staking and [EigenLayer](/wiki/daos/staking/eigenlayer) governs restaking, Jito is the rare DAO whose treasury sits astride an entire chain's _MEV supply chain_ – client, block engine, tips, and restaking – making it a distinctive study in governing revenue-generating infrastructure rather than a single protocol.

## JitoSOL: liquid staking with MEV

[JitoSOL](https://www.jito.network/docs/jitosol/overview/) is a non-custodial [liquid-staking](/wiki/daos/staking/lido-dao) token: deposit SOL, receive JitoSOL, and keep a liquid, DeFi-composable claim that accrues both ordinary staking yield _and_ a share of the MEV rewards Jito's validators earn. It is Solana's largest liquid-staking token, with on the order of **14.5 million SOL (~$2.9B)** staked through the pool as of 2025-2026 ([Solana Compass](https://solanacompass.com/projects/jito)).

Delegation is not hand-managed. Jito runs [StakeNet](https://www.jito.network/docs/stakenet/overview/) – a blend of on-chain programs and off-chain "keepers", anchored by the **Steward Program** – to score validators and rebalance JitoSOL's stake across them automatically, on-chain and auditably. Crucially, _every_ StakeNet parameter (delegation criteria, safety thresholds, caps) is set by [Jito DAO governance](https://www.jito.network/docs/governance/the-jito-governance-token-jto/), so the community, not a private operator, controls where the largest Solana stake pool points. The scoring-formula approach contrasts with fellow Solana LST DAO [Marinade](/wiki/daos/staking/marinade), which instead auctions its stake to the validators that bid the highest yield.

## The Jito-Solana client, Block Engine & tips

The other half of Jito is MEV infrastructure. The [Jito-Solana validator client](https://www.jito.wtf/validators/) is an MEV-enabled fork of Solana's Agave client; by 2025 it was run by roughly **90%+ of Solana's staked SOL** (~95% of validators), making it the network's de-facto standard ([GetBlock](https://getblock.io/blog/what-is-jito-solana-mev-client/)).

Around it sits an off-chain **Block Engine**: searchers submit _bundles_ – atomic, explicitly-ordered groups of transactions – and bid _tips_ for inclusion, and the winning bundles are forwarded to the leader. Tips flow back to stakers and validators through the on-chain [Tip Distribution Program](https://jito-foundation.gitbook.io/mev/mev-payment-and-distribution/tip-distribution-program). The scale is large: heading into 2025, Jito tips had paid out roughly **$674 million** to stakers and validators and accounted for close to half of Solana's real economic value ([Crypto Briefing](https://cryptobriefing.com/jito-351m-market-cap-78m-mev-fees-solana/)). In July 2025 Jito announced the [Block Assembly Marketplace (BAM)](https://www.helius.dev/blog/block-assembly-marketplace-bam), a verifiable, privacy-preserving, programmable block-building architecture that runs block construction inside Trusted Execution Environments – borrowing the design of Ethereum's [Flashbots BuilderNet](https://blockworks.com/news/jito-upgrade-block-assembly-marketplace).

## What the Jito DAO governs

JTO is a fixed-supply governance token (1 billion, [airdropped 7 December 2023](https://www.jito.network/docs/governance/the-jito-governance-token-jto/)). Holders draft [Jito Improvement Proposals (JIPs)](https://forum.jito.network/) on the governance forum and vote token-weighted through Solana's SPL Governance (Realms), with a DAO multisig enacting passed proposals. Per the governance docs, JTO controls three concrete levers:

- **StakeNet parameters** – the delegation strategy behind JitoSOL's multi-billion-dollar stake distribution.
- **TipRouter NCN parameters** – the node-consensus network that computes and distributes MEV tips.
- **The DAO treasury** – the JTO held by the DAO plus the fees generated by JitoSOL and restaking.

Because a JitoSOL depositor need not hold JTO – and a JTO holder need not stake – Jito is a clean example of the [token-weighted-voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) model applied to critical shared infrastructure: influence over Solana's staking and MEV plumbing is priced, transferable, and accrues to whoever accumulates the most JTO.

## TipRouter and Jito (Re)staking

[TipRouter](https://www.jito.network/blog/what-is-jito-tiprouter/) (live since February 2025) is itself built on Jito's newer product line: [Jito (Re)staking](https://www.jito.network/docs/restaking/jito-restaking-overview/). Restaking lets staked SPL assets be re-pledged to secure additional **Node Consensus Networks (NCNs)**, with vault positions represented by transferable _Vault Receipt Tokens (VRTs)_; the programs are audited by Certora, Offside and OtterSec and secure hundreds of millions in assets. TipRouter is the first flagship NCN – it decentralises the computation and distribution of Jito tips, replacing a trusted off-chain process. It charges a **6% fee on tips**, split between Jito Labs and the DAO; in Q2 2025 that fee alone earned the DAO [22,391 SOL (~$4M)](https://kairoscrypto.substack.com/p/tiprouter-jitos-2025-growth-engine).

## Routing fees to the DAO

Through 2025 Jito's governance steadily redirected protocol revenue to the treasury and to token holders. [JIP-24](https://www.coindesk.com/tech/2025/08/05/solana-s-jito-proposes-routing-100-of-block-engine-fees-to-dao-treasury) proposed routing **100% of Block Engine fees** (and future BAM fees) to the Jito DAO treasury. Separately, [JIP-38](https://solanacompass.com/news/jtx-goes-live-on-solana-as-jitos-self-custody-trading-platform-opens-to-first-1000-users) (passed 13 July 2025) directs 80% of fees from **JTX** – Jito's self-custody spot-trading platform – to the DAO, and commits 100% of the DAO's share to open-market **JTO buybacks** through Q4 2027, with the repurchased JTO burned. The result is a DAO increasingly funded by, and returning value from, the infrastructure it governs.

## How Caper approaches this

Jito shows token-weighted governance at its most consequential: control over Solana's largest stake pool and its MEV pipeline accrues to whoever holds the most JTO, a freely tradeable asset. That is a deliberate, working design for a live revenue business – something a small [caper](/wiki/foundations/what-is-a-caper) does not operate and does not try to imitate.

Caper differs in _who_ the decisive vote belongs to. A caper's governance weight is `(t·v)/(V·T)` – governance tokens held (`t`) times an earned, non-transferable [soulbound proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens) (`v`), over total supply of each (verified in `contracts/logic/src/lib.rs`, `compute_vote_weight`). The soulbound token is minted one-per-vote and cannot be bought or moved (`DIVISIBILITY_NONE`, depositor locked to the component; `contracts/core/src/caper_dao.rs`). Holdings still count – `t` is a multiplier – but a large bag alone cannot capture control the way accumulating JTO can, because the earned factor `v` is not for sale. The same weight sizes a member's [exit redemption](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), and the vote token is burned on the way out (`exit()`, same file). And where Jito's treasury moves when a multisig enacts an off-chain-drafted JIP, a caper's [treasury](/wiki/markets/bonding-curve) moves only through typed on-chain PAYOUT / INVEST / DIVEST / VOTE proposals in which the passing vote _is_ the transfer.

## References

- [Jito Foundation – Documentation Hub](https://www.jito.network/docs/hub/overview/)
- [Jito – The JTO Governance Token](https://www.jito.network/docs/governance/the-jito-governance-token-jto/)
- [Jito – StakeNet & the Steward Program](https://www.jito.network/docs/stakenet/overview/)
- [Jito – (Re)staking overview](https://www.jito.network/docs/restaking/jito-restaking-overview/)
- [Jito MEV – Tip Distribution Program](https://jito-foundation.gitbook.io/mev/mev-payment-and-distribution/tip-distribution-program)
- [JIP-24 – Jito DAO receives Block Engine & BAM fees](https://forum.jito.network/t/jip-24-jito-dao-receives-all-jito-block-engine-fees-and-future-bam-fees/860)
- [CoinDesk – Jito proposes routing 100% of Block Engine fees to the DAO (5 Aug 2025)](https://www.coindesk.com/tech/2025/08/05/solana-s-jito-proposes-routing-100-of-block-engine-fees-to-dao-treasury)
- [Helius – Block Assembly Marketplace (BAM)](https://www.helius.dev/blog/block-assembly-marketplace-bam)
- [Solana Compass – Jito metrics](https://solanacompass.com/projects/jito)

## Lido DAO

URL: https://caper.network/wiki/daos/staking/lido-dao
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Name** | Lido DAO |
| **Type** | Protocol DAO (liquid staking) |
| **Governance token** | LDO (ERC-20 on Ethereum; DAO voting only, no direct fee claim) |
| **Product** | stETH — the largest ETH liquid-staking token |
| **Governance model** | [Token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) Aragon on-chain voting + [Snapshot](https://snapshot.org/#/lido-snapshot.eth) signalling + Easy Track for routine ops; **Dual Governance** gives stETH holders a veto |
| **Protocol fee** | 10% of staking rewards, split between node operators and the DAO treasury |
| **Notable for** | Largest ETH staking pool; the staking-centralization debate; pioneering **Dual Governance** — a stETH-holder rage-quit safeguard over LDO votes |
| **Dual Governance status** | Live on Ethereum since 8 Aug 2025; state machine has never left `Normal` — no Veto Signalling, no rage quit (read on-chain 7 Aug 2026) |
| **Primary sources** | [docs.lido.fi](https://docs.lido.fi/), [research.lido.fi](https://research.lido.fi/), [blog.lido.fi](https://blog.lido.fi/) |
| **Related** | [Aave DAO](/wiki/daos/lending/aave-dao), [Curve DAO](/wiki/daos/dexs/curve-dao), [Rage-quit & exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) |

The **Lido DAO** governs [Lido](https://lido.fi/), the largest liquid-staking protocol on Ethereum. Users deposit ETH and receive **stETH**, a transferable token that accrues staking rewards while remaining usable across DeFi — so a staker keeps liquidity instead of locking ETH in a validator. The protocol is run by holders of the **LDO** governance token, who set the node-operator set, protocol parameters, and the fee — currently **10% of staking rewards**, split between node operators and the DAO treasury. Because Lido stakes a very large share of all ETH, its governance is not just a protocol matter but a live question about the decentralization of Ethereum itself. ([Lido docs](https://docs.lido.fi/))

## stETH and the liquid-staking model

Solo staking on Ethereum requires 32 ETH, dedicated hardware, and a locked position. Lido removes all three constraints: any amount of ETH can be deposited, the protocol routes it to a curated set of professional **node operators**, and the depositor receives **stETH** that rebases daily with rewards and can be traded, lent, or used as collateral. That composability is why stETH became one of the most widely integrated assets in DeFi — and why it anchors the collateral base of protocols like [Aave](/wiki/daos/lending/aave-dao).

The trade-off is trust in Lido's operator set and smart contracts. Historically the operators were a DAO-curated whitelist; to widen participation Lido added the permissionless **Community Staking Module (CSM)**, letting independent operators join with a bond rather than a governance vote. Node-operator selection, module parameters, and withdrawal mechanics are all controlled by LDO governance. ([docs.lido.fi](https://docs.lido.fi/))

## The centralization debate

Lido's success created the problem it is best known for. Because it pools stake from many users behind one protocol, Lido at times controlled roughly a third of all staked ETH — close to the **one-third threshold** at which a single actor can affect Ethereum's finality, and well within sight of the two-thirds level that matters for consensus safety. Critics argued that a single liquid-staking protocol approaching these thresholds undermines the very decentralization staking is meant to secure; a widely debated 2021 research-forum proposal even asked whether Lido should _self-limit_ its share of the network. Lido's answer has been to decentralize _within_ the protocol — more independent operators, the CSM, distributed-validator technology — rather than cap deposits. Rivals such as [Rocket Pool](/wiki/daos/staking/rocket-pool) make the opposite structural bet — a permissionless node-operator set from the start, at the cost of the curated professionalism Lido relies on. The debate remains one of the sharpest governance questions in Ethereum. ([Lido research forum](https://research.lido.fi/); [Lido blog](https://blog.lido.fi/))

## Dual Governance — giving stakers a veto

LDO holders decide, but the people most exposed to a bad decision are **stETH holders**, who may hold no LDO at all. **Dual Governance**, approved by an LDO vote in mid-2025 (about **53.6M LDO** in favour against a 50M-LDO quorum, with a single dissenting vote) and rolled out to Ethereum thereafter, closes that gap by inserting a dynamic timelock that stETH holders can extend. It is one of the most closely watched governance mechanisms in DeFi because it grafts an _exit-based safeguard_ onto a token-weighted DAO, and it is the largest live instance of [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance): the second constituency can delay or leave, never propose. ([The Block](https://www.theblock.co/post/360212/lido-dao-votes-to-enable-dual-governance-giving-stakers-veto-power); [Dual Governance 101](https://blog.lido.fi/dual-governance-101-explainer/))

Every governance action affecting Lido on Ethereum is routed through an [Emergency Protected Timelock](https://etherscan.io/address/0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316#readContract) whose governance address is the [DualGovernance](https://etherscan.io/address/0xC1db28B3301331277e307FDCfF8DE28242A4486E#readContract) contract. Even entirely unopposed, a proposal waits **3 days** after submission before it can be scheduled and a further **1 day** before it can execute. Dissent is registered by depositing stETH into a [signalling escrow](https://etherscan.io/address/0x165813A31446a98c84E20Dda8C101BB3C8228e1c#readProxyContract), and the escrowed share drives a five-state machine:

- **Veto Signalling** — once escrowed stETH crosses the _first seal_ at **1% of stETH supply**, execution is delayed on a sliding scale, from **5 days** up to a maximum of **45 days** as more stETH piles in, buying time to scrutinise the proposal.
- **Rage Quit** — if escrowed stETH crosses the _second seal_ at **10% of supply**, governance is frozen: no queued proposal can execute until the dissenting stakers have fully withdrawn their ETH. Stakers who disagree leave _before_ the change binds them.

The thresholds and durations are not protocol lore; they are immutable constants in a deployed [config provider](https://etherscan.io/address/0xa1692Af6FDfdD1030E4E9c4Bc429986FA64CB5EF#readContract) contract, readable by anyone. Read on **7 August 2026** at Ethereum block **25,705,002**:

|  |  |
| --- | --- |
| **First seal (delay begins)** | 1% of stETH supply |
| **Second seal (rage quit)** | 10% of stETH supply |
| **Veto Signalling duration** | 5 days minimum, 45 days maximum |
| **Minimum escrow lock** | 5 hours before escrowed stETH can be withdrawn |
| **Deactivation / cooldown** | 3 days maximum / 5 hours |
| **Rage-quit extension period** | 7 days |
| **ETH withdrawal delay after a rage quit** | **60 days**, growing **15 days** per consecutive rage-quit round, capped at **180 days** |
| **Base timelock (no dissent)** | 3 days after submit + 1 day after schedule |

That last-but-one row is the part the explainers tend to skip. The exit is real, but it is not fast: a staker who rage-quits waits at least two months after their withdrawal finalises before touching the ETH, and a DAO whose stakers keep rage-quitting stretches that toward six. The delay is deliberate — it prices repeated use of the escape hatch — but it means "exit" here is a slow, one-directional decision rather than a liquid one. ([DualGovernanceConfig.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/libraries/DualGovernanceConfig.sol))

The design was audited by multiple firms (Certora, OpenZeppelin, Statemind, Runtime Verification) and lives in the [lidofinance/dual-governance](https://github.com/lidofinance/dual-governance) contracts. It borrows the name and spirit of Moloch's [rage quit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), applied to a two-token structure: LDO proposes, stETH can veto or exit. ([Dual Governance overview](https://blog.lido.fi/dual-governance-overview/))

## The on-chain record, one year in

Dual Governance is usually described in the conditional — what stETH holders _could_ do. The deployed contracts also record what they have actually done, and the answer is nothing at all. Every figure below was read from Ethereum mainnet on **7 August 2026** at block **25,705,002**; the addresses are published on [Lido's deployed-contracts page](https://docs.lido.fi/deployed-contracts/).

The [DualGovernance](https://etherscan.io/address/0xC1db28B3301331277e307FDCfF8DE28242A4486E#readContract) state machine was initialised on **8 August 2025 at 10:21:47 UTC** and its persisted state has read `Normal` ever since. Three fields in `getStateDetails()` make that a definitive claim rather than a snapshot:

- `normalOrVetoCooldownExitedAt` is **0** — the machine has never left the Normal state, because that field is stamped on any exit from it and is never cleared.
- `vetoSignallingActivatedAt` is **0** — Veto Signalling has never once been entered. That field is set on entry and never reset. ([DualGovernanceStateMachine.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/libraries/DualGovernanceStateMachine.sol))
- `getRageQuitEscrow()` returns the **zero address**, which the contract's own documentation states means "no rage quits have occurred in the system". ([DualGovernance.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/DualGovernance.sol))

Meanwhile the timelock has been busy. [getProposalsCount()](https://etherscan.io/address/0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316#readContract) returns **12**, and every one of the twelve carries status `Executed` — none cancelled, none stuck. Each was scheduled exactly 3 days after submission, the minimum the timelock allows, from the first on 29 May 2025 to the twelfth on 20 July 2026. The safeguard has never been the reason a Lido proposal was late.

The reason is visible in the size of the bar. stETH total supply at the same block was **9,432,901 stETH**, so the first seal — the point at which a proposal is delayed by even five days — requires roughly **94,329 stETH** to be escrowed, and freezing governance outright requires about **943,290 stETH**. The [signalling escrow](https://etherscan.io/address/0x165813A31446a98c84E20Dda8C101BB3C8228e1c#readProxyContract) currently holds **0.0000114 stETH**, and `getRageQuitSupport()` reads **0.00000000012%**. In practice the escrow is empty, and has been for a year.

Two honest readings of that record compete, and the wiki takes neither on faith. One: the veto is a deterrent working as designed, shaping which proposals are drafted at all, and a mechanism that never fires can still be doing its job — the [optimistic-governance](/wiki/dao-governance/concepts/voting/optimistic-governance) case. Two: a threshold of ~94,329 stETH held by a dispersed, mostly passive holder base is a coordination problem no one has yet solved, and the veto is nominal. Nothing on-chain distinguishes the two, and the twelve uncontested proposals do not decide it either way. What the record does settle is narrower and worth stating plainly: **as of August 2026 the largest deployed exit-based safeguard in DeFi has never been used**.

One dated caveat belongs alongside it. The timelock still carries **emergency protection**: an activation committee and an execution committee that can put the system into a 30-day emergency mode and execute outside the normal flow. `isEmergencyModeActive()` reads `false`, and `getEmergencyProtectionDetails()` gives an expiry of **20 June 2027**, after which those committee powers lapse on their own. Until then, Dual Governance runs with a training-wheel override that its final form will not have. ([EmergencyProtectedTimelock](https://etherscan.io/address/0xCE0425301C85c5Ea2A0873A2dEe44d78E02D2316#readContract); [committee addresses](https://docs.lido.fi/deployed-contracts/))

## How Caper approaches this

Dual Governance is a retrofit: Lido started as a token-weighted DAO and later bolted on a _second_ constituency (stETH) with a veto and an exit, because the holders bearing the risk had no direct say. A [caper](/wiki/foundations/what-is-a-caper) reaches the same destination from the opposite direction — it is built so voice and exit are the _same_ right from day one. There is no separate escrow, no 1%/10% thresholds to organise, and no second token class: every member's [voting weight](/wiki/governance/voting) and their [pro-rata claim on the treasury at exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) are one and the same number, combining the stake they hold with the participation they have shown. A member who dislikes where a caper is heading does not need to accumulate a veto quorum; they can always [exit](/wiki/governance/execution) for their share, immediately. Lido's mechanism is the more general fix for the enormous installed base of one-token DAOs; a caper is what that safeguard looks like when it is native rather than grafted on. The exact exit math is on the linked governance pages, verified against the contract — no additional guarantees are implied here.

## References

- [Lido documentation](https://docs.lido.fi/) — protocol, staking modules, and governance reference.
- [Lido deployed contracts](https://docs.lido.fi/deployed-contracts/) — the mainnet addresses for DualGovernance, the config provider, the signalling escrow and the Emergency Protected Timelock (primary).
- [Lido research forum](https://research.lido.fi/) — proposals and the decentralization debate (primary source).
- [Dual Governance 101: Explainer](https://blog.lido.fi/dual-governance-101-explainer/) and [Dual Governance: An Overview](https://blog.lido.fi/dual-governance-overview/) — the veto/rage-quit mechanism and thresholds.
- [lidofinance/dual-governance](https://github.com/lidofinance/dual-governance) — the audited contracts; [DualGovernanceStateMachine.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/libraries/DualGovernanceStateMachine.sol) and [DualGovernanceConfig.sol](https://github.com/lidofinance/dual-governance/blob/main/contracts/libraries/DualGovernanceConfig.sol) carry the state-transition and delay-growth logic quoted above.
- The Block, [Lido DAO votes to enable dual governance](https://www.theblock.co/post/360212/lido-dao-votes-to-enable-dual-governance-giving-stakers-veto-power) (2025) — the approving vote.

## Marinade (MNDE)

URL: https://caper.network/wiki/daos/staking/marinade
Updated: 2026-07-27

| Project | Marinade Finance |
| --- | --- |
| Category | Liquid & native staking (Solana) |
| Token | MNDE (governance) · mSOL (liquid-staking receipt) |
| Chain | Solana |
| Governance | Marinade DAO (mDAO) — locked-MNDE voting on [Realms / SPL Governance](https://realms.today/) |
| Launched | 2021 |
| Status | 🟢 Active |
| Website | [marinade.finance](https://marinade.finance) |

**Marinade** is a stake-automation protocol on [Solana](https://solana.com) and one of the network's earliest and largest liquid-staking DAOs. It spreads a depositor's SOL across a competitively-selected set of validators and returns either a non-custodial native stake or the liquid receipt token **mSOL**. What makes Marinade a governance case study rather than just a staking product is that the _delegation itself_ is the thing being governed: which validators receive stake, and on what terms, is decided by an on-chain marketplace and by MNDE token-holders — the [delegation-strategy-as-governance](/wiki/dao-governance/concepts/voting/voting-and-delegation) pattern.

## What Marinade is

Marinade offers two ways to stake, both driven by the same validator-selection logic and paying rewards each Solana epoch (~2–3 days):

- **Marinade Native** — a non-custodial delegation system where the SOL never leaves the user's own stake accounts; Marinade only sets the delegation. There is no receipt token and no smart-contract custody risk.
- **Liquid staking (mSOL)** — the user's SOL is pooled and they receive **mSOL**, a value-accruing token that can be redeployed across Solana DeFi ([Kamino](https://kamino.finance), [Orca](https://www.orca.so), [Raydium](https://raydium.io)) while continuing to earn staking rewards.

Around these sit **Marinade Select** (a curated, verified validator set aimed at institutions), instant unstake (a liquidity pool that lets stakers exit without waiting for the epoch cooldown, for a fee), and protected staking-reward mechanisms. Marinade reports 150,000+ holders and has operated [since 2021](https://marinade.finance).

## The Stake Auction Marketplace (SAM)

SAM is Marinade's distinctive mechanism and the clearest example of turning validator selection into an open market. Instead of a hand-tuned scoring formula deciding who gets stake, validators _bid_ for it in two ways:

- **Static bids (CPMPE)** — a fixed cost per 1,000 SOL delegated per epoch, paid out of the validator's on-chain _bond_.
- **Dynamic commission bids** — a basis-point share of the rewards the validator earns (inflation, [MEV](/wiki/daos/staking/jito), and block rewards) passed back to stakers, without changing the validator's public commission rate.

Validators are ranked by `max_yield` — the total yield they can offer stakers at a given stake level (commission plus bid). Marinade runs a **last-price (uniform-clearing) auction**: stake is allocated top-down until it runs out, and the `realized_yield` paid to everyone is set by the _lowest-ranked winning validator_. Validators who bid above that clearing price only pay enough to match it, not their full bid. A single validator is capped at **15% of Marinade's total stake** (set by [MIP-19](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market)) to preserve decentralization. The full mechanism is documented in the [SAM overview](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market).

## Governance: the Marinade DAO

The **Marinade DAO (mDAO)** is constituted of MNDE holders who _lock_ their MNDE in governance; locked MNDE confers voting power and access to the token's utilities — a vote-lock design in the same family as [vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow), layered on top of [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting). Voting runs on-chain through [Realms](https://realms.today/) and [SPL-Governance](/wiki/dao-governance/tooling/frameworks/spl-governance), so proposal rules are enforced by smart contracts and the record is public.

Marinade Improvement Proposals (MIPs) set the parameters that matter — the SAM per-validator cap, bond and commission rules, treasury use, and product changes — which keeps the delegation policy accountable to token-holders rather than to a closed operator. MNDE has a 700M maximum supply.

## Where Marinade fits

Marinade is the pure liquid-staking-DAO archetype on Solana, distinct from its network sibling [Jito](/wiki/daos/staking/jito), which pairs its JitoSOL LST with an MEV block-engine and tip market. On Ethereum the closest analogues are [Lido](/wiki/daos/staking/lido-dao) (dominant-share LST with an off-chain operator set), [Rocket Pool](/wiki/daos/staking/rocket-pool) (permissionless node operators), and [ether.fi](/wiki/daos/staking/ether-fi) — and, one layer out, [EigenLayer](/wiki/daos/staking/eigenlayer)'s restaking. Marinade's contribution to the design space is the _auction_: it replaces a governed scoring formula with a market that lets validators compete on yield, which is a cleaner answer to the "who decides where the stake goes, and can they be captured" question that [sinks many DAOs](/wiki/dao-governance/concepts/analysis/how-daos-fail).

## How Caper approaches this

Marinade's design answers a question Caper answers differently: how do you keep the people steering a pool of value honest? Marinade uses an open auction plus locked-MNDE voting; a [caper](/wiki/foundations/what-is-a-caper) instead makes _leaving_ the discipline. Governance weight is not raw token balance but a participation-weighted figure — the canonical formula `w = (t · v) / (V · T)` multiplies a member's holdings by how much they have actually voted, so a large passive bag alone captures no control (verified against `compute_vote_weight` in `contracts/logic/src/lib.rs`). And any member can always [exit](/blog/the-exit-right), redeeming a pro-rata slice of the treasury sized by that same vote weight (the `exit` path in the same contract requires both the governance and the soulbound vote token, and computes the share pre-burn). Where Marinade leans on markets and vote-locks to align a delegation strategy, Caper leans on a credible, always-open exit to keep a treasury's stewards accountable. See [how Caper proposals work](/wiki/governance/proposals).

## Rocket Pool

URL: https://caper.network/wiki/daos/staking/rocket-pool
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Name** | Rocket Pool |
| **Type** | Protocol DAO (liquid staking) |
| **Governance token** | RPL (ERC-20 on Ethereum; node-operator collateral + [pDAO voting power](/wiki/dao-governance/concepts/voting/token-weighted-voting)) |
| **Product** | rETH — a permissionless, decentralized ETH liquid-staking token |
| **Governance model** | Two-tier: an on-chain **Protocol DAO** (RPL holders, square-root-weighted) plus a trusted-node **Oracle DAO**; an elected **security council** guards upgrades |
| **Node model** | Permissionless minipools — anyone can run a node with an ETH bond + RPL collateral (no allowlist) |
| **Notable for** | The decentralization-first alternative to curated liquid staking, and a rare square-root anti-whale governance weight |
| **Links** | [rocketpool.net](https://rocketpool.net/) · [docs](https://docs.rocketpool.net/) · [governance forum](https://dao.rocketpool.net/) · [RPIPs](https://rpips.rocketpool.net/) |

**Rocket Pool** is a decentralized [liquid-staking](/wiki/daos/staking/lido-dao) protocol on Ethereum, governed by RPL holders and a set of trusted oracle nodes. It issues **rETH**, a reward-bearing token that appreciates against ETH as staking rewards accrue. Where the largest staking protocols run a curated, DAO-approved set of professional node operators, Rocket Pool's defining choice is a _permissionless_ operator set: anyone can run a node by posting an ETH bond and RPL collateral, with no allowlist. That decision shapes both the product and the governance, which Rocket Pool splits across two distinct DAOs. Sources throughout link to Rocket Pool's own documentation and its [RPIP](https://rpips.rocketpool.net/) improvement-proposal register.

## rETH and the permissionless node-operator model

Solo staking on Ethereum requires 32 ETH and continuous uptime. Rocket Pool lets ordinary users deposit any amount of ETH for **rETH** — a token whose exchange rate rises as the underlying validators earn rewards — while a separate class of participants, **node operators**, actually run the validators. An operator spins up a _minipool_, posting a personal ETH bond ([Saturn I](https://saturn.rocketpool.net/) lowers the bond toward 4 ETH via _megapools_) plus **RPL collateral** that is slashed if they underperform. Because operators are permissionless, Rocket Pool's node set is far more numerous and geographically diffuse than a curated one — the [Lido](/wiki/daos/staking/lido-dao) centralization critique is the exact problem Rocket Pool designs against. The tradeoff is that permissionless operators can't be trusted with protocol admin, which is precisely why governance is split in two. See the [protocol docs](https://docs.rocketpool.net/) for the full minipool and rETH mechanics.

## Two DAOs: the pDAO and the oDAO

Rocket Pool separates _who sets policy_ from _who reports trusted facts_:

- **Protocol DAO (pDAO)** — the RPL-holder governance body that shapes protocol direction: parameters, treasury/inflation, upgrades. Voting power is a function of _effective RPL stake_ held by node operators (see the next section).
- **Oracle DAO (oDAO)** — a small set of well-regarded staking-ecosystem members running special nodes that supply data the smart contracts cannot compute for themselves (validator balances, the rETH exchange rate, reward Merkle trees) and execute mandated administrative steps. Its remit, membership, and slashing rules are fixed by [RPIP-24, the oDAO Charter](https://rpips.rocketpool.net/RPIPs/RPIP-24).

This is a deliberate answer to a hard problem: a permissionless validator set needs some trusted party to attest to off-chain reality, but that trusted party should not also control policy. The oDAO is intentionally narrow — an oracle and executor, not a legislature — while the pDAO holds the political power. Rocket Pool has openly worked to [reduce the residual centralization](https://www.theblock.co/post/237808/rocket-pool-promises-to-fix-centralization-concerns-related-to-pdao) in how the two interact.

## On-chain pDAO governance: square-root weight and layered votes

The Houston upgrade moved the pDAO fully on-chain ([RPIP-33](https://rpips.rocketpool.net/RPIPs/RPIP-33)), replacing pure [Snapshot](https://snapshot.org/) signalling with binding contract execution. Two features stand out:

- **Square-root voting weight.** A node operator's pDAO power is scored on the _square root_ of their effective RPL stake — so the larger the stake, the less voting power per RPL. The explicit goal, per Rocket Pool's design notes, is to temper large operators and let blocs of smaller operators actually move a vote. This is a rare on-chain anti-whale weight, distinct from the linear [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) most protocols use.
- **Snapshot-and-override voting.** Eligibility, delegation state, and power are frozen at a snapshot when a proposal is created. There are two voting periods: first delegates (and direct voters) cast votes, then members who had delegated their power get a window to _override_ their delegate's choice. A **veto quorum** lets the community instantly defeat a proposal — and the proposer forfeits their bond — to deter spam and proposals that skipped off-chain signalling.

Proposal creation and challenges are bonded throughout, so putting a bad proposal on-chain has a real cost. The full rules live in [RPIP-4](https://rpips.rocketpool.net/RPIPs/RPIP-4) and the [governance guides](https://docs.rocketpool.net/).

## The security council and upgrade guardrails

A fully on-chain, permissionless governance layer needs a circuit breaker. Rocket Pool elects a **security council** whose members can pause the protocol quickly if something goes wrong and can make certain parameter changes without waiting out the normal delay. The council is itself controlled by the pDAO, which sets the required quorum and can replace members. [RPIP-60](https://rpips.rocketpool.net/RPIPs/RPIP-60) formalizes these _protocol upgrade guardrails_: upgrades authorized by a pDAO vote pass through a mandatory delay during which the security council can veto, and are then executed on-chain by the oDAO. The current [Saturn I](https://saturn.rocketpool.net/) upgrade — halving the operator bond, introducing megapools, express/standard deposit queues, and adjustable commission — was authorized by pDAO vote and scheduled for oDAO execution after the mandated delay, a live demonstration of the whole two-DAO-plus-council pipeline.

## How Caper approaches this

Rocket Pool's answer to plutocracy is a _concave function of capital_: square-root the RPL stake so whales get less power per token, add a trusted oracle set for facts, and elect a council to catch emergencies. It is clever, and it needs no participation history — power is still bought with RPL, just at a diminishing rate. [Caper](/wiki/foundations/what-is-a-caper) makes a different bet. A caper's vote weight is `(t·v)/(V·T)` — held tokens `t` times the member's _earned_ [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) votes `v`, over supply — computed by the contract's `compute_vote_weight` helper and reused verbatim by `exit()` to size a member's treasury share. The vote token is `DIVISIBILITY_NONE`, minted one per vote, and non-transferable (its depositor role is locked to the DAO itself), so the participation factor cannot be bought, rented, or delegated away. This is not a bagless system — `t` is a genuine multiplier, so stake still counts — but the decisive factor a well-funded buyer cannot acquire is the earned soulbound record, not a curve applied to their capital. And there is no separate oracle DAO or elected council to trust: typed `PAYOUT`/`INVEST`/`VOTE` proposals execute directly against a protocol-controlled treasury vault. Honestly, that means a caper forgoes exactly the professional operator layer and emergency council Rocket Pool provides; the wager is that earned, un-buyable weight plus a minimal on-chain surface beats a trusted set you have to keep honest.

## References

- [Rocket Pool](https://rocketpool.net/) — protocol site and rETH overview.
- [Rocket Pool documentation](https://docs.rocketpool.net/) — minipools, node operation, and Houston governance guides.
- [RPIP-33](https://rpips.rocketpool.net/RPIPs/RPIP-33) — implementation of an on-chain pDAO; [RPIP-4](https://rpips.rocketpool.net/RPIPs/RPIP-4) — community resolutions and voting.
- [RPIP-24](https://rpips.rocketpool.net/RPIPs/RPIP-24) — the Oracle DAO Charter; [RPIP-60](https://rpips.rocketpool.net/RPIPs/RPIP-60) — protocol upgrade guardrails.
- [Saturn I](https://saturn.rocketpool.net/) — the current upgrade (megapools, 4 ETH bond, queues).
- [Rocket Pool governance forum](https://dao.rocketpool.net/) — live pDAO discussion and proposals.

## Decentralized Publishing & Peer Review

URL: https://caper.network/wiki/desci/decentralized-publishing
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | Decentralized publishing & peer review |
| **What it is** | Open-access, content-addressed _research objects_ plus credited, paid, on-chain peer review – replacing paywalled journals and unpaid, opaque review |
| **Key tools** | [ResearchHub / ResearchCoin](/wiki/desci/ecosystem/researchhub), [DeSci Nodes](https://www.desci.com/publish) & [dPID](https://www.dpid.org/), [DeSci Codex](https://www.desci.com/blog/how-desci-codex-makes-scientific-research-durable-reusable-and-ai-ready) |
| **Part of** | [Decentralized Science (DeSci)](/wiki/desci/what-is-desci) |
| **Reference** | [ethereum.org/desci](https://ethereum.org/en/desci/) |

## Overview

**Decentralized publishing and peer review** is the DeSci pillar that targets how research is _disseminated and validated_, sitting alongside [novel funding](/wiki/desci/desci-funding), [IP-NFTs](/wiki/desci/ip-nfts), and [DeSci DAOs](/wiki/desci/desci-daos). The traditional stack – a handful of commercial journals gate-keeping both distribution and validation – is the part of science the [Ethereum Foundation's DeSci hub](https://ethereum.org/en/desci/) singles out for “creating, reviewing, crediting, storing, and disseminating” knowledge on open infrastructure.

### The problem it targets

- **An extractive publishing cartel.** A few publishers dominate the literature at margins that dwarf most of tech: Elsevier has run a [profit margin approaching 40%](https://tidsskriftet.no/en/2020/08/kronikk/money-behind-academic-publishing), sustained because the manuscripts, editing, and peer review are supplied for free by publicly-funded academics.
- **Peer review is unpaid and opaque.** Reviewers work without compensation and without public credit. In [March 2025 four researchers sued six of the largest publishers](https://www.statnews.com/2025/03/10/peer-review-antitrust-lawsuit-academic-scientific-journals-sued-by-scientists/), alleging they colluded not to pay for peer review – a direct challenge to the free-labor model.
- **Paywalls and shifted costs.** Publicly-funded results sit behind subscriptions; open-access “fixes” often just move the bill to authors via article-processing charges.
- **The PDF loses the science.** Data, code, and provenance are stripped out of a flat file, making results hard to reproduce, reuse, or machine-read.

## What decentralized publishing changes

The core move is to publish a **research object** rather than a document: manuscript, data, code, figures, and metadata bundled as one versioned, independently-addressable unit.

- **Content-addressed, persistent identifiers.** [DeSci Nodes](https://www.desci.com/publish) auto-assign a [dPID](https://www.dpid.org/) (decentralized persistent identifier) built on content identifiers (CIDs) – cryptographic fingerprints that pin an exact version, guard against [content drift](https://docs.desci.com/create-and-publish/share/persistent-identifier-dpid), and let readers cite an individual component, not just a whole paper.
- **Beyond the PDF.** [DeSci Codex](https://www.desci.com/blog/how-desci-codex-makes-scientific-research-durable-reusable-and-ai-ready) is an open protocol for durable, reusable, AI-ready research objects with a transparent version history – the container the flat file never was.
- **Open access by default.** Preprint-first publishing puts the work in public the moment it is submitted, before – not after – review.
- **Credit becomes an on-chain asset.** Reviews and contributions are recorded as attestations tied to a wallet, so a reviewer accrues portable reputation instead of anonymous, uncredited labor.

## Paying for peer review: ResearchHub & ResearchCoin

[ResearchHub](/wiki/desci/ecosystem/researchhub) is the clearest working model for the paid-review thesis. Its journal pays reviewers **$150 in ResearchCoin (RSC)** for a completed peer review, is [open access by default](https://www.researchhub.com/journal) with every submission immediately available as a preprint, and targets peer review in **as few as 14 days** – a fraction of a traditional journal's timeline. RSC also funds bounties across the platform, though its [governance role is thinner than it looks](/wiki/desci/ecosystem/researchhub) – RSC has no on-chain voting machinery, and Snapshot votes are non-binding signals.

The token moved onto major venues over 2025 – listed on [Coinbase (Base network) on 31 July 2025 and Kraken on 17 November 2025](https://coinmarketcap.com/currencies/researchcoin/) – and ResearchHub has integrated with [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) and [Molecule](/wiki/desci/ecosystem/molecule) to route RSC bounties into an on-chain research workflow, pulling peer review directly into the [BioDAO](/wiki/desci/desci-daos) funding pipeline.

## Infrastructure and standards

Under the platforms sits open, publicly-inspectable infrastructure. [DeSci Labs](/wiki/desci/ecosystem/desci-labs)'[ Nodes](https://github.com/desci-labs/nodes) are open-source “secure PID containers for interoperable research objects,” and the [dPID protocol](https://www.dpid.org/) standardizes how those objects are named and resolved so citations point at durable, content-addressed artifacts rather than link-rotting URLs. Because objects are versioned and fingerprinted, the [provenance chain](https://docs.desci.com/create-and-publish/share/persistent-identifier-dpid) – who published what, when, and what changed – is auditable rather than taken on trust. This is the same shift the rest of DeSci makes with [IP-NFTs](/wiki/desci/ip-nfts): turn an opaque institutional record into an open, portable, on-chain one.

## How Caper approaches this

Caper is a [DAO protocol](/wiki/foundations/what-is-a-caper), not a publishing platform – it does not host papers or run peer review. But it shares the load-bearing principle underneath decentralized review: **credit and influence should be earned and non-transferable.** Paid on-chain peer review works precisely because a reviewer's reputation is accrued by contribution and stays attached to them; it is not a badge anyone can buy.

Caper's governance carries the same idea into who steers a treasury. Every vote mints a [soulbound proof-of-vote token](/wiki/dao-governance/concepts/membership/soulbound-tokens) – non-divisible and non-transferable in the contract (`DIVISIBILITY_NONE`, deposits gated to the component's own calls) – and a member's earned voting record folds directly into both their vote weight and their exit share, computed as `(held · votes) / (supply · circulation)`. Influence you accumulate by turning up cannot be bought or sold, mirroring the reviewer-reputation model on-chain publishing is trying to build. It is not bag-less – holdings still multiply weight – but the decisive, participation-earned factor is un-buyable by design. (Verified against `contracts/logic/src/lib.rs` for the weight formula and `contracts/core/src/caper_dao.rs` for the soulbound vote token.)

## Decentralized Science Funding

URL: https://caper.network/wiki/desci/desci-funding
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Topic** | DeSci funding mechanisms |
| **Models** | Quadratic funding · Retroactive funding · Token-curated grants · IP-NFT deals · Curve-funded treasuries |
| **Used by** | [Gitcoin](/wiki/desci/ecosystem/gitcoin-desci), [VitaDAO](/wiki/desci/ecosystem/vitadao), [Bio Protocol](/wiki/desci/ecosystem/bio-xyz), [Optimism](/wiki/daos/networks/optimism-collective) (retro funding — **paused** Jan 2026) |
| **Related** | [What is DeSci](/wiki/desci/what-is-desci), [DeSci DAOs](/wiki/desci/desci-daos), [IP-NFTs](/wiki/desci/ip-nfts) |

**Decentralized science funding** is the family of mechanisms [DeSci](/wiki/desci/what-is-desci) uses to route capital to research without a central grant committee: community-weighted matching, pay-for-demonstrated-impact, token-holder-curated grants, and treasuries that fill continuously from token markets rather than episodic fundraising.

## Why science funding is being rethought

Traditional grant funding concentrates decisions in a small number of agencies and committees, with long cycles and heavy application overhead. The pressure became acute after the 2025 wave of U.S. federal research-funding cuts: a [JAMA Internal Medicine study](https://jamanetwork.com/journals/jamainternalmedicine/article-abstract/2840939) found that NIH grant terminations disrupted 383 active clinical trials — about 1 in 30 — affecting more than 74,000 enrolled participants. Against that backdrop [health-research commentators](https://partnersindigitalhealth.substack.com/p/decentralized-science-desci-and-the) began treating decentralized funding, governance, and data-sharing as credible alternative infrastructure rather than a Web3 curiosity. Roughly 50 active DeSci initiatives now span funding DAOs, publishing, healthcare data, and IP management.

## Quadratic funding

[Quadratic funding](https://wtfisqf.com) amplifies a matching pool by the _breadth_ of community support: many small donations attract more matching than one whale donating the same total, because the match scales with the square of the sum of square roots of contributions. [Gitcoin](https://gov.gitcoin.co) made it the default mechanism for open-source and public-goods funding and has run [dedicated DeSci rounds](/wiki/desci/ecosystem/gitcoin-desci) distributing community-matched grants to research projects. The mechanism is set out in full on [quadratic voting and funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding).

The most recent large round shows both the scale and the strain. **Gitcoin Grants 24 (GG24)** distributed [over $1.8 million across six thematic domains](https://gitcoin.co/case-studies/gg24-first-funding-round-of-gitcoin-3-0), with donation rounds running **14–28 October 2025**. Of that, **$1.175 million** was Gitcoin's own matching and roughly **$632,500** came from external partners — the first Gitcoin round in which more than a third of the matching capital originated outside the core DAO treasury. The two open-source quadratic-funding domains, operated with [Giveth](/wiki/daos/public-goods/giveth), drew **$36,657 in direct donations** amplified by **$300,000 in matching** to **78 projects** from roughly **1,300 unique donors** ([results thread](https://gov.gitcoin.co/t/gg24-oss-quadratic-funding-results/24782)).

GG24 is also notable for refusing to be a single-mechanism round: it combined quadratic funding with conviction voting, retroactive funding, [MACI private voting](/wiki/dao-governance/concepts/voting/private-and-shielded-voting), Deep Funding, and peer-reviewed [hypercerts](/wiki/dao-governance/concepts/treasury/hypercerts) in one cycle. For a DeSci funder the practical reading is that no single allocation rule is treated as settled — matching, judged impact, and private ballots are now run side by side and compared.

## Retroactive funding

Retroactive public-goods funding inverts the grant: instead of predicting which proposals will succeed, it rewards work that has already proven valuable — on the theory that it is easier to agree on what _was_ useful than on what _will be_. The model was popularized by [Optimism's Retro Funding rounds](https://docs.optimism.io/governance), which have distributed hundreds of millions of OP to infrastructure and tooling, and DeSci programs borrow it for reproducibility work and datasets whose value only shows after publication. The full design, its judging problem, and its results are covered on [retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding).

**The canonical implementation is currently paused.** Announcing Season 9 on **8 January 2026**, the Optimism Foundation stated that “[the Retro Funding program will not run for at least the next 12 months](https://www.optimism.io/blog/season-9-from-experiment-to-organization)”, and flagged a possible re-allocation of the ~775M OP reserved for it. Any DeSci programme designing around retroactive funding should treat Optimism as a source of method rather than as a live matching partner — see [Optimism Collective](/wiki/daos/networks/optimism-collective).

## Token-curated grants and IP-NFT deal flow

[DeSci DAOs](/wiki/desci/desci-daos) put funding decisions to their token holders: proposals are sourced and reviewed (typically by expert working groups), then approved by token vote, with the funded intellectual property tokenized as an [IP-NFT](/wiki/desci/ip-nfts) held by the DAO — a structure pioneered by [Molecule](/wiki/desci/ecosystem/molecule) ([docs](https://docs.molecule.xyz)). [VitaDAO](/wiki/desci/ecosystem/vitadao) has deployed [$4.7M across 31 research projects](https://www.vitadao.com/research) this way, and vertical DAOs replicate the model per disease area — [HairDAO](https://www.hairdao.xyz) for hair loss, [CryoDAO](https://www.cryodao.org) for cryopreservation research.

Where that expert review is scored and published, it becomes a gate in its own right rather than advice to voters. [VitaDAO](/wiki/desci/ecosystem/vitadao) runs a "senior review" in which a panel scores a proposal out of 5 across seven categories before it reaches a token vote: [VDP-164](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052), a $500,000 loan to a portfolio company, drew an overall conviction score of 2.3 against an average of 3.7 for previously funded projects, and has not appeared on the DAO's Snapshot space since. A low score does not reject a proposal under any written rule – it strands one, which is a different accountability problem from the one token voting is usually accused of – and VitaDAO's forum has since gone offline, so that thread now exists only in the Internet Archive.

## Launchpads and curve-funded treasuries

The newest layer skips grant rounds entirely: launchpads such as [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) curate new bioDAOs and fund them through token launches, so the research treasury fills from an open token market and keeps filling as the token trades — continuous funding priced by the crowd instead of a committee.

## What the 2026 retrenchment means for research funders

Two of the sector's largest public-goods funders moved in the same direction within a year, and the pattern matters more than either event. Optimism paused its programme outright; Gitcoin kept running but sourced more than a third of GG24's matching pool externally rather than from its own treasury. Both are symptoms of the same structural fact: **a matching pool funded from a protocol treasury is a discretionary expense, and discretionary expenses are the first thing a DAO cuts.**

That is a direct argument for the funding models the rest of this page describes. [IP-NFT](/wiki/desci/ip-nfts) deal flow gives a DeSci DAO a claim on the assets it funds rather than a donation receipt; a curve-funded treasury fills from trading rather than from an annual allocation vote. Neither is obviously better than a well-run matching round — but neither can be switched off by a single governance post, which is what a research group planning multi-year work now has to weigh.

## How Caper approaches this

Caper is built around that last model. Launching a [caper](/wiki/foundations/what-is-a-caper) puts a research community's treasury on a [bonding curve](/wiki/markets/raising-funds): anyone can buy in at a price set by the curve, and part of every trade accrues to the caper's own treasury, so funding is continuous rather than a one-shot round. The community then directs the treasury through [on-chain proposals](/wiki/governance/proposals) — **PAYOUT** pays a lab, supplier, or researcher directly; **INVEST** lets one research caper back another. Because members keep an [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) at all times, backers are never locked into an agenda they no longer support. That exit pays out the member's [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — the same number that sets their voting power — so the share tracks participation as well as stake, rather than being a flat pro-rata claim on tokens alone.

## DeSci DAOs

URL: https://caper.network/wiki/desci/desci-daos
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Topic** | Decentralized Science DAOs |
| **Focus areas** | Longevity · Psychedelics · Genomics · Women's health · Rare disease · Hair loss · Cryopreservation · Brain health · Dermatology · Climate biotech · Long COVID |
| **Examples** | [VitaDAO](/wiki/desci/ecosystem/vitadao), [PsyDAO](/wiki/desci/ecosystem/psydao), [GenomesDAO](/wiki/desci/ecosystem/genomesdao), [AthenaBIO](/wiki/desci/ecosystem/athenadao) |
| **Pages in this wiki** | 22 DeSci organisations and platforms — see the [directory](/wiki/desci/desci-daos) below |
| **Related** | [What is DeSci](/wiki/desci/what-is-desci), [DeSci funding](/wiki/desci/desci-funding), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) |

**DeSci DAOs** are [decentralized autonomous organizations](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) that fund, govern, and commercialize scientific research. Where traditional funders (NIH, ERC) concentrate decisions in review committees, a DeSci DAO lets its token holders decide which research gets funded — and, through [IP-NFTs](/wiki/desci/ip-nfts), gives the funding community a stake in the intellectual property it backs. In the [DAO taxonomy](/wiki/dao-governance/concepts/fundamentals/types-of-daos) they are a hybrid of grant DAO and investment DAO.

## How a DeSci DAO works

The typical pipeline: researchers submit proposals; an expert working group screens and negotiates terms; the token-holder community votes; and funded projects transfer rights to the DAO as an [IP-NFT](/wiki/desci/ip-nfts) — the structure pioneered by [Molecule](/wiki/desci/ecosystem/molecule) and proven by [VitaDAO](/wiki/desci/ecosystem/vitadao), which has deployed [$4.7M across 31 research projects](https://www.vitadao.com/research). Governance runs on the same machinery as any token-voting DAO (see [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models)), usually with off-chain signaling plus multisig execution.

## Directory

Every organisation below has a full page in this wiki. Therapeutic and research DAOs first, then the platform layer they run on.

### Therapeutic & research DAOs

- [VitaDAO](/wiki/desci/ecosystem/vitadao) — longevity; the flagship, with [$4.7M across 31 research projects](https://www.vitadao.com/research)
- [AthenaBIO](/wiki/desci/ecosystem/athenadao) — women's health (renamed from AthenaDAO in March 2026)
- [PsyDAO](/wiki/desci/ecosystem/psydao) — psychedelics research
- [CryoDAO](/wiki/desci/ecosystem/cryodao) — cryopreservation and biostasis
- [HairDAO](/wiki/desci/ecosystem/hairdao) — androgenic alopecia and hair loss
- [Cerebrum DAO](/wiki/desci/ecosystem/cerebrum-dao) — brain health and neurodegeneration
- [ValleyDAO](/wiki/desci/ecosystem/valleydao) — climate biotech and synthetic biology
- [Curetopia](/wiki/desci/ecosystem/curetopia) — rare disease
- [UltraRare Bio](/wiki/desci/ecosystem/ultrarare-bio) — rare disease
- [Long COVID Labs](/wiki/desci/ecosystem/long-covid-labs) — long COVID and post-viral illness
- [DermaLabs](/wiki/desci/ecosystem/dermalabs) — dermatology, funded by a consumer skincare line
- [Quantum Biology DAO](/wiki/desci/ecosystem/quantum-biology-dao) — quantum biology
- [GenomesDAO](/wiki/desci/ecosystem/genomesdao) — genomics and personal genomic-data sovereignty
- [AxonDAO](/wiki/desci/ecosystem/axondao) — user-owned health data, wearables, and compute
- [Rejuve.AI](/wiki/desci/ecosystem/rejuve-ai) — AI-driven longevity research on contributed health data
- [PeptAI](/wiki/desci/ecosystem/peptai) — peptide discovery via scientific AI agents
- [Pump.science](/wiki/desci/ecosystem/pump-science) — tokenised longevity experiments (RIF, URO)

### Platforms, infrastructure & funders

- [Molecule](/wiki/desci/ecosystem/molecule) — the [IP-NFT](/wiki/desci/ip-nfts) infrastructure most of the above run on
- [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) — the launchpad that curates, funds, and lists new bioDAOs
- [DeSci Labs](/wiki/desci/ecosystem/desci-labs) — research objects and verifiable publishing
- [ResearchHub](/wiki/desci/ecosystem/researchhub) — open publishing and peer review paid in ResearchCoin
- [Gitcoin DeSci Grants](/wiki/desci/ecosystem/gitcoin-desci) — [quadratic-funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) rounds for open science

## Scale and trajectory

As of early 2026 roughly [50 active DeSci initiatives](https://partnersindigitalhealth.substack.com/p/decentralized-science-desci-and-the) span funding DAOs, publishing platforms, healthcare data, and IP management — and the 2025 wave of U.S. federal research-funding cuts — a [JAMA Internal Medicine study](https://jamanetwork.com/journals/jamainternalmedicine/article-abstract/2840939) tied NIH grant terminations to 383 disrupted clinical trials and more than 74,000 affected participants — has pushed the model from curiosity toward credible alternative infrastructure. The bottleneck has shifted from capital to deal flow: the established DAOs report more funds than fundable, well-structured proposals.

## From grant round to launchpad

The directory splits cleanly in two, and the split is chronological. The first BioDAOs were built one at a time around a single disease area, each running its own raise and its own [IP-NFT](/wiki/desci/ip-nfts) pipeline. What followed was a platform layer that industrialised the pattern: [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) curates new bioDAOs, funds them through token launches, and lists them alongside the incumbents, describing itself as “[DeSci's new financial layer, engineered to commercialize the best science, faster](https://www.bio.xyz/)”. Its own milestones mark the turn — aggregate BioDAO token market cap crossing **$200M in November 2023**, then the **BIO Genesis raise of over $33 million in November 2024**.

The consequence for anyone reading this directory as a map: a new BioDAO in 2026 is far more likely to arrive as a curated token launch on a launchpad than as an independently bootstrapped collective, and its treasury is more likely to be denominated in its own token than in stablecoins. That is a real change in the risk a research programme carries — funding tied to a token price is continuous when the market is up and absent when it is not, which is the trade the older grant-round model did not make.

## Funding models

DeSci DAOs mix [several funding mechanisms](/wiki/desci/desci-funding): token-curated grants (the IP-NFT pipeline above), [quadratic-funding rounds](/wiki/desci/ecosystem/gitcoin-desci) for smaller open-science work, retroactive rewards for demonstrated impact, and — the newest layer — token launches that fund a treasury continuously from an open market.

## How Caper approaches this

Caper gives a lab or research community that last option natively: launch a [caper](/wiki/foundations/what-is-a-caper) and its treasury fills from a [bonding-curve token sale](/wiki/markets/raising-funds), then the member community directs funds by on-chain vote — **PAYOUT** proposals pay for experiments and equipment, **INVEST** proposals let one research caper back another, and every member keeps a participation-weighted [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) the whole time. See [DeSci on Radix](/wiki/desci/desci-and-radix) for why the platform fits research assets.

## DeSci on Radix

URL: https://caper.network/wiki/desci/desci-and-radix
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | Why the [Radix](https://www.radixdlt.com/) asset model fits [decentralized science](/wiki/desci/what-is-desci) |
| **Core advantages** | Native [IP-NFTs](/wiki/desci/ip-nfts) as first-class resources · engine-level [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) governance · atomically composable funding |
| **Programming model** | [Asset-oriented programming](https://radix.wiki/contents/tech/core-concepts/asset-oriented-programming) (assets are engine primitives, not contract balances) |
| **Live example** | [Caper](/wiki/foundations/what-is-a-caper) — bonding-curve fundraising into a member-owned treasury |
| **Related** | [DeSci DAOs](/wiki/desci/desci-daos), [DeSci funding](/wiki/desci/desci-funding), [Molecule](/wiki/desci/ecosystem/molecule) |

[**Decentralized science (DeSci)**](/wiki/desci/what-is-desci) runs into the same technical walls everywhere: research intellectual property has to be tokenized without becoming drainable smart-contract state, funding flows (matching rounds, milestone releases, IP fractionalization) have to execute without half-completing, and the [DAOs](/wiki/desci/desci-daos) that coordinate it need governance that can't be gamed at the application layer. [Radix](https://www.radixdlt.com/), a layer-1 built around **[asset-oriented programming](https://radix.wiki/contents/tech/core-concepts/asset-oriented-programming)**, addresses those three problems at the protocol level rather than leaving each project to re-solve them in Solidity. This page maps the concrete synergies and points to a live example.

## Native IP-NFTs, not contract state

On most chains an [IP-NFT](/wiki/desci/ip-nfts) is a balance recorded inside a smart contract, reachable through the [token-approval](https://radix.wiki/contents/tech/core-concepts/native-assets-vs-token-approvals) pattern — the same pattern behind the majority of DeFi drains, where a malicious or buggy `approve` lets an attacker move assets the owner never meant to release. On Radix an IP-NFT is a **native resource held in a vault**, the same kind of first-class object as the network's own token. It cannot be moved without an explicit, visible instruction in the [transaction manifest](https://radix.wiki/contents/tech/core-protocols/transaction-manifests) the owner signs, it shows up directly in the [Radix Wallet](https://radix.wiki/contents/tech/core-protocols/radix-wallet), and it composes with any protocol without granting a standing approval. For research IP whose provenance and custody are the whole point, "assets can't be drained via approval exploits" is a material property, not a nicety.

## Engine-level DAO governance

DeSci DAOs on Radix express governance through [access rules and auth zones](https://radix.wiki/contents/tech/core-concepts/access-rules-and-auth-zones) — multi-sig, role-based, and threshold controls enforced by the [Radix Engine](https://radix.wiki/contents/tech/core-protocols/radix-engine) itself, not re-implemented in each application's code. Because the rule that "only the review committee's badge can release these funds" is checked by the engine on every call, a whole class of [governance-logic bugs](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) simply cannot be written. The same mechanism gives DeSci projects a clean way to run the [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) they actually want — badge-gated peer review, staged custody of an IP-NFT, or a member vote — without trusting bespoke permission code.

## Atomic, composable funding

DeSci [funding mechanisms](/wiki/desci/desci-funding) are often multi-step: match a [quadratic-funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) round, release a milestone tranche, split royalties across IP-token holders. On Radix these run inside a single [transaction manifest](https://radix.wiki/contents/tech/core-protocols/transaction-manifests) that either commits in full or aborts entirely — **no partial failures, no funds stuck between steps**. That atomicity is what lets a raise, a treasury deposit, and a governance-badge mint happen as one indivisible action rather than a fragile sequence a user has to babysit.

## A live example: Caper

[Caper](/wiki/foundations/what-is-a-caper) is a Radix-native protocol that puts these properties to work for exactly the DeSci pattern of "raise money for a venture, then let the people who funded it govern and exit." A caper raises through a [bonding curve](/wiki/markets/bonding-curve) — contributors mint tokens along a deterministic price curve, and the proceeds accrue into a member-owned [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) rather than a founder's wallet. Funded projects are then steered by [on-chain proposals](/wiki/governance/proposals) whose weight combines token balance with earned [participation](/wiki/governance/voting-mechanisms), and any member can [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) at any time, surrendering their tokens and their participation record together for a treasury share set by that same combined weight rather than by token balance alone. For a research collective that wants a fair on-chain raise, member governance, and a standing right to leave — the recurring asks of a [DeSci DAO](/wiki/desci/desci-daos) — it is a concrete demonstration of the Radix synergies above rather than a hypothetical.

## IP-NFTs and IP Tokens

URL: https://caper.network/wiki/desci/ip-nfts
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Topic** | Intellectual Property [NFTs](https://en.wikipedia.org/wiki/Non-fungible_token) (IP-NFTs) & IP Tokens (IPTs) |
| **Originator** | [Molecule](https://www.molecule.xyz) — [open-source IP-NFT contracts](https://github.com/moleculeprotocol/IPNFT) |
| **Original model (V1–V2)** | One IP-NFT (legal rights + data room) → fractionalized into fungible IP Tokens |
| **Current model (V3)** | [Molecule Labs](https://docs.molecule.xyz/technical-deep-dive/onchain-lab) — a LabNFT bound to its own smart account, tokenized into one ERC-20 IPT per Lab |
| **Chains** | Base (Labs core, chain ID 8453); Ethereum Mainnet (legacy IPNFT, [marked UNMAINTAINED](https://docs.molecule.xyz/references/contracts)) |
| **Used by** | [VitaDAO](/wiki/desci/ecosystem/vitadao), [AthenaDAO](/wiki/desci/ecosystem/athenadao), [Molecule](/wiki/desci/ecosystem/molecule) / [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) DAOs |

## Overview

**IP-NFTs** (Intellectual Property [Non-Fungible Tokens](https://en.wikipedia.org/wiki/Non-fungible_token)) tokenize the legal rights to a piece of research as an on-chain asset. The standard was created by [Molecule](/wiki/desci/ecosystem/molecule), whose [open-source contracts](https://github.com/moleculeprotocol/IPNFT) state that “IP-NFTs allow their users to tokenize intellectual property” and describe themselves as “building blocks for the DeSci economy.” They are the primitive that lets a [DeSci DAO](/wiki/desci/desci-daos) own, fund, and govern intellectual property the way it would any other treasury asset.

The design has been through three generations. The original IP-NFT and its [Tokenizer](https://github.com/moleculeprotocol/IPNFT) shipped on Ethereum Mainnet and carried every production DeSci raise through 2024. As of Molecule Protocol V3 those contracts are [marked UNMAINTAINED in Molecule's own contract index](https://docs.molecule.xyz/references/contracts), and the live stack is **Molecule Labs** on Base. Both models matter here: the older one is what the funded research actually sits on, and the newer one is where new projects are minted.

## What the original IP-NFT held

Unlike a collectible NFT, an IP-NFT is a legal-and-data container. The [IPNFT contract on Ethereum Mainnet](https://etherscan.io/address/0xcaD88677CA87a7815728C72D74B4ff4982d54Fc1) is an ERC-721 token recording IP ownership, paired with an **AccessResolver** that grants time-limited read access to encrypted files — the underlying **data room** of research materials. The token is the on-chain hook for the off-chain agreement and dataset, not a static ownership record. A companion **CrowdSale** contract ran the token sales that funded the work.

### From IP-NFT to IP Tokens

A single IP-NFT is indivisible, so Molecule's Tokenizer contract fractionalized it into **IP Tokens (IPTs)** — [ERC-20](https://eips.ethereum.org/EIPS/eip-20) fungible tokens whose holders share governance and economic rights over the research. Fractionalization is what turns a one-off asset into something a community can fund: it enables broad participation, fundraising, and secondary-market liquidity for very early-stage science. That IP-NFT-plus-Tokenizer pair is the design most DeSci writing still describes, and it is the one the funded programmes below were built on.

## Molecule Labs: the V3 model

Molecule's current primitive is not an IP-NFT wrapping a document but a **Lab**: [“an NFT (ERC-721) that is permanently bound to its own smart contract wallet (ERC-6551), enhanced with account abstraction (ERC-4337), and extensible through a modular plugin architecture (ERC-7579) secured by an onchain attestation registry (ERC-7484)”](https://docs.molecule.xyz/technical-deep-dive/onchain-lab). Five standards converge into one object, so the research project stops being a token that _points at_ assets and becomes an account that _holds_ them — treasury, data anchor, licences, and any other [ERC-721](https://eips.ethereum.org/EIPS/eip-721) or ERC-20 an Ethereum account can hold.

Two consequences are worth understanding before modelling governance on top of a Lab:

- **Identity and control are separated.** A Lab's identity is its [token-bound account](https://eips.ethereum.org/EIPS/eip-6551) address, which is deterministic and permanent; its controller is whoever currently holds the LabNFT. Molecule's docs are explicit that `owner()` resolves the current NFT holder on every call, so ownership transfer is “an emergent property” of a plain ERC-721 `transferFrom` — [“no migration, no re-initialization, no key rotation”](https://docs.molecule.xyz/introduction/architecture). Selling the NFT sells the project, history and treasury included.
- **Capabilities are installed, not forked.** Licensing logic, royalty distribution, and governance arrive as [attested modules](https://docs.molecule.xyz/technical-deep-dive/module-registry): anyone can write one, but an [ERC-7484](https://eips.ethereum.org/EIPS/eip-7484) attestation from a trusted Molecule attestor is required before any Lab can install it. That is a deliberate trade of permissionlessness for a security gate, and it means Molecule retains a veto over what a Lab can be extended to do.

### One IPT per Lab

Tokenization moved with it. The **OclTokenizer** [“turns a Lab into a liquid asset: it deploys one fractional ERC-20 IP Token (IPT) per Lab, gated by a signed membership agreement”](https://docs.molecule.xyz/references/contracts/tokenizer). Each IPT is an [EIP-1167 minimal-proxy](https://eips.ethereum.org/EIPS/eip-1167) clone of a `LabToken` template, so every Lab has its own token address rather than a shared registry. Supply is controlled by three levers documented in the contract reference: `issue` (tokenizer or Lab controller only), `cap` (“once capped, `issue` reverts `TokenCapped()` forever, giving holders supply certainty”), and holder-initiated burning. Tokenizing requires both LabNFT control and a signed membership agreement, bound to a specific document hash so the signature cannot be replayed against a different one.

### Where the contracts live

|  |  |
| --- | --- |
| **Base Mainnet** — LabNFT (proxy) | [0x9F96…BE92](https://basescan.org/address/0x9F96027eeAFb9ad5F2b5d7043B36Ee96B2EeBE92) — Lab ownership NFT |
| **Base Mainnet** — OclTokenizer (proxy) | [0x62F5…c84E](https://basescan.org/address/0x62F532C3f563D974deEc103AAb8cC597f4f9c84E) — IPT factory |
| **Base Mainnet** — AccessResolver (v3) | [0x89a1…b72B](https://basescan.org/address/0x89a14Be8f7824d4775053Edad0f2fA2d6767b72B) — roles & file access |
| **Ethereum Mainnet** — IPNFT _(unmaintained)_ | [0xcaD8…4Fc1](https://etherscan.io/address/0xcaD88677CA87a7815728C72D74B4ff4982d54Fc1) — the original IP-NFT |

Addresses and status per [Molecule's contract index](https://docs.molecule.xyz/references/contracts), which lists the Base stack as “Molecule Labs core (v0.1.0)” and heads the Ethereum and Sepolia IPNFT blocks “UNMAINTAINED.” The public [IPNFT repository](https://github.com/moleculeprotocol/IPNFT) is not archived, but its last push was in November 2025.

## Coin-to-Company: the token is not equity

The hardest question about any tokenized-research asset is what the token actually entitles you to. Molecule's answer in V3 is unusually direct: [“Tokens are not equity. They do not confer legal ownership, board representation, dividend rights, or the protections that come with being a registered shareholder in a legal entity.”](https://docs.molecule.xyz/technical-deep-dive/rwa-equity) What IPTs give holders is governance voice, token-gated data-room access, and economic exposure.

The **Coin-to-Company (C2C)** module is the opt-in bridge for holders who want the real thing. It is a lock-and-qualify process: swap liquid IPTs one-for-one for non-transferable locked tokens, complete KYC/AML to receive a soulbound credential attesting verification, and only then become eligible to sign ordinary share-purchase or subscription documents with the project's legal entity. The equity grant itself happens off-chain through standard corporate process. Once a holder is designated a shareholder their locked tokens cannot be unlocked; exiting the shareholder position requires an off-chain request and administrative approval.

The design is explicitly regulatory: keeping the token separate from equity is what stops the broader holder base from being pulled into securities treatment, and the lock is what stops someone completing KYC, receiving shares, and immediately selling into the open market. It is the clearest statement in DeSci of a boundary the wider [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) debate usually leaves blurred — and a useful counterpoint for any DAO whose members assume their governance token is a claim on the entity.

## In practice

[VitaDAO](/wiki/desci/ecosystem/vitadao) pioneered the model in production on the original Ethereum contracts: it sold a share of the IPTs behind a longevity research programme (its **VITA-FAST** offering) to fund the work, directly linking community capital to a specific scientific outcome. [AthenaDAO](/wiki/desci/ecosystem/athenadao) and the other biotech DAOs coordinated through [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) followed the same sequence — mint, tokenize, sell IPTs to fund the research, let holders govern commercialization.

That history is why the legacy contracts matter even though they are unmaintained: they still hold live research assets. For a DeSci DAO the tokenized IP _is_ the treasury's core holding, which makes [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) a question of stewarding illiquid, high-variance research bets rather than a stack of liquid tokens. See [DeSci funding](/wiki/desci/desci-funding) for how these raises are structured, and [research data ownership](/wiki/desci/research-data-ownership) for the data-side counterpart.

## On Radix

On Radix, IP-NFTs would be [native NFT resources](https://radix.wiki/contents/tech/core-protocols/nfts-on-radix) rather than ERC-721 contract state — making them more composable, safer against [approval-drain exploits](https://radix.wiki/contents/tech/core-concepts/native-assets-vs-token-approvals), and directly visible in the [Radix Wallet](https://radix.wiki/contents/tech/core-protocols/radix-wallet). Fractionalizing an IP-NFT into IPTs maps cleanly onto minting a fungible resource against a held non-fungible one, executed atomically in a single [transaction manifest](https://radix.wiki/contents/tech/core-protocols/transaction-manifests). The V3 Lab is a closer fit still: Radix components are already accounts that own resources and hold badges, so the ERC-6551 plus ERC-4337 plus ERC-7579 stack Molecule assembles from five standards is closer to the platform's default shape than an addition to it.

## How Caper approaches this

An IP-NFT tokenizes the legal rights to a specific research asset; a [caper](/wiki/foundations/what-is-a-caper) tokenizes the _collective_ that funds and governs that research. A research group can open a caper with a [bonding-curve](/wiki/markets/bonding-curve) treasury, raise from supporters who receive the caper's own fractional tokens, then direct that capital toward acquiring or developing IP through a governance-approved [PAYOUT proposal](/wiki/governance/proposals) — a lab grant, a licensing deal, a milestone payment — decided by a [stake-weighted-by-participation vote](/wiki/governance/voting). Caper does not mint the IP rights on-chain the way an IP-NFT does: the acquired IP is held and licensed off-chain by the collective, while the caper handles the fundraising, treasury, and governance around it — with a [participation-gated pro-rata exit](/wiki/governance/voting) so a contributor who loses conviction can withdraw their treasury share rather than being locked in. See [DeSci funding](/wiki/desci/desci-funding).

## References

- [Molecule — Contracts index (Base Labs core v0.1.0; Ethereum/Sepolia IPNFT blocks marked UNMAINTAINED)](https://docs.molecule.xyz/references/contracts)
- [Molecule — Molecule Labs (the five converging standards, identity vs controller, what Labs own)](https://docs.molecule.xyz/technical-deep-dive/onchain-lab)
- [Molecule — Architecture (OnChainLabFactory, proxy delegation chain, ownership transfer)](https://docs.molecule.xyz/introduction/architecture)
- [Molecule — OclTokenizer contract reference](https://docs.molecule.xyz/references/contracts/tokenizer)
- [Molecule — IPT (IP Token) contract reference: issue, cap, burn](https://docs.molecule.xyz/references/contracts/ipt)
- [Molecule — Coin-to-Company model (lock-and-qualify, KYC credential, off-chain equity)](https://docs.molecule.xyz/technical-deep-dive/rwa-equity)
- [moleculeprotocol/IPNFT — open-source IP-NFT contracts and subgraphs](https://github.com/moleculeprotocol/IPNFT)
- [Etherscan — original IPNFT contract, Ethereum Mainnet](https://etherscan.io/address/0xcaD88677CA87a7815728C72D74B4ff4982d54Fc1)

## Research Data Ownership & Data DAOs

URL: https://caper.network/wiki/desci/research-data-ownership
Updated: 2026-08-08

| Topic | Research data ownership & Data DAOs |
| --- | --- |
| What it is | Models that let the people who generate scientific, genomic, and personal data keep ownership of it and share in the value it creates — instead of surrendering it to a platform, sequencing company, or data broker |
| Core primitives | Data NFTs & datatokens · compute‑to‑data · data unions · encrypted vaults |
| Leading examples | [Ocean Protocol](https://oceanprotocol.com/) · [GenomesDAO](/wiki/desci/ecosystem/genomesdao) · [Streamr data unions](https://blog.streamr.network/what-are-data-unions-how-do-they-work-which-ones-can-i-use/) (Swash) |
| Cautionary tale | The [23andMe Chapter 11 filing](https://www.sec.gov/Archives/edgar/data/1804591/000119312525060817/d933650d8k.htm) (23 March 2025) — a database of ~14.4 million people became an asset of the estate and [sold for $305.0 million](https://www.sec.gov/Archives/edgar/data/1804591/000119312525158551/d11473d8k.htm) |
| Why DeSci cares | Data is the raw material of science; who owns and governs it decides who benefits from it |
| Related | [IP-NFTs](/wiki/desci/ip-nfts) · [DeSci funding](/wiki/desci/desci-funding) · [DeSci DAOs](/wiki/desci/desci-daos) |

## The problem: the people who make the data rarely own it

Scientific progress runs on data — genomes, clinical measurements, sensor streams, browsing and behavioural traces. Yet the people and institutions who _generate_ that data almost never control it or share in the value extracted from it. A research participant hands over a sample and gets a one-time payment, if anything; a patient's records are locked inside a hospital system; a consumer's DNA sits on a company's servers under a terms-of-service agreement they cannot renegotiate. The value accrues to whoever holds the database.

What that concentration means in practice was made vivid in 2025, when 23andMe Holding Co. and certain subsidiaries [filed voluntary Chapter 11 petitions on 23 March 2025](https://www.sec.gov/Archives/edgar/data/1804591/000119312525060817/d933650d8k.htm) and the customer genomic database became an asset of the estate. The company's own [annual report for the year ended 31 March 2025](https://www.sec.gov/Archives/edgar/data/1804591/000162828025030786/mehcq-20250331.htm) sizes it at “approximately 14.4 million and 15.1 million PGS customers” for 2025 and 2024 — a fall it attributes “primarily as a result of customers electing to delete their data” — and reports that 80% of customers had consented to research. It was [auctioned in May 2025 among seven qualified bidders](https://www.sec.gov/Archives/edgar/data/1804591/000095014225001416/eh250629700_8k.htm), and after a reopened round [closed on 14 July 2025 at $305.0 million to TTAM Research Institute](https://www.sec.gov/Archives/edgar/data/1804591/000119312525158551/d11473d8k.htm) — a nonprofit affiliated with the company's co-founder and former CEO — “free and clear of liens, claims, encumbrances, and other interests.” It is the sharpest illustration of the core problem [decentralised science](/wiki/desci/what-is-desci) takes aim at: when data ownership is centralised, the terms can change without the consent of the people the data describes, and the only lever an individual holds is deletion. See [GenomesDAO](/wiki/desci/ecosystem/genomesdao) for a vault design built specifically against this failure mode.

## Data as an ownable, governable asset

The web3 answer is to represent a dataset as something you can hold, permission, and trade without giving up custody of the underlying records. [Ocean Protocol's datatokens](https://docs.oceanprotocol.com/developers/contracts/datatokens) are the clearest example: each published dataset is paired with an ERC‑20 _datatoken_ that acts purely as an access-control key, while a _data NFT_ represents the base ownership right. Holding and spending the datatoken grants access to the data; the data itself never has to go on-chain and can stay on the owner's own storage. Ownership, licensing, and access all become programmable, which is precisely what lets a group of people pool and govern data collectively.

This turns two things that were previously trapped inside a single company into shared, tradeable objects: the **right to the data** and the **revenue from licensing it**. It is the data analogue of the [IP-NFT](/wiki/desci/ip-nfts) pattern DeSci already uses for patents and research IP — ownership of an intangible asset made liquid and collectively holdable.

## Data DAOs and data unions in practice

A **Data DAO** is a collective that owns or manages data assets on behalf of its members, pooling many individually-worthless contributions into a dataset with real market value and governing the terms of access together. Several distinct models exist:

- **[Ocean Protocol](https://oceanprotocol.com/)** — the base layer for tokenised data. Its [compute-to-data](https://docs.oceanprotocol.com/developers/compute-to-data) mechanism lets a buyer run an algorithm _against_ a private dataset and receive only the result, so a DAO can monetise sensitive data for AI training without the raw records ever leaving the owner's server.
- **[GenomesDAO](/wiki/desci/ecosystem/genomesdao)** — genomic-data ownership built on [encrypted-vault infrastructure](https://www.genomes.io) (AMD SEV hardware enclaves). Individuals keep their sequenced DNA in a private vault and are paid each time a researcher queries it, rather than selling it outright to a sequencing company.
- **[Data unions](https://blog.streamr.network/what-are-data-unions-how-do-they-work-which-ones-can-i-use/)** (Streamr) — opt-in pools of real-time personal data where a smart contract splits buyer revenue among all contributors. The browser extension [Swash](https://streamr.network/case-studies/swash/) grew into one of the largest, with over 200,000 users selling their aggregated browsing data collectively rather than surrendering it to ad networks for free.
- **[AxonDAO](/wiki/desci/ecosystem/axondao)** — the consumer-biometric variant: members contribute health metrics, behavioural signals, and voice recordings and are paid in $AXGT for consented access, with the raw records kept off-chain in compliance-ready storage and only the access rights coordinated on-chain.

The common thread is the same one that defines a [DeSci DAO](/wiki/desci/desci-daos): a shared asset (here, the data and the revenue it earns) owned by many, with the rules of access decided by governance rather than by a single custodian.

## The hard problems

Tokenising data does not make the underlying difficulties disappear, and honest coverage names them:

- **Privacy and re-identification.** Genomic and health data can never be truly anonymised — a genome identifies not only you but your relatives. Compute-to-data and hardware enclaves reduce exposure but do not eliminate the risk that a determined buyer re-identifies contributors from query results.
- **Valuation.** A single person's data is nearly worthless; value only emerges at aggregate scale, which makes it genuinely hard to price any one contribution fairly and easy for a marketplace to under-reward the people supplying the raw material.
- **Regulation.** Selling or transferring personal data collides with GDPR, HIPAA, and a growing patchwork of state genetic-privacy laws — some of which, as the 23andMe objections showed, treat consent as non-transferable regardless of what a token says.
- **Governance capture.** If control of a data collective is a freely-bought token, an outside buyer can accumulate it and outvote the very contributors whose data gives the pool its worth — the classic DAO failure, applied to data.

## Where DeSci — and Caper — fit

Data ownership is the third leg of the [DeSci](/wiki/desci/what-is-desci) agenda alongside [funding](/wiki/desci/desci-funding) and [IP](/wiki/desci/ip-nfts): fund the work, own the resulting IP, and let the people who generate the data keep and govern it. The data-custody layer — datatokens, compute-to-data, encrypted vaults — solves how a dataset is held and accessed. It leaves open a second question that is pure governance: once a collective owns a valuable pool of data and the revenue it earns, **who decides the terms, and can a contributor who disagrees leave with their share?**

**How Caper approaches this.** [Caper](/wiki/foundations/what-is-a-caper) is a DAO protocol, not a data-storage layer — it would sit underneath a data collective as the funding-and-governance rail, next to (not instead of) an Ocean- or GenomesDAO-style custody stack. Its relevance is to the last problem above. A caper's decisive governance weight is `(t · v) / (V · T)` — your token share _multiplied by_ your share of an earned, non-transferable [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) vote token minted one-per-ballot and impossible to buy. So an outside buyer cannot simply accumulate the token and seize control of the pool; decisive weight also requires a record of having actually participated. That earned factor maps naturally onto the contribute-to-earn logic data unions already use. And every member holds a clamped [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): a contributor who dislikes where the collective is taking its data can redeem their share of the treasury and leave, rather than being trapped in a pool whose direction they lost a vote on.

Two honest caveats. Caper governs the shared _treasury and decisions_, not the data itself — the privacy and custody guarantees still come from the data layer, not the DAO. And its weight is not purely earned: `t` is a genuine capital term, so a large holder still carries real weight — the earned vote token bounds capture, it does not abolish the influence of size. See also [Rejuve.AI](/wiki/desci/ecosystem/rejuve-ai), an AI-longevity data union that rewards members for contributing health data.

## The Reproducibility Crisis

URL: https://caper.network/wiki/desci/reproducibility-crisis
Updated: 2026-08-03

| Topic | The reproducibility crisis |
| --- | --- |
| What it is | The widespread failure of published scientific findings to replicate when re-tested |
| Landmark evidence | Ioannidis (2005) · Reproducibility Project: Psychology (2015) · Baker's _Nature_ survey (2016) |
| Root causes | Publication bias, p‑hacking, HARKing, publish‑or‑perish incentives, closed data & code |
| Proposed fixes | Preregistration, registered reports, open data/code, open peer review, realigned funding |
| Why DeSci cares | Blockchains can make method, data, and funding decisions transparent and permanent — attacking the incentives that reward irreproducible work |

## Overview

The **reproducibility crisis** (also called the replication crisis) is the finding that a large share of published scientific results cannot be reproduced when independent researchers repeat the experiment. It spans psychology, biomedicine, economics, and beyond, and it is the deepest of the "misaligned incentive" problems that [Decentralized Science](/wiki/desci/what-is-desci) sets out to address. Where [decentralized publishing](/wiki/desci/decentralized-publishing) targets how results are disseminated and [DeSci funding](/wiki/desci/desci-funding) targets how research is paid for, the reproducibility crisis is about a prior question: whether the published record is even _true_.

The crisis is not primarily about fraud. It is a systems problem: the incentives that govern careers, grants, and journals reward novel, positive, statistically-significant results and quietly penalise the replications, null results, and shared data that would keep the record honest.

## How deep the crisis runs

Three landmark pieces of evidence anchor the modern debate:

- **Ioannidis (2005), "Why Most Published Research Findings Are False."** The most-cited paper in [_PLoS Medicine_](https://journals.plos.org/plosmedicine/article?id=10.1371/journal.pmed.0020124) argued from first principles that, given small studies, small effect sizes, flexible analysis, and publication bias, the majority of claimed research findings in many fields are likely false positives.
- **Reproducibility Project: Psychology (2015).** The Open Science Collaboration directly replicated 100 studies from three top psychology journals. 97% of the originals had reported statistically-significant results; on replication only **36%** did, and just **39%** of effects were judged to have replicated — with replication effect sizes roughly **half** the originals ([_Science_](https://www.science.org/doi/10.1126/science.aac4716); project on [OSF](https://osf.io/ezcuj/)).
- **Baker's _Nature_ survey (2016).** A survey of over 1,500 scientists found that **more than 70%** had tried and failed to reproduce another scientist's experiments, and **more than half** had failed to reproduce their _own_ — yet most had never published a failed replication (["1,500 scientists lift the lid on reproducibility"](https://www.nature.com/articles/533452a)).

Parallel large-scale replication efforts in [experimental economics](https://www.science.org/doi/10.1126/science.aaf0918) and cancer biology (the [Reproducibility Project: Cancer Biology](https://www.cos.io/rpcb)) reached similar conclusions: a meaningful fraction of headline findings simply do not hold up.

## Why it happens: the incentive structure

The crisis is best understood as the predictable output of the incentives researchers actually face, not as individual carelessness:

- **Publish or perish.** Hiring, tenure, and grants reward publication volume and novelty. Replications and null results rarely advance a career, so they rarely get done or published.
- **Publication bias (the file-drawer problem).** Journals preferentially publish positive, significant findings. The negative results that would balance the record stay in the drawer, inflating the apparent strength of every published effect.
- **p‑hacking & researcher degrees of freedom.** Flexible choices in data collection and analysis — which outliers to drop, which covariates to include, when to stop collecting — let researchers reach the p < 0.05 threshold from noise, often without conscious intent ([Simmons, Nelson & Simonsohn, "False-Positive Psychology"](https://journals.sagepub.com/doi/10.1177/0956797611417632)).
- **HARKing.** "Hypothesising After the Results are Known" — presenting a post-hoc explanation of a chance finding as if it had been predicted in advance — turns exploratory noise into a confirmatory-looking story.
- **Closed data and code.** When the underlying data and analysis code are not shared, results cannot be checked, re-run, or built on, and errors go undetected.

## What fixes it: open, credible science

The reform agenda is largely about changing incentives and making the process transparent by default:

- **Preregistration.** Recording hypotheses and the full analysis plan _before_ seeing the data removes the flexibility that p‑hacking and HARKing exploit ([Center for Open Science](https://www.cos.io/initiatives/prereg); [Nosek et al., "The preregistration revolution"](https://www.pnas.org/doi/10.1073/pnas.1708274114)).
- **Registered Reports.** Journals peer-review and accept a study on the strength of its _question and method_ before results exist, so publication no longer depends on the outcome ([COS Registered Reports](https://www.cos.io/initiatives/registered-reports)).
- **Open data & code.** Sharing the dataset and analysis pipeline lets anyone re-run and verify a result — the foundation of the FAIR data principles.
- **Open, credited peer review.** Transparent, attributed, and increasingly _paid_ review realigns the one step meant to catch problems — see [decentralized publishing & peer review](/wiki/desci/decentralized-publishing).
- **Funding negative and confirmatory work.** Deliberately paying for replications and null results — a natural fit for the retroactive and community-directed models covered in [DeSci funding](/wiki/desci/desci-funding).

## Where DeSci — and Caper — fit

Most of the reproducibility crisis is a problem of scientific method and culture, and no blockchain "solves" it. What decentralised infrastructure can change is the layer underneath the incentives: **making the record permanent and the decisions transparent.** On-chain timestamps let a hypothesis or preregistration be provably fixed before data collection; content-addressed storage makes data and code tamper-evident; and token incentives can be pointed at the work — replications, null results, shared datasets — that the traditional system underfunds. That is the connective tissue between this crisis and the rest of the [DeSci](/wiki/desci/what-is-desci) agenda.

**How Caper approaches this.** [Caper](/wiki/foundations/what-is-a-caper) is a DAO protocol, not a lab or a journal — it does not run experiments or host papers. Its contribution is the funding-and-governance rail a research community would sit on. Every proposal, vote, and payout is an on-chain action with typed outcomes (a passing PAYOUT or INVEST vote _is_ the transfer), so who funded which work is a permanent public record rather than an off-chain minute. And a caper's decisive governance weight multiplies a member's token holdings by an earned, non-transferable [soulbound](/wiki/dao-governance/concepts/membership/soulbound-tokens) record of participation — so a large position on its own carries no weight, and influence over which research a treasury backs cannot be captured on capital alone. It is a modest, honest fit: Caper supplies transparent, incentive-aligned rails; it does not adjudicate whether a given result replicates.

## What is Decentralized Science (DeSci)

URL: https://caper.network/wiki/desci/what-is-desci
Updated: 2026-07-29

|  |  |
| --- | --- |
| **Topic** | Decentralized Science (DeSci) |
| **What it is** | Funding, publishing & governing research on public blockchains via DAOs and token incentives |
| **Core primitives** | [IP-NFTs](/wiki/desci/ip-nfts), [DeSci DAOs](/wiki/desci/desci-daos), [novel funding](/wiki/desci/desci-funding), [open publishing & review](/wiki/desci/decentralized-publishing) |
| **Reference** | [ethereum.org/desci](https://ethereum.org/en/desci/) |

## Overview

**Decentralized Science (DeSci)** is a movement to reform how science is funded, published, and governed using public blockchains, [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), and token incentives. As the [Ethereum Foundation's DeSci hub](https://ethereum.org/en/desci/) frames it, the goal is to build public infrastructure for “funding, creating, reviewing, crediting, storing, and disseminating scientific knowledge” — addressing systemic failures of the traditional research system.

### The problems DeSci targets

- **Funding bottleneck** — grant capital is scarce, slow, and gate-kept; low single-digit acceptance rates push researchers to optimize for grant committees rather than discovery.
- **Closed-access publishing** — publicly-funded results sit behind paywalls, and peer review is opaque and unpaid.
- **IP lock-up** — promising early research stalls in university tech-transfer offices, unable to attract capital or reach the public.
- **Misaligned incentives** — the [reproducibility crisis](/wiki/desci/reproducibility-crisis) and negative results are undervalued because they don't advance careers.

### Core primitives

- **[IP-NFTs & IP Tokens](/wiki/desci/ip-nfts)** — tokenize the legal rights to research so a community can own and fund it.
- **[DeSci DAOs](/wiki/desci/desci-daos)** — token holders collectively decide which research to fund and how to commercialize the results.
- **[Novel funding](/wiki/desci/desci-funding)** — [quadratic funding](https://wtfisqf.com/), retroactive public-goods funding, and token-curated grants replace the single grant committee.
- **[Decentralized publishing & peer review](/wiki/desci/decentralized-publishing)** — open-access research objects and on-chain attestations that give reviewers reputation and, increasingly, payment.
- **[Research data ownership](/wiki/desci/research-data-ownership)** — data NFTs, data unions, and Data DAOs that let the people who generate genomic and clinical data keep ownership of it and a share of the value.

### Why now: the 2025–26 public-funding shock

DeSci's funding-bottleneck thesis stopped being abstract in 2025. Over the year the U.S. government [terminated or froze more than 3,800 NIH and NSF research grants — roughly $3 billion in unspent, already-committed funds](https://www.sciencenews.org/article/nih-nsf-cuts-2025-data), the NIH alone accounting for nearly 2,500 grants (about $2.3 billion). One analysis found the terminations disrupted [roughly 1 in 30 active clinical trials, affecting more than 74,000 enrolled participants](https://www.ajmc.com/view/nih-grant-terminations-disrupt-1-in-30-clinical-trials-impacting-over-74-000-participants). When the dominant grant pipeline contracts this sharply, community- and token-based funding stops being a novelty and becomes a lifeline — the clearest demand-side tailwind DeSci has had.

### The 2026 landscape

DeSci has consolidated around a few coordination layers. [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) — which describes itself as “DeSci's new financial layer” — now coordinates [10+ biotech DAOs](https://www.bio.xyz/) across longevity, women's health, psychedelics and synthetic biology, having raised over $33M in its [BIO Genesis](https://www.bio.xyz/) round (Binance Labs' first DeSci investment, Nov 2024). At [DeSci.Berlin in June 2026](https://cryptobriefing.com/bioprotocol-openlabs-desci-berlin/) it launched **OpenLabs** — backed by a fresh [$6.9 million round](https://manufacturingchemist.com/bio-protocol-launch-ai-powered-decentralised-ai-platform) — pairing AI-assisted project development with community funding votes in a single interface — the same launcher that issues Bio's [BioAgents](/wiki/desci/ecosystem/peptai) — a sign that DeSci's frontier is moving from tokenizing IP toward operating the full research workflow on-chain.

### Relevance to Radix

Radix's [asset-oriented programming](https://radix.wiki/contents/tech/core-concepts/asset-oriented-programming) is well-suited to DeSci: [IP-NFTs](/wiki/desci/ip-nfts) are native resources (not contract state), DAOs benefit from [engine-level access rules](https://radix.wiki/contents/tech/core-concepts/access-rules-and-auth-zones), and complex funding flows compose atomically via [transaction manifests](https://radix.wiki/contents/tech/core-protocols/transaction-manifests). See [DeSci on Radix](/wiki/desci/desci-and-radix).

### How Caper approaches this

A research collective doesn't need a bespoke platform to run the DeSci playbook. A [caper](/wiki/foundations/what-is-a-caper) gives any group a [bonding-curve](/wiki/markets/bonding-curve) treasury to raise from supporters and a proposal system to direct that treasury toward a lab, a milestone, or an IP acquisition — with a [participation-gated pro-rata exit](/wiki/governance/voting) so contributors who lose conviction can withdraw their share rather than being locked in. It's the same “community funds the science, community governs the outcome” loop that DeSci pioneered, without a research group having to deploy its own contracts. See [DeSci funding](/wiki/desci/desci-funding).

## AthenaBIO (formerly AthenaDAO)

URL: https://caper.network/wiki/desci/ecosystem/athenadao
Updated: 2026-08-01
Verified: 2026-08-01

|  |  |
| --- | --- |
| **Type** | DeSci organization — women's health R&D |
| **Founded** | 2022, as AthenaDAO |
| **Renamed** | AthenaBIO, announced 8 March 2026 |
| **Founder** | Laura Minquini |
| **Focus** | Women's health research funding & IP |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO |
| **Token** | ATH (still live post-rename) |
| **Capital vehicle** | Holding company + SPVs, ~$5M target, ~15 assets |
| **Deployed to date** | ~$1.5M across five review cohorts |
| **Chain** | Ethereum |
| **Status** | Active — newsletter publishing through July 2026 |
| **Website** | [athenadao.co](https://www.athenadao.co) |

## Overview

**AthenaBIO**, founded in 2022 as **AthenaDAO**, is a [decentralized science (DeSci)](/wiki/desci/what-is-desci) organization that sources, funds and incubates women's health R&D, connecting researchers with legal, strategic, scientific and market support. It began as a [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO, using community-held tokens to govern which projects get funded and how the resulting intellectual property is stewarded, and it still describes its funding rails in those terms — [“on-chain transparent blockchain technology and incentives to fund early-stage research and biotech startups via a token held by the community”](https://www.athenadao.co), with capital allocation done collaboratively.

Women's health is chronically under-funded relative to its disease burden, and the organization frames the gap as [a market opportunity rather than a charity case](https://beautymatter.com/articles/how-athena-bio-is-rewriting-rd-funding-for-womens-health) — pooling community capital to de-risk early translational science that traditional grant pipelines and venture funds routinely skip. Its named research bets concentrate on ovarian aging: novel therapeutic targets with the AI drug-discovery firm Gero, the integrated stress response (ISR) pathway for ovarian follicle survival, and the cGAS–STING inflammatory pathway in reproductive aging.

## From AthenaDAO to AthenaBIO

On **8 March 2026** the organization published [“AthenaBIO: The first Science-First Ecosystem for Women's Health R&D”](https://athenadao.substack.com/p/athenabio-the-first-science-first), which introduces the entity as _“AthenaBIO (formerly known as AthenaDAO)”_. The rename has since propagated through the public site: [athenadao.co](https://www.athenadao.co) now reads “AthenaBIO” in its body copy and footer while keeping the original domain, and the organization describes itself as **“a think tank and global community of researchers, funders, and advocates”** rather than as a DAO. The ATH token and the community-allocation framing remain on the site.

The rename formalises a shift that began in September 2025, when AthenaDAO [launched AthenaBIO](https://athenadao.substack.com/p/athenabio) as an equity vehicle to carry vetted assets through the capital-intensive phases — validation, regulation, scale — that a community treasury alone cannot underwrite. It is structured as [a holding company with SPVs rather than a traditional closed-end fund](https://beautymatter.com/articles/how-athena-bio-is-rewriting-rd-funding-for-womens-health), aiming to raise about **$5 million** against roughly **15 early-stage assets** across AI-driven diagnostics, ovarian health and reproductive technology, all previously cleared by the organization's scientific review.

The founders were candid about the motive: as one put it, “your token is never going to reflect the value of what you are building” — a recurring tension in [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics), where a freely-traded governance token's price drifts away from the value of the underlying work. The answer here was to split the two rather than pick one: keep the community layer for sourcing, education and IP governance, and route institutional capital through a separate equity structure. It is worth reading alongside [VitaDAO](/wiki/desci/ecosystem/vitadao), which met the same discovery-to-commercialization gap by pairing IP-NFTs with a pharma spinout instead of a holding company.

## Funding model & track record

Through five review cohorts the organization's community has [deployed roughly $1.5 million into science](https://www.futurefemhealth.com/p/exclusive-new-5m-athenabio-vehicle). Its own March 2026 count of what that bought is **six labs, 20 academic fellowships, three pre-prints, three start-ups, one summit and more than 100 live events**, from a Science & Deal Flow team that reports having [evaluated over 430 scientific proposals across five focused cohorts](https://athenadao.substack.com/p/athenabio-the-first-science-first). These are self-reported figures and the counts differ slightly between the organization's own posts and press coverage; treat them as an order of magnitude rather than an audited ledger.

Every asset passes the scientific-review process before capital is committed, and funded IP is held and licensed through the [IP-NFT](/wiki/desci/ip-nfts) tooling built by [Molecule](/wiki/desci/ecosystem/molecule) — the same rails used by [HairDAO](/wiki/desci/ecosystem/hairdao) and the rest of the Bio Protocol cohort. The community layer also publishes standalone research: a data-and-wearables report on the ownership and governance of women's health data sits alongside the funded science, and the newsletter has continued to publish through **July 2026**, which is the clearest available signal that the organization is operating rather than winding down.

## How Caper approaches this

The token-versus-equity split AthenaBIO reached for is exactly the seam a [caper](/wiki/foundations/what-is-a-caper) is designed to close. On Caper, contributed capital flows into the caper's own [bonding-curve](/wiki/markets/bonding-curve) treasury rather than into a free-floating token whose price detaches from the work — value accrues to the treasury itself, and members hold a [participation-weighted exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on it. Research spending is then authorised the same way governance authorises any spend: a [PAYOUT proposal](/wiki/governance/proposals) that transfers a chosen currency and amount from the treasury to a lab or researcher once members [vote it through](/wiki/governance/voting). There is no separate equity vehicle to spin up, and voting weight is stake weighted by participation, so the people funding the science keep governance coupled to their exposure.

## External links

- [AthenaBIO — official website](https://www.athenadao.co)
- [“AthenaBIO: The first Science-First Ecosystem” — rename announcement, 8 March 2026](https://athenadao.substack.com/p/athenabio-the-first-science-first)
- [AthenaBIO launch — AthenaDAO Substack, September 2025](https://athenadao.substack.com/p/athenabio)
- [BeautyMatter — how AthenaBIO is rewriting R&D funding for women's health (January 2026)](https://beautymatter.com/articles/how-athena-bio-is-rewriting-rd-funding-for-womens-health)
- [Bio Protocol ecosystem](https://www.bio.xyz)

## AxonDAO

URL: https://caper.network/wiki/desci/ecosystem/axondao
Updated: 2026-08-12
Verified: 2026-08-10

| Name | AxonDAO |
| --- | --- |
| Type | Decentralized-science (DeSci) health-data network and GPU compute provider |
| Focus | User-owned biometric & health data, voice biomarkers, rented GPU capacity for AI and life-sciences research |
| Token | $AXGT (governance & utility — explicitly no equity, ownership, or revenue rights) |
| Ethereum contract | `0x6112C3509A8a787df576028450FebB3786A2274d` ([Etherscan](https://etherscan.io/token/0x6112C3509A8a787df576028450FebB3786A2274d)) |
| Chains | Ethereum, Base, Arbitrum |
| Founder & CEO | Christopher (Chris) Crecelius |
| Products | AxonGPU (enterprise rental) · AxonOS (browser GPU desktop) · CureRING (wearable) · A+Voice |
| Notable | Oracle Cloud GPU deal (Feb 2026); NVIDIA Blackwell cluster with ICC (Mar 2026); NVIDIA Inception member; public GPU-revenue dashboard |
| Status | 🟢 Active |
| Website | [axondao.io](https://axondao.io) · [whitepaper](https://whitepaper.axondao.io) |

## Overview

AxonDAO is a decentralized-science network that lets individuals collect, govern, and monetize their own biometric and health data instead of surrendering it to platforms for free. Its [whitepaper](https://whitepaper.axondao.io) describes the protocol as a "DeSci coordination layer designed to enable ethical, consent-based collection, governance, and utilization of biometric and health data through blockchain coordination and GPU-accelerated artificial intelligence." Members contribute data – health metrics, behavioural signals, and voice recordings – and earn the $AXGT token for consented participation, while researchers pay for access to large, ethically-sourced datasets.

Since early 2026 the organization has grown a second, unusually concrete leg: it _sells compute_. AxonDAO now operates NVIDIA GPU clusters and rents them to AI and life-sciences customers under the **AxonGPU** brand, publishing the proceeds and the resulting $AXGT buybacks on a public dashboard. That makes it one of the relatively few [DeSci DAOs](/wiki/desci/desci-daos) whose treasury has a revenue line attached to a physical asset rather than a token sale – a point of interest well beyond DeSci, and one covered in general terms on [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual).

It sits in the same [decentralized-science](/wiki/desci/what-is-desci) wave as [VitaDAO](/wiki/desci/ecosystem/vitadao) and the other [BioDAOs](/wiki/desci/ecosystem/molecule), but occupies a distinct niche: where those organizations tokenize _intellectual property_ from lab research, AxonDAO tokenizes _access to personal data_ generated by ordinary people – a consumer-facing [data DAO](/wiki/desci/research-data-ownership) rather than an IP-NFT fund.

## The health-data ownership problem

Most health and biometric data today is captured by device makers, apps, and clinical systems and monetized without the person it describes seeing any of the value. AxonDAO's thesis is that this asset should belong to – and be paid for by consent of – the individual who generates it. Its [whitepaper](https://whitepaper.axondao.io) is emphatic that the data itself is never fractionally sold or put on-chain: "AxonDAO does not store personal health data on public blockchains. All sensitive data is stored off-chain in compliance-ready environments, with access governed by explicit user consent." What the blockchain coordinates is _consent, valuation, and access rights_, not the raw records – an important distinction from data-marketplace designs that tokenize the data itself.

## The $AXGT token and governance

$AXGT is the network's governance and utility token, deployed on Ethereum at [`0x6112C3509A8a787df576028450FebB3786A2274d`](https://etherscan.io/token/0x6112C3509A8a787df576028450FebB3786A2274d) and bridged to Base and Arbitrum following a 1:1 migration from its original contract. Per the [whitepaper](https://whitepaper.axondao.io), it "enables participation in data contribution, access coordination, protocol governance, and research funding," and it "does not represent equity, ownership, profit participation, or claims on assets or revenues" – a governance-and-access token, not a security. Holders vote on protocol decisions and on which research programs get funded, stake to participate, receive $AXGT for contributing consented data, and unlock published tier discounts on GPU rental by holding a balance.

Supply figures for $AXGT are quoted inconsistently across market-data sites, so the checkable number is the contract's own: a `totalSupply()` call against the Ethereum contract returned **719,799,874 AXGT** (18 decimals) on 10 August 2026. That is the Ethereum leg only; the canonical burn address `0x…dEaD` held 4 AXGT on the same date, so any retirement of supply to date has run through the contract rather than through a dead-address transfer.

## CureRING, A+Voice, and the data programmes

AxonDAO's first flagship data programme was **A+Voice**, launched in June 2024, a platform for collecting voice recordings to build datasets for _voice-biomarker_ research – using vocal features to help detect and monitor conditions such as neurological and respiratory disease ([announcement](https://news.bitcoin.com/axondao-unveils-avoice-pioneering-biometric-ai-voice-collection/)). Contributors are rewarded in $AXGT for consented submissions, turning routine data collection into a paid, opt-in act.

In June 2025 it shipped hardware. **CureRING** is a smart ring that tracks heart rate, body temperature, blood-oxygen, sleep, stress, and activity, encrypting the readings into a user-controlled vault; its [launch release of 6 June 2025](https://www.manilatimes.net/2025/06/06/tmt-newswire/globenewswire/axondao-launches-curering-the-health-wearable-that-pays-users-for-their-data/2128796) priced it at $243 (payable in USD or $AXGT) in sizes 9–13, said pre-orders were shipping, and committed to returning _50% of the purchase price in $AXGT after four months of consistent daily use_, with further rewards for consenting to share anonymized data with approved researchers. The design inverts the usual wearable bargain: the buyer is paid back for wearing the device rather than paying with data they never see revenue from.

Those are 2025 terms, and AxonDAO's own surfaces no longer restate them. Its [CureRING ecosystem page](https://www.axondao.io/ecosystem/curering) carries a single status badge — **"Planned"** — quotes no price, and says in terms that "the role is not to present a consumer wearable as the whole company"; the ordering destination named in the launch release, [curering.ai](https://curering.ai), is now a "join the waitlist" landing page with no price and no checkout. The ring is best read as announced, briefly sold, and currently re-scoped as the ecosystem's consent layer rather than a shipping product — consistent with the organization's broader move toward compute described below.

## AxonGPU: the compute business

Turning consented data into research requires serious compute, and AxonDAO chose to own that layer rather than rent it. In February 2026 it selected [Oracle Cloud Infrastructure](https://markets.businessinsider.com/news/stocks/axondao-selects-oracle-cloud-infrastructure-to-build-and-scale-secure-gpu-infrastructure-for-ai-and-life-sciences-workloads-1035802508) to build and scale a secure GPU platform for regulated healthcare and life-sciences AI workloads, with US-based data sovereignty and mandatory encryption – a move [DAO Times](https://daotimes.com/axondao-transitions-to-enterprise-grade-infrastructure-through-oracle-cloud-partnership/) characterised as a transition to enterprise-grade infrastructure.

In March 2026 it went further and deployed its own hardware. The "Science Discovery" platform, built with [International Computer Concepts (ICC)](https://www.icc-usa.com/blog/axondao-ICC-science-discovery-gpu-infrastructure) on Supermicro systems, pairs an [NVIDIA Blackwell B200 cluster](https://markets.businessinsider.com/news/stocks/axondao-launches-science-discovery-gpu-infrastructure-built-with-icc-1035895572) (roughly 1.4 TB of aggregate VRAM across eight GPUs per node) with an NVIDIA RTX PRO 6000 cluster (~768 GB across eight GPUs), dual Intel Xeon 6952P processors, multi-terabyte DDR5 ECC memory, NVMe storage, and a 400 Gb/s network fabric. Founder Christopher Crecelius framed the deployment as providing "the performance density, memory capacity, and network throughput required to support advanced AI training while enabling a structured tokenized model for data contribution and compute access."

Two rental paths sit on top. **Enterprise rental** reserves managed capacity for large workloads. **AxonOS** – announced in private beta and initially running on V100 GPUs – is self-serve: a full Linux desktop in the browser with direct GPU passthrough rather than a hypervisor or thin client, preloaded with JupyterLab, RStudio, and bioinformatics tooling, paid for in ETH at hourly rates with published tier discounts for $AXGT holders ([AxonOS](https://axondao.io/axonos)). The network is also an NVIDIA Inception member and has integrated [SKALE](https://stocktwits.com/news-articles/markets/cryptocurrency/axondao-agxt-uses-skale-skl/chlnAQLRRRm) to make consent toggles, data queries, and reward payouts gas-free for end users.

## Revenue, buybacks, and the public dashboard

The compute business gives AxonDAO something most DAOs lack: an external customer paying for a service, rather than a treasury drawn down from a token sale. It publishes a [revenue dashboard](https://axondao.io/dashboard) that it describes as covering "fleet earnings, AXGT buybacks, and on-chain transparency," including validated GPU-revenue definitions, buyback records, burn-address records, and notes on how each metric is measured. At the time of writing (10 August 2026) the dashboard renders its figures client-side from fleet telemetry and was reporting a sync rather than a settled number, so the mechanism is public but the audited totals are not yet independently citable from the page itself.

The structure is worth noting regardless of the numbers, because it is the shape [DAO treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) are increasingly reaching for: a revenue-producing asset owned by the organization, with a stated policy routing part of the proceeds back into the token. Whether that policy is durable – and whether the buyback is disclosed precisely enough to verify – is the standard question to put to any [value-accrual](/wiki/economics/fee-switches-and-value-accrual) claim, and this one is young enough that the honest answer is "not yet demonstrated over a full cycle."

## Ecosystem projects

Around the core network AxonDAO lists five applications, each a different consented-data vertical feeding the same research stack ([ecosystem](https://axondao.io/ecosystem)): **AxonVoice**, research-stage speech analysis for psychedelic health studies; **Psyonic**, voice AI exploring mood and cognition signals in microdosing research; **PHEAL**, which matches music to a listener's biometrics and routes fan support to artists directly; **Peake Health**, wearable fitness tracking with user-controlled sharing (listed as coming soon); and **CANABIT**, cannabis education built on user-contributed data and reviewed science. The pattern across all five is the same primitive – an opt-in data contribution that pays the contributor – applied to a different population.

The organization's press releases carry Wyoming datelines (Sheridan and Cheyenne), placing it among the DeSci projects that pair on-chain governance with a US legal wrapper; the trade-offs of that arrangement are covered on [DAO legal structures](/wiki/dao-governance/concepts/membership/dao-legal-structures).

## Place in the DeSci landscape

AxonDAO represents the _personal-data_ archetype of decentralized science: rather than funding a lab and tokenizing the resulting [IP-NFT](/wiki/desci/ip-nfts), it aggregates a network of individuals who each own and license a slice of the raw material – their health data. That makes it a close cousin of the [Data DAO](/wiki/desci/research-data-ownership) model (Ocean-style datatokens, 23andMe's contested genomic archive) applied to consumer biometrics, and a contrast to the IP-first [VitaDAO](/wiki/desci/ecosystem/vitadao)/[CryoDAO](/wiki/desci/ecosystem/cryodao) lineage.

Its compute pivot adds a second contrast. Most DeSci organizations are _buyers_ of research capacity, funding grants out of a treasury; AxonDAO has made itself a _seller_ of it, which changes the failure mode. Its main challenges are no longer only the data-network ones – reaching the scale of contributors that makes datasets valuable, and keeping consent and compliance airtight – but the capital-intensive ones that come with owning hardware: utilisation, depreciation, and competing on price with hyperscalers. Its premise, that people should be paid for the data they already generate, remains one of DeSci's clearest consumer stories.

## How Caper approaches this

AxonDAO's core argument is that individuals – not platforms – should capture the value of what they generate, and that a token can coordinate a community around that shared asset. [Caper](/wiki/foundations/what-is-a-caper) makes the same bet the unit of design: a [personal token](/wiki/economics/personal-tokens) lets any individual or collective launch a community-owned treasury and governance around their own work, [raising funds](/wiki/markets/raising-funds) on a bonding curve rather than selling equity.

Where AxonDAO rewards data contributors in $AXGT, a caper turns that reward into durable governance: a member's influence is their _canonical vote weight_, a function of both the tokens they hold and the votes they have earned by showing up – so the people who supply the value accumulate real say over how the treasury spends it. And where AxonDAO's dashboard is a disclosure that the treasury _says_ it will recycle revenue, a caper's equivalents are [typed proposals](/wiki/governance/proposals) the contract executes: pay a contributor directly, invest the treasury into an aligned caper, or sell a holding back out of it. The policy is the code path, not the promise.

## Bio Protocol

URL: https://caper.network/wiki/desci/ecosystem/bio-xyz
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Type** | BioDAO launchpad & funding layer |
| **Founded** | 2022 |
| **Focus** | Biotech DAO incubation & funding |
| **BioDAOs launched** | 11+ |
| **Token** | BIO — capped 3.32B supply |
| **Genesis raise** | $33M+ (Nov 2024, Binance Labs' first DeSci investment) |
| **Chains** | Ethereum, Solana, Base |
| **Website** | [bio.xyz](https://www.bio.xyz) |

## Overview

Bio Protocol (formerly Bio.xyz) is a [decentralized funding, governance and liquidity engine for early-stage science](https://docs.bio.xyz/bio/introduction/concepts/decentralized-science) — a protocol for directing capital and talent to biotech DAOs ("BioDAOs") and tokenized scientific IP. It incubates and funds specialized BioDAOs, each focused on a specific disease area or scientific domain.

The platform raised over $33 million through Bio Genesis in November 2024, with Binance Labs making its first DeSci investment. In June 2026 it introduced [OpenLabs](https://crypto.news/bio-protocol-launches-ai-research-hub-to-challenge-grant-gatekeepers/), an AI research hub unveiled at DeSci.Berlin 2026 that folds idea development, contributor coordination and funding into a single interface. Bio Protocol runs the tokenization layer built on [Molecule](/wiki/desci/ecosystem/molecule).

## BIO token, curation and staking

[BIO](https://www.bio.xyz/bio-token) is the protocol's governance token, with a capped maximum supply of 3.32 billion. Its allocation is weighted toward the ecosystem it funds: roughly 34.9% to ecosystem incentives, 25% core contributors, 13.6% investors, 10.5% protocol treasury, 8% community auctions and 8% BioDAO incentives.

The token's central job is **curation**. Holders [stake BIO on the BioDAOs they want admitted to the network](https://www.gate.com/learn/articles/decoding-bio-protocol-building-a-meaningful-research-funding-incubator/4760), combining community signaling with expert review to filter which projects get funded. Staking earns loyalty points ("BioXP") that grant priority access to **Ignition Sales** — the low-cap fundraises that launch a new BioDAO. Bio Protocol's V2 rollout streamlined this into a launchpad that lets a BioDAO form and raise in days rather than months.

This is a textbook [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) design: the token is a curation and access right, and staking aligns holders with the quality of the pipeline rather than with short-term price. It is also a two-layer governance structure — BIO curates _which_ DAOs exist, while each BioDAO governs its own research and IP.

## BioDAO ecosystem

Bio Protocol has launched 11+ specialized BioDAOs:

- **[VitaDAO](/wiki/desci/ecosystem/vitadao)** — longevity research (initiated July 2021)
- **[AthenaBIO](/wiki/desci/ecosystem/athenadao)** — women's health
- **[PsyDAO](/wiki/desci/ecosystem/psydao)** — psychedelic science
- **[ValleyDAO](/wiki/desci/ecosystem/valleydao)** — synthetic biology
- **[HairDAO](/wiki/desci/ecosystem/hairdao)** — hair-loss research (patents its DAO-funded findings)
- **[CryoDAO](/wiki/desci/ecosystem/cryodao)** — cryopreservation
- **[Cerebrum DAO](/wiki/desci/ecosystem/cerebrum-dao)** — brain health
- **[Curetopia](/wiki/desci/ecosystem/curetopia)** — rare diseases
- **[Long COVID Labs](/wiki/desci/ecosystem/long-covid-labs)** — Long COVID research
- **[Quantum Biology DAO](/wiki/desci/ecosystem/quantum-biology-dao)** — quantum biology
- **[DermaLabs](/wiki/desci/ecosystem/dermalabs)** — skincare science

### BioAgents

From 2026 the same Launcher also issues **BioAgents** — autonomous research agents that hold a token and a treasury without a voting membership. Aubrai came first; [PeptAI](/wiki/desci/ecosystem/peptai) is the one that has published wet-lab confirmation of an agent-designed candidate, and its [May 2026 Ignition Sale](https://www.bio.xyz/blog-posts/bio-monthly-may-2026-peptai-ignition-sale-bio-on-robinhood-vebio-staker-rewards) is the reference example of the mechanism described above.

## How Caper approaches this

Bio Protocol is a launchpad: a shared curation-and-funding layer that stands up many BioDAOs, each of which then needs its own token, treasury and governance. A [caper](/wiki/foundations/what-is-a-caper) is the opposite shape — a single self-contained primitive where the fundraise (a [bonding curve](/wiki/markets/bonding-curve)), the treasury, the proposal system (PAYOUT / INVEST / DIVEST / VOTE) and a participation-weighted exit ship together. The two are complementary: an ecosystem curator answers "which projects deserve capital"; a caper answers "how does one funded community raise, spend and let members leave without stitching four tools together."

## External Links

- [Bio Protocol — Official Website](https://www.bio.xyz)
- [BIO Token — Overview & allocation](https://www.bio.xyz/bio-token)
- [Bio Protocol Documentation](https://docs.bio.xyz/)

## Cerebrum DAO

URL: https://caper.network/wiki/desci/ecosystem/cerebrum-dao
Updated: 2026-08-03

| Type | BioDAO — neuroscience / brain-health research funding |
| --- | --- |
| Focus | Extending healthy brain lifespan; first target Alzheimer's disease and neurodegeneration |
| Founder | Brian Magierski (also founder of 21 Impact Labs, CEO of Xponetiq) |
| Token | NEURON (ERC-20, Ethereum) — governance + IP-NFT access |
| Launched | NEURON Dutch auction on the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) launchpad, deadline 30 April 2024 |
| Portfolio | ~$1.3M committed across 7 projects (IP-NFT, IP-license and equity deals) |
| IP framework | [Molecule](/wiki/desci/ecosystem/molecule) IPNFT protocol |
| Website | [cerebrumdao.com](https://www.cerebrumdao.com/) |

**Cerebrum DAO** is a [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO that, in its own words, is "a community-powered network organization to source, fund, and translate research that accelerates solutions to extend healthy brain lifespan" ([cerebrumdao.com/about](https://www.cerebrumdao.com/about)). Its first focus area is **Alzheimer's disease** — a condition it notes affects some 6.7 million Americans, with cases projected to rise sharply by 2050 ([Bio Protocol](https://www.bio.xyz/blog-posts/bringing-neuroscience-onchain-with-cerebrum-dao)). Founder **Brian Magierski** has said the effort was motivated by his daughter's Down syndrome diagnosis, which carries a near-certain lifetime risk of Alzheimer's dementia.

Cerebrum follows the [VitaDAO](/wiki/desci/ecosystem/vitadao) model pioneered across the Bio Protocol pipeline: a freely-tradeable governance token funds early-stage translational research, and the resulting intellectual property is tokenized on-chain as an [IP-NFT](/wiki/desci/ip-nfts) owned by the community rather than a single lab or fund.

## What Cerebrum DAO funds

Cerebrum treats neurodegeneration as tightly coupled to biological aging, and concentrates on the upstream drivers of brain decline: **neuro-inflammation, metabolic stress, mitochondrial dysfunction, and vascular changes** — with particular attention to blood-brain-barrier dysfunction ([cerebrumdao.com](https://www.cerebrumdao.com/)). Researchers apply for funding directly, with a stated 6–8 week response window depending on the pipeline ([cerebrumdao.com/researchers](https://www.cerebrumdao.com/researchers)).

When the DAO backs a project, the IP is tokenized "using the IPNFT protocol, ensuring equitable distribution of license and governance rights," and licensing proceeds are split between the researchers and the DAO ([cerebrumdao.com/about](https://www.cerebrumdao.com/about)). This is the same [Molecule](/wiki/desci/ecosystem/molecule)-built mechanism used by [HairDAO](/wiki/desci/ecosystem/hairdao) and [VitaDAO](/wiki/desci/ecosystem/vitadao) — funding research _before_ a company exists and giving the community an on-chain claim on its upside.

## The IP-NFT portfolio

As of mid-2026 Cerebrum reports roughly **$1.3 million committed across seven projects** ([cerebrumdao.com/projects](https://www.cerebrumdao.com/projects)):

| Project | What it is | Instrument | Allocated |
| --- | --- | --- | --- |
| **[Fission Bio](https://www.cerebrumdao.com/projects/fission-bio)** | Protein–protein interaction inhibitor severing the link between chronic inflammation and mitochondrial dysfunction | IP-Token | $400,000 |
| **[Percepta®](https://www.cerebrumdao.com/projects/percepta-brain)** | Patent-protected brain-health supplement (PTI-00703® cat's claw + MemorTea® oolong extract); tokenized as [IP-NFT #129](https://etherscan.io/nft/0xcaD88677CA87a7815728C72D74B4ff4982d54Fc1/129) | IP Portfolio License | $400,000 |
| **[Project Transfidelity](https://www.cerebrumdao.com/projects/project-transfidelity)** | Enhancing protein-translation fidelity to combat neurodegeneration (Dr Dimitri Scherbakov, University of Zurich) | IP-Token | $254,000 |
| **Arctic Therapeutics (AT-001)** | Oral NAC-amide (NACA) disrupting amyloid plaques; Phase IIa data in HCCAA patients (Dr Hakon Hakonarson) | Equity | €75,000 |
| **SK-Channels** | Small-molecule modulator for tremors and ataxia | IP License | $60,000 |
| **Neuron-Gale** | Galectin-3 inhibitors for neuro-inflammation (Dr Maryna Polyakova) | — | $50,000 |
| **Xponetiq** | Mobile app for brain-healthy habits | Product | $50,000 |

Cerebrum describes the Percepta deal as "a world's first tokenization of a robust patent portfolio and a world's first tokenized crowdsale for a clinical evidence study" ([cerebrumdao.com](https://www.cerebrumdao.com/projects/percepta-brain)) — an illustration of how a BioDAO can pool retail capital behind a specific clinical study rather than a whole company.

## NEURON token & governance

Cerebrum raised its treasury through a **Dutch auction of the NEURON token** on the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) launchpad, with a deadline of 3pm CET on 30 April 2024; every participant paid the same clearing price and lower bidders were refunded, with US persons excluded and Persona KYC required ([Bio Protocol](https://www.bio.xyz/blog-posts/bringing-neuroscience-onchain-with-cerebrum-dao)). NEURON is a freely-transferable ERC-20 on Ethereum ([0xab81…4a6b](https://etherscan.io/token/0xab814ce69e15f6b9660a3b184c0b0c97b9394a6b)).

Holding NEURON confers **governance rights** over which research the DAO funds, plus exclusive access to the DAO's IP Tokens, discounted access to future brain-health products, and early access to any therapeutics it brings to market ([cerebrumdao.com/neuron-token](https://www.cerebrumdao.com/neuron-token)). Voting is on-chain and token-weighted: influence over the funding pipeline scales with the size of a holder's NEURON balance.

## How Caper approaches this

Cerebrum shows both the promise and the tension in token-governed research funding. The promise is real: a community, not a single fund, decides which neuroscience gets backed, and owns the resulting IP-NFTs. The tension is that **NEURON is a freely-tradeable token** — so control over which science gets funded has a spot price. A large enough buyer can accumulate NEURON and tilt the funding pipeline, and the voice a long-time contributor earned is worth exactly the same as the same balance bought yesterday.

[Caper](/wiki/foundations/what-is-a-caper) keeps token-weighted stake but adds a factor that cannot be bought. Every vote mints a **soulbound proof-of-vote token** — non-transferable and indivisible (`DIVISIBILITY_NONE`, and mintable/depositable only by the DAO component so it can never move between holders; `contracts/core/src/caper_dao.rs`). A member's voting weight is `(t·v)/(V·T)` — held governance tokens `t` multiplied by their earned vote record `v`, over supply — and the treasury [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) share is computed by the very same formula. So a big NEURON-style bag still counts (`t` is a multiplier, not ignored), but it cannot by itself capture the pipeline: the decisive, earned part of governance weight is a record you accumulate by participating, and it is not for sale.

## CryoDAO

URL: https://caper.network/wiki/desci/ecosystem/cryodao
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Type** | DeSci DAO – cryopreservation & biostasis R&D |
| **Focus** | Cryopreservation, biostasis, cryobiology research funding |
| **First proposal** | CRYO-1, 27 November 2023 |
| **Founding member** | Kai Micah Mills (Thiel Fellow; also Cryopets, American Biostasis Foundation) |
| **Governance** | [vote.cryodao.eth](https://snapshot.box/#/s:vote.cryodao.eth) on Snapshot – 30 proposals, 115 followers, **no quorum on any of them** |
| **Token** | CRYO (Ethereum); voting weight is raw balance across three CRYO contracts plus vCRYO, with no delegation |
| **Latest vote** | CRYO-26, 28–31 July 2026 – elected Dr Emil Kendziorra Research Steward, 7 voters |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO |
| **IP framework** | [Molecule](/wiki/desci/ecosystem/molecule) [IP-NFTs](/wiki/desci/ip-nfts) |
| **Treasury** | ~$5M+ (self-reported) |
| **Website** | [cryodao.org](https://www.cryodao.org) |

## Overview

CryoDAO is a [decentralized science (DeSci)](/wiki/desci/what-is-desci) organization that funds research in [cryopreservation, biostasis, and cryobiology](https://www.bio.xyz/blog-posts/cryopreservation-and-the-future-of-life-a-closer-look-at-cryodaos-vision) – the science of preserving cells, tissues, organs, and whole organisms at very low temperatures so they can be revived, or restored, once the medicine to treat them exists. It operates as a BioDAO within the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) ecosystem, and states its objective plainly: [to contribute to cryopreservation research projects that have a high potential to increase the quality and capabilities of cryopreservation](https://www.cryodao.org).

Cryopreservation is chronically under-funded – the field sits between clinical medicine, longevity, and cryonics, and rarely fits a conventional grant or venture mandate. CryoDAO pools community capital to back the high-risk, high-upside experiments that de-risk the underlying technology, a bet organised through a founding cohort that includes [Kai Micah Mills](https://www.linkedin.com/in/kaimicahmills/), a Thiel Fellow who also founded Cryopets and the American Biostasis Foundation. Its first governance proposal opened on 27 November 2023.

## Governance and the CRYO token

CryoDAO [follows the VitaDAO model](https://www.bio.xyz/blog-posts/cryopreservation-and-the-future-of-life-a-closer-look-at-cryodaos-vision): the community votes on which research proposals to fund using the [CRYO token](https://www.cryodao.org/the-cryo-token), and intellectual property emerging from the work it backs is funded, governed, and developed through [Molecule](/wiki/desci/ecosystem/molecule)'s [IP-NFT](/wiki/desci/ip-nfts) framework rather than assigned to a single lab or company.

Those votes run in CryoDAO's own Snapshot space, [vote.cryodao.eth](https://snapshot.box/#/s:vote.cryodao.eth), which has carried 30 proposals numbered CRYO-1 through CRYO-26 and has 115 followers. This is a distinct body from [Bio Protocol's bioxyz.eth space](https://snapshot.box/#/s:bioxyz.eth), which decides BIO's own treasury and ecosystem questions under a BIOPSY prefix and has never carried a CryoDAO funding vote. Weight is a plain token balance: four `erc20-balance-of` strategies summing CRYO across three contract addresses plus vCRYO, with no delegation strategy, so influence cannot be lent to an active voter by a passive holder.

The space sets no quorum, no voting period, no delay and no default voting type, leaving each of those to the individual proposal – and **every one of the 30 proposals has been posted with a quorum of zero**. There is therefore no participation floor a funding decision has to clear, which matters because participation has collapsed.

CRYO trades as a [listed token on Ethereum](https://www.coingecko.com/en/coins/cryodao); as with any freely-traded governance token, its market price moves independently of the DAO's on-chain treasury, which the project reports at roughly $5M+. This is the same token-versus-treasury tension that runs through [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) generally – the traded price of a governance chip and the value of the work it funds are two different things.

## Turnout, and what a zero quorum means in practice

The full [vote record](https://snapshot.box/#/s:vote.cryodao.eth) is public, and read end to end it describes a DAO that deliberates less each year:

|  |  |  |
| --- | --- | --- |
| **Year** | **Proposals** | **Median voters** |
| 2023 (from 27 Nov) | 3 | 6 |
| 2024 | 21 | 13 |
| 2025 | 3 | 3 |
| 2026 (to date) | 3 | 1 |

The high-water mark was the CryoDAO Liquidity and Treasury Proposal of 15 January 2024, which drew **79 voters**. Nothing since has come close. Two of the three proposals put to the DAO in 2026 passed on **a single voter**: CRYO-24, which funded the rescue of [NASA's Rodent Research-20 samples](https://science.nasa.gov/biological-physical/investigations/rr-20/) after the experiment was defunded, closed on 5 January 2026 with one ballot carrying 447 CRYO; and CRYO-25, the CryoPig study – a €50,000 grant for multi-organ cryopreservation with HIFU rewarming in a pig model, led by Diego Monzón Díaz MD at Hospital Gregorio Marañón with Prof. Ramon Risco of the University of Seville – closed on 20 February 2026 with one ballot carrying 256,608 CRYO. Both ran three-day voting windows. Both passed unanimously, because there was nobody to disagree.

The most recent vote is the healthiest of the three. CRYO-26, open 28 to 31 July 2026, elected Dr Emil Kendziorra – CEO and co-founder of Tomorrow Bio – as a Research Steward to supply scientific review capacity for the proposal pipeline, and drew 7 voters casting 275,737 CRYO For, none Against and none abstaining. The proposal was submitted by CryoCore, the DAO's core team, which also authored the two single-voter proposals before it.

That is the honest reading of this governance model: proposals are written by a core team and ratified by a handful of large holders, with no quorum that could stop a proposal nobody turns up for. It is the [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) pattern in an unusually pure form – not a contested vote with low turnout, but an uncontested one, which is a weaker check than the mechanism looks like on paper. The science being funded is real and the reviewers being appointed are credible; what the ballot is doing is recording a decision, not testing it.

## Funded research

CryoDAO's [funded portfolio](https://www.cryodao.org/projects) spans the concrete engineering problems that stand between today's cryobiology and reversible whole-organ or whole-organism preservation. Representative projects, each traceable to the proposal that authorised it:

- **CryoPig – multi-organ cryopreservation with HIFU rewarming** (CRYO-25, February 2026) – cooling and then reviving organs in a pig model using high-intensity focused ultrasound to rewarm tissue evenly and avoid the cracking and ice damage that fast rewarming causes.
- **CRYORAT** (CRYO-21 and CRYO-21.1, November 2024; CRYO-23, April 2025) – high sub-zero preservation and revival of a small mammal, a milestone experiment toward reversible whole-body biostasis.
- **Cryoprotective Agent (CPA) Repository** (CRYO-19, August 2024; expanded under CRYO-19.1, April 2025) – an open reference of cryoprotectants for researchers and medicinal chemists, aimed at developing new agents that reduce the toxicity current protocols impose.
- **American Biostasis Foundation (STASIS)** (CRYO-22, May 2025) – a purpose-built long-term cryopreservation facility and research lab.
- **Saving NASA's Space Mice** (CRYO-24, January 2026) – preserving the samples from NASA's Rodent Research-20 ISS experiment, which studied spaceflight's effect on ovarian function and bone loss, after budget cuts ended the programme.
- **Gaia Life** (CRYO-20, August 2024) and the DAO's **Molecule Catalyst** and **Fast Grants Fellowship** funding routes (CRYO-16 and CRYO-14, June 2024).

Each is chosen and paid out by member vote, and the results – protocols, data, and reference material like the CPA repository – are pushed toward an open commons rather than enclosed behind a single owner.

## How Caper approaches this

CryoDAO's loop – raise a community treasury, then let token holders vote research grants out of it – is the shape a [caper](/wiki/foundations/what-is-a-caper) runs natively. On Caper the raise happens on a [bonding curve](/wiki/markets/bonding-curve) into the caper's own treasury, so contributed capital accrues to the treasury itself rather than to a free-floating token whose price detaches from the work – the exact token-versus-value gap a grants DAO usually has to manage by hand. Each grant is then a governance-approved [PAYOUT proposal](/wiki/governance/proposals) that moves a chosen currency and amount from the treasury to a lab once members [vote it through](/wiki/governance/voting).

The turnout problem above is the one Caper's weighting is aimed at. Voting weight is stake weighted by earned participation – the canonical `(t·v)/(V·T)`, where held tokens are one multiplicative factor alongside a non-transferable record of how you have voted – so a member who keeps showing up carries more of the decision than a comparable balance that does not, and a balance that has never voted carries none of it. That does not manufacture turnout, and nothing in a protocol can. What it changes is who a thin vote belongs to: the weight sits with the members who have been participating rather than with whoever happens to hold the most tokens on the day.

Members also keep a [participation-weighted exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on the undeployed treasury, computed from that same weight – a built-in accountability lever for capital funding long-horizon, high-uncertainty science, and the recourse a holder has when a decision goes through on one ballot. Caper does not supply the cryobiology itself, which is the hard domain-specific part; what it supplies is the treasury, spending, and exit rails a research DAO would otherwise assemble from scratch.

## External links

- [CryoDAO – official website](https://www.cryodao.org)
- [CryoDAO on Snapshot (vote.cryodao.eth)](https://snapshot.box/#/s:vote.cryodao.eth) – the full CRYO-1 to CRYO-26 vote record
- [CryoDAO – funded projects](https://www.cryodao.org/projects)
- [Cryopreservation and the Future of Life – Bio Protocol on CryoDAO](https://www.bio.xyz/blog-posts/cryopreservation-and-the-future-of-life-a-closer-look-at-cryodaos-vision)
- [CryoDAO newsletter](https://news.cryodao.org)

## Curetopia

URL: https://caper.network/wiki/desci/ecosystem/curetopia
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Type** | DeSci BioDAO — rare-disease drug discovery & community medicine |
| **Focus** | Funding and owning treatments for the 10,000+ rare diseases with no approved therapy; drug repurposing for inherited metabolic disease |
| **Launched** | 2025 (community auction & TGE March 2025); [Bio Incubator Cohort 2](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia) |
| **Lead scientist** | Dr. Ethan Perlstein (Harvard PhD, Y Combinator alum; previously advanced a rare-disease drug to Phase 3) |
| **Governance** | Token-weighted — one vote per $CURES token; proposals discussed publicly then voted on-chain |
| **Token** | $CURES (Solana; 100,000,000 max supply) |
| **Community raise** | $1.77M from 1,000+ funders (March 16, 2025) |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO — the first BioDAO to launch a community auction on Solana |
| **IP framework** | [Molecule](/wiki/desci/ecosystem/molecule) [IP-NFTs](/wiki/desci/ip-nfts) |
| **Website** | [curetopia.xyz](https://www.curetopia.xyz/) |

## Overview

**Curetopia** is a [decentralized-science](/wiki/desci/what-is-desci) (DeSci) research collective — a [BioDAO](/wiki/desci/desci-daos) that uses on-chain governance and tokenized intellectual property to fund cures for **rare diseases**. It describes itself as [“community medicine”](https://www.bio.xyz/blog-posts/curetopia-accelerating-rare-disease-cures-using-desci-powered-community-medicine): patient communities and their allies collectively decide which research to back, and the resulting IP is owned by the community rather than a single sponsor.

Curetopia is the [first BioDAO to run a community auction on Solana](https://www.bio.xyz/blog-posts/curetopia-raises-1-77m-to-accelerate-rare-disease-cures-using-desci), and was incubated through the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) launchpad. It is led by **Dr. Ethan Perlstein** — a Harvard PhD and Y Combinator alum who previously founded a biotech that advanced a rare-disease drug into Phase 3 trials — placing an experienced drug developer at the head of a patient-owned research organization.

## The rare-disease funding gap

More than **10,000 rare diseases** collectively affect roughly [1 in 10 people globally](https://www.bio.xyz/blog-posts/curetopia-raises-1-77m-to-accelerate-rare-disease-cures-using-desci), yet the overwhelming majority have **no approved treatment**. Each individual disease has a small patient population — an estimated $200–300M addressable market per condition — so traditional pharma, optimized for blockbuster indications, systematically under-invests in them. The unmet need is enormous in aggregate (a $1 trillion-plus economic burden in the U.S. alone) but fragmented into thousands of markets each too small to attract conventional capital.

Curetopia's answer is to pool that fragmented demand. Patients, families and researchers who each care intensely about one rare condition coordinate through a shared treasury and governance token, and the DAO concentrates on the highest-leverage opportunities — beginning with **drug repurposing** for inherited metabolic diseases, where an already-approved molecule can reach patients far faster and more cheaply than a new chemical entity. This is the same [patient-directed funding](/wiki/desci/desci-funding) thesis that [VitaDAO](/wiki/desci/ecosystem/vitadao) pioneered for longevity, applied to the long tail of orphan conditions.

## The $CURES token and governance

Curetopia is coordinated by the **$CURES** token on Solana, with a maximum supply of **100,000,000**. Governance is [token-weighted at one vote per token](https://www.curetopia.xyz/cures): proposals are posted publicly, discussed by the community, and then voted on by $CURES holders. Roughly 15% of supply was distributed through the community auction, with the remainder allocated across the core team, treasury reserves and contributor incentives.

What distinguishes Curetopia's design is that the token is also a **contribution reward**. Curetopians who supply [data of any kind, biospecimens, clinical-trial participation, or even compute time](https://www.curetopia.xyz/cures) for analysis earn $CURES — so the people who materially advance the research also accumulate governance rights over it. Smart contracts attach “use-it-or-lose-it” commitments to shared data and cell lines, unlocking token rewards only when a resource is actually put to work. It is a [DAO-tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) model built to align voting power with genuine scientific contribution, not merely with capital.

## AARS2, IP-NFTs and community medicines

Curetopia tokenizes the research it funds as [IP-NFTs](/wiki/desci/ip-nfts) through [Molecule](/wiki/desci/ecosystem/molecule): a patent or research program is minted on-chain and can be fractionally owned, so provenance and licensing are auditable by anyone — including the patient communities themselves. When tokenized IP leads to an approved drug, the resulting revenue flows back to the Curetopia treasury as [“community medicines”](https://www.curetopia.xyz/cures) owned by the DAO rather than a private licensor.

The model has already produced a concrete result. Curetopia identified a [potential treatment for AARS2](https://www.bio.xyz/blog-posts/curetopia-raises-1-77m-to-accelerate-rare-disease-cures-using-desci) — a fatal rare disease with no approved therapy — and moved to file a provisional patent on the findings and tokenize it, with proceeds directed back to the DAO. It is exactly the loop the structure is meant to close: community-funded discovery becoming community-owned IP whose upside returns to the patients who backed it.

## Place in the Bio Protocol ecosystem

Curetopia sits alongside [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity), [HairDAO](/wiki/desci/ecosystem/hairdao) (hair loss), [CryoDAO](/wiki/desci/ecosystem/cryodao) (cryopreservation), [ValleyDAO](/wiki/desci/ecosystem/valleydao) (synthetic biology) and [Cerebrum DAO](/wiki/desci/ecosystem/cerebrum-dao) (brain health) in the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) portfolio of BioDAOs. It was one of three projects — with **Long COVID Labs** and **Quantum Biology DAO** — admitted early to [Bio Incubator Cohort 2](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia).

Its $1.77M community raise from [1,000+ individual funders](https://www.bio.xyz/blog-posts/curetopia-raises-1-77m-to-accelerate-rare-disease-cures-using-desci) in March 2025 made it a notable proof point for the Solana DeSci thesis and for Bio Protocol's launchpad, and it has since [partnered with initiatives such as MIRA](https://x.com/bioprotocol/status/1894471903471173763) to widen its reach into rare-disease patient networks.

## How Caper approaches this

Curetopia rewards the people who do the work — contributing data, biospecimens or trial participation earns $CURES, and $CURES is governance. That instinct, tying influence to contribution, is the same one [a caper](/wiki/foundations/what-is-a-caper) builds in at the protocol level. The difference is what happens after the token is minted: $CURES trades freely at one vote per token, so a large enough buyer on the open market can accumulate a decisive say over which rare-disease research gets funded, regardless of whether they ever contributed.

On [Caper](/wiki/foundations/what-is-a-caper), a member's influence is the [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — governance holdings `t` multiplied by an _earned, soulbound_ proof-of-vote record `v` (verified in `contracts/logic/src/lib.rs`: `compute_vote_weight` returns `(held·votes)/(supply·circulation)`; and in `contracts/core/src/caper_dao.rs`, where the vote token is minted one-per-vote at `DIVISIBILITY_NONE` with a depositor rule of `global_caller` and `depositor_updater` set to `deny_all`, which makes it non-transferable). The same formula sets a member's [treasury exit share](/wiki/markets/raising-funds), and `exit()` reuses that exact weight before burning the tokens. A big bag still counts — `t` is a multiplier, not bagless — but the decisive part of governance is participation nobody can purchase. For a patient community deciding whose cure to back, that keeps control with the people the science is actually for.

## DermaLabs (DermaDAO)

URL: https://caper.network/wiki/desci/ecosystem/dermalabs
Updated: 2026-08-12

| Name | DermaLabs (DermaDAO) |
| --- | --- |
| Type | Decentralized-science (DeSci) BioDAO — consumer-product-led dermatology research |
| Focus | Skin health & longevity: turning everyday skincare use into standardized, real-world observational trials |
| Token | $SKIN (utility – governs research direction and funding, no equity or revenue rights); as of 12 August 2026 the live route to it is an airdrop for early data contributors, not a running rewards programme |
| Products | Moon Drops (evening antioxidant serum) & Sol Drops (daytime mineral serum) shipping; SkinScan AI-imaging app listed _coming soon_ behind a waitlist as of 12 August 2026 |
| Launchpad | [BIO Protocol](https://app.bio.xyz/daos/dermalabs) (bio.xyz) — $SKIN Ignition Sale (Gnosis batch auction), December 2025 |
| Science lead | Dr. DTS (Hongseok Kim), board-certified Korean dermatologist |
| Trials programme | In development – dermadao.xyz states it "is currently in development and will be launching soon" (checked 12 August 2026) |
| Status | 🟢 Active |

## Overview

**DermaLabs** (governed as **DermaDAO**) is a decentralized-science BioDAO on the [Bio Protocol launchpad](https://app.bio.xyz/daos/dermalabs) that reorganizes skincare research around real-world data instead of small, one-off clinical panels. It pairs dermatologist-led formulation with a community that opts into standardized, pre-registered trials, capturing measurable skin changes through an AI-imaging app and rewarding validated data contributions with tokens ([bio.xyz](https://www.bio.xyz/blog-posts/every-bathroom-mirror-is-a-laboratory-how-dermalabs-is-rebuilding-skincare-science-from-the-ground-up)). It sits in the same [DeSci](/wiki/desci/what-is-desci) lineage as [VitaDAO](/wiki/desci/ecosystem/vitadao) and [HairDAO](/wiki/desci/ecosystem/hairdao), but occupies a distinct niche: the consumer product _is_ the experiment.

## The thesis: every bathroom mirror is a laboratory

Skincare is a [$190 billion-plus global industry](https://www.bio.xyz/blog-posts/every-bathroom-mirror-is-a-laboratory-how-dermalabs-is-rebuilding-skincare-science-from-the-ground-up) that still validates products on small, short, industry-funded panels — methodologically closer to marketing than to science. DermaLabs' bet is that the largest untapped dataset in dermatology is the one billions of people already generate every morning and night. By standardizing how ordinary users apply a product and photograph the result, it converts routine consumer behavior into a continuously growing longitudinal study across real climates, routines, skin tones, and adherence levels ([dermadao.xyz](https://dermadao.xyz/science)). The product is the data-generation flywheel: buying and using the serum is how a member enters the trial.

## Products and SkinScan

DermaLabs ships evidence-first consumer skincare as the on-ramp to its research loop. Its first products are **Moon Drops**, an evening antioxidant serum combining L-ascorbic acid, alpha-tocopherol, and ferulic acid, and **Sol Drops**, a daytime mineral serum with zinc oxide, titanium dioxide, niacinamide, and panthenol ([bio.xyz](https://www.bio.xyz/blog-posts/every-bathroom-mirror-is-a-laboratory-how-dermalabs-is-rebuilding-skincare-science-from-the-ground-up)). Each purchase credits the buyer BioXP toward the wider Bio ecosystem.

The measurement layer is **SkinScan**, described as an AI-imaging app that turns a phone into a clinically relevant skin lab, quantifying wrinkles, spots, and redness from user photos. On [dermadao.xyz](https://dermadao.xyz/science), checked 12 August 2026, it is listed as **coming soon** behind a waitlist rather than as a shipped tool. The design intent is unchanged and worth stating on its own terms: standardized capture would turn a selfie into a comparable data point, so a member's own before/after becomes a row in a shared, auditable dataset rather than an anecdote. Whether that measurement layer exists yet is a separate question from whether the idea is sound, and as of this check it does not.

## Decentralized trials and IP

DermaDAO's stated research model is blinded, pre-registered A/B protocols run on-chain: participants follow a defined regimen, keep time-stamped photo journals, and are rewarded for validated contributions, with AI-assisted analysis quantifying changes in measurable skin attributes. Its illustrative study is the **LUNAR trial** ("Longevity Using Novel Actives for Rejuvenation"), in which Moon Drops serves as the baseline formulation and enhanced variants are tested side by side under standardized protocols, tracked longitudinally rather than at a single endpoint ([bio.xyz](https://www.bio.xyz/blog-posts/every-bathroom-mirror-is-a-laboratory-how-dermalabs-is-rebuilding-skincare-science-from-the-ground-up)). Because a design registered up front and data that stays user-owned permit _stratified_ analysis – by diagnosis, skin tone, and age – the model could answer questions a single-panel study cannot.

**None of it is running yet.** Checked 12 August 2026, [dermadao.xyz](https://dermadao.xyz/science) states plainly that "the decentralized trials program is currently in development and will be launching soon", and invites people to fill in a survey form to become an early contributor and "stand to earn a $SKIN Airdrop". The words "pre-registered" and "IP-NFT" do not appear on that page. So the honest present-tense description is a shipped consumer product line and a research programme that has been designed and announced but not yet opened – a distinction the DAO's own site draws, and one worth preserving here rather than reading the roadmap as the record.

If and when the programme opens, the intended output layer is [IP tokens (IP-NFTs)](/wiki/desci/ip-nfts) – the same [Molecule](/wiki/desci/ecosystem/molecule)-pioneered primitive [VitaDAO](/wiki/desci/ecosystem/vitadao) uses – so a validated finding would become a transparent, community-owned, fundable asset rather than a corporate trade secret. That is the model DermaLabs sits inside by virtue of being a [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO, not a step it has been observed taking.

## The science team

DermaLabs is fronted by a working dermatology and cosmetic-chemistry bench rather than a purely crypto-native team ([bio.xyz](https://www.bio.xyz/blog-posts/every-bathroom-mirror-is-a-laboratory-how-dermalabs-is-rebuilding-skincare-science-from-the-ground-up)):

- **Dr. DTS (Hongseok Kim)** — board-certified Korean dermatologist focused on evidence-based K-beauty, and the public face of the launch.
- **Jez Marston** — physician-scientist with a PhD in immunology and computational biology (Cornell).
- **Hyeon Pyo Jhun** — cosmetic chemist with 40-plus years in skincare R&D.
- **Dongsinne Sohn** — health and Web3 operator focused on chronic skin conditions.

## The $SKIN token and place in the Bio ecosystem

**$SKIN** is DermaDAO's utility token: it rewards validated data and product contributions and lets holders govern research direction and funding, with no equity or revenue claim ([dermadao.xyz](https://dermadao.xyz/science)). It launched through Bio Protocol's [Ignition Sale mechanism](https://docs.molecule.to/bio.xyz/launchpad/faqs) — a [Gnosis batch-auction](https://docs.molecule.to/bio.xyz/launchpad/faqs) where participants bid stablecoins for a fixed token allocation — in December 2025.

DermaLabs is one of [Bio Protocol's](/wiki/desci/ecosystem/bio-xyz) incubated BioDAOs, alongside longevity ([VitaDAO](/wiki/desci/ecosystem/vitadao)), hair loss ([HairDAO](/wiki/desci/ecosystem/hairdao)), cryopreservation ([CryoDAO](/wiki/desci/ecosystem/cryodao)), and quantum biology ([Quantum Biology DAO](/wiki/desci/ecosystem/quantum-biology-dao)). What sets it apart is going to a shipped, revenue-generating consumer product first and treating that product line as the recruitment funnel for its science — the clearest example in the [BioDAO](/wiki/desci/desci-daos) set of the "real-world DeSci product" model.

## How Caper approaches this

DermaLabs and [Caper](/wiki/foundations/what-is-a-caper) answer different questions, but they meet on one: who should steer a community-funded effort, and how is that steering earned? DermaDAO rewards contribution with a freely tradeable [$SKIN](https://dermadao.xyz/science) token — data and purchases mint governance power that can then be bought or sold on the open market. Caper takes the opposite stance on the decisive slice of control: voting on a caper mints a _soulbound, non-transferable_ proof-of-vote token (indivisible, and locked to its holder — its deposit authority is the component itself, with updates permanently denied, per `contracts/core/src/caper_dao.rs`). A member's on-chain influence is `compute_vote_weight = (t·v)/(V·T)` in `contracts/logic/src/lib.rs` — their token holdings _times_ their earned votes, over the totals — so a big bag alone can't capture control, and participation can't be purchased after the fact. The same weight sets a member's [exit](/wiki/governance/proposals) redemption before the vote tokens are burned. For a research DAO, the honest read is that each model optimizes for something real: $SKIN maximizes liquid, tradeable incentives to contribute data at scale, while Caper's earned, un-sellable weight is built for the case where you specifically do not want steering to be for sale.

## DeSci Labs

URL: https://caper.network/wiki/desci/ecosystem/desci-labs
Updated: 2026-08-03

| Name | DeSci Labs |
| --- | --- |
| Type | DeSci infrastructure company + [DeSci Foundation](https://www.descifoundation.org/about) (standards steward) |
| Focus | Open, content-addressed scientific publishing & persistent identifiers |
| Founded | Switzerland, July 2021 |
| Founders | Prof. Philipp Koellinger (CEO), Dr. Christopher Hill, Sina Iman |
| Products | [DeSci Nodes / DeSci Publish](https://www.desci.com/publish), [DeSci Codex](https://www.desci.com/blog/how-desci-codex-makes-scientific-research-durable-reusable-and-ai-ready), [dPID](https://www.dpid.org/) |
| Funding | [$6.5M seed](https://startupsmagazine.co.uk/article-desci-labs-raises-65m-transform-scientific-publishing) (29 Aug 2024) |
| Status | 🟢 Active |
| Website | [desci.com](https://www.desci.com) |

## Overview

[DeSci Labs](https://www.desci.com/about) is a Swiss software company building the base infrastructure for [decentralized science](/wiki/desci/what-is-desci) – the open, content-addressed layer beneath the field's publishing and funding platforms. Where BioDAOs such as [VitaDAO](/wiki/desci/ecosystem/vitadao) or [ResearchHub](/wiki/desci/ecosystem/researchhub) coordinate _who funds and reviews_ research, DeSci Labs builds the plumbing that makes a research output durable, versioned, and machine-readable in the first place.

It is the first **infrastructure and standards** organization in this directory rather than a funder or a patient community: its products – [DeSci Nodes](https://www.desci.com/publish), the [dPID](https://www.dpid.org/) identifier protocol, and the [DeSci Codex](https://www.desci.com/blog/how-desci-codex-makes-scientific-research-durable-reusable-and-ai-ready) network – are the components the [decentralized-publishing pillar](/wiki/desci/decentralized-publishing) cites as the tooling under everything else.

## The problem it targets

DeSci Labs was founded on a diagnosis of the traditional scientific record: results are frozen into flat PDFs that strip out the data, code, and provenance, then locked behind a [publishing cartel](/wiki/desci/decentralized-publishing) at margins that dwarf most of tech. CEO Philipp Koellinger frames the deeper cost as a [“replication crisis that is derailing scientific progress”](https://startupsmagazine.co.uk/article-desci-labs-raises-65m-transform-scientific-publishing) – a problem the wiki treats at length in the [reproducibility-crisis](/wiki/desci/reproducibility-crisis) page.

Two failures follow from the PDF-as-unit-of-record model. Citations point at _link-rotting URLs_ rather than the exact bits that were reviewed, so the literature quietly drifts out from under its own references; and the underlying data and code, severed from the paper, cannot be independently re-run. DeSci Labs' answer is to change the unit of publication itself.

## Research objects: DeSci Nodes & DeSci Publish

The core move is to publish a **research object** instead of a document: manuscript, datasets, code, figures, and metadata bundled into one versioned, independently-addressable unit. [DeSci Nodes](https://www.desci.com/publish) (also shipped as [DeSci Publish](https://startupsmagazine.co.uk/article-desci-labs-raises-65m-transform-scientific-publishing), billed as “the first open-source, peer-to-peer platform for scientific publishing”) is the application researchers use to assemble and release these objects, with private drafts, licensing, and transparent version history built in.

The engine is open source: the [desci-labs/nodes](https://github.com/desci-labs/nodes) repository describes Nodes as “secure PID containers for interoperable research objects.” Around it sits a developer surface – `Codex-Lib` for low-level protocol access, `Nodes-Lib` and a `Nodes CLI` for automated publishing – so other DeSci applications can publish to the same network without rebuilding the storage layer.

## dPID: decentralized persistent identifiers

When a Node is published it automatically receives a [dPID](https://www.dpid.org/) (decentralized persistent identifier). Unlike a DOI – a mutable pointer administered by a central registrar – a dPID is built on **content identifiers (CIDs)**, the cryptographic fingerprints used by [IPFS](https://ipfs.tech), so “the same logical object always maps to the exact same sequence of bits.” That guards against [content drift](https://docs.desci.com/create-and-publish/share/persistent-identifier-dpid) and lets a reader cite an individual component of a paper, not just the whole.

dPIDs read like short, human-friendly filepaths with version and history control, resolvable through the [dPID Browser](https://www.dpid.org/) or an open-source HTTP _dPID Resolver_ that bridges the conventional web to decentralized storage. Notably the protocol is a **split responsibility**: per dpid.org it is “Engineering by DeSci Labs & Governance by the DeSci Foundation” – the company writes the code, a separate non-profit stewards the standard.

## DeSci Codex & the Open State repository

[DeSci Codex](https://www.desci.com/blog/how-desci-codex-makes-scientific-research-durable-reusable-and-ai-ready) is the open protocol beneath the app – “a decentralized network for publishing and preserving scientific research objects.” Content is content-addressed and securely replicated across multiple nodes via peer-to-peer resolution, so a published object survives independent of any single service provider. Institutions can run `Codex-Node` backend services to participate in that replication and add durability to the network.

The stated payoff is research that is **durable, reusable, and AI-ready**: because every object carries its data, code, and an auditable provenance chain – who published what, when, and what changed – results become both independently reproducible and directly machine-readable, the container the flat PDF never was. It is the same open-record shift the rest of DeSci makes with [IP-NFTs](/wiki/desci/ip-nfts), applied to the publication itself.

## Company and Foundation: engineering vs. governance

DeSci Labs deliberately separates the venture-funded engineering company from the neutral steward of the standards it depends on. The [DeSci Foundation](https://www.descifoundation.org/about) is a non-profit registered in Canton Zug, Switzerland (CHE-389.450.872, subject to annual Swiss audit) whose mission is to “explore and support improvements in the scientific ecosystem” and to “enfranchise stakeholders” in the emerging field.

The two are organizationally distinct but aligned: Koellinger is the Foundation's president as well as DeSci Labs' CEO, and co-founder Christopher Hill sits on its five-member Executive Board, which works alongside an advisory board of 15+ from academia, blockchain, and open science. Keeping the identifier standard's governance in a separate non-profit – rather than inside the company that could later be acquired or wound down – is a bet on [credible neutrality](/wiki/dao-governance/concepts/fundamentals/governance-minimization) for infrastructure the whole field is meant to build on.

## Funding, team & place in the ecosystem

DeSci Labs closed a [$6.5M seed round on 29 August 2024](https://startupsmagazine.co.uk/article-desci-labs-raises-65m-transform-scientific-publishing), backed by Stride VC, OSS Capital, [Protocol Labs](https://www.protocol.ai), Accomplice, HV Capital, and Holtzbrinck Digital, with the capital earmarked for a “traceable digital scientific record” and the DeSci Publish launch. The team of roughly a dozen engineers and scientists is led by Koellinger (a behavioral-genetics researcher with 17,000+ citations, formerly of the University of Wisconsin–Madison and Vrije Universiteit Amsterdam), Hill (a neuro-economist), and Iman (a software engineer previously at Palantir).

Within the wider field DeSci Labs is the layer under the platforms: [ResearchHub](/wiki/desci/ecosystem/researchhub) pays for peer review, [Molecule](/wiki/desci/ecosystem/molecule) and [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) route funding into [BioDAOs](/wiki/desci/desci-daos), and DeSci Nodes plus dPID give all of them a durable, content-addressed way to name and preserve what the science actually produces.

## How Caper approaches this

DeSci Labs is not a governance protocol – it publishes research, not treasuries – but the two share a load-bearing idea: **a decision, or a result, should be a durable, content-addressed record that anyone can audit, not a claim you take on trust.** A dPID pins the exact bits that were reviewed so a citation can't rot out from under itself.

[Caper](/wiki/foundations/what-is-a-caper) makes the equivalent move for what a DAO _does_ with money: every treasury action is a [typed proposal](/wiki/governance/proposals) – a _PAYOUT_ that transfers from the treasury, an _INVEST_ that buys another caper's token, or a _VOTE_ that casts that stake in another caper's decision – recorded and executed on-chain rather than settled in a back channel. And it echoes DeSci Labs' second bet, splitting the neutral standard from the company that builds it: in Caper the market itself is immutable (a fixed bonding curve, no reprice method), so only the treasury is ever up for a vote. A research collective that publishes its outputs through DeSci Nodes could fund that work through exactly these typed, auditable proposals. _(Caper mechanics verified against `contracts/core/src/caper_dao.rs` and `contracts/logic/src/lib.rs`.)_

## GenomesDAO

URL: https://caper.network/wiki/desci/ecosystem/genomesdao
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Type** | DeSci DAO / biotech |
| **Founded** | 2018 (Genomes.io) |
| **Focus** | Genomic data ownership & privacy |
| **HQ** | London, UK |
| **Investors** | Pantera Capital, Modular Capital (2024) |
| **Token** | GENOME (consolidated from GENE + GNOME) |
| **Supply** | 1,000,000,000 GENOME (fixed) |
| **Networks** | Base + Ethereum |
| **Technology** | AMD SEV-ES encrypted vaults |
| **Status** | 🟢 Active |
| **Website** | [genomes.io](https://www.genomes.io) |

## Overview

GenomesDAO, built by [Genomes.io](https://www.genomes.io) (founded 2018, London), is a biotech [DeSci DAO](/wiki/desci/desci-daos) focused on the safe, private, and auditable monetization of genomic data — a leading example of [research data ownership](/wiki/desci/research-data-ownership). It combines [AMD's SEV-ES encrypted virtualization, blockchain, and DeFi](https://genomes.gitbook.io/genomes.io-docs) so individuals retain full ownership and control over their DNA data instead of surrendering it to a sequencing company or data broker.

The project [raised a new investment round from Pantera Capital and Modular Capital in 2024](https://www.biospace.com/article/releases/genomesdao-secures-new-investment-round-from-pantera-capital-and-modular-capital/) to expand its encrypted-vault infrastructure.

## How it works

GenomesDAO works with clinical-grade providers to deliver 30x whole-genome sequencing that analyses 100% of the genome. User DNA is stored in fully encrypted "DNA Vaults" secured by AMD SEV-ES, so only the individual controls access. Pharmaceutical companies and research organizations query the data using GENOME tokens, with Genomes.io acting as broker — and critically, the user must approve each individual query of their vault: a query asks a single specific question and only the answer, not the raw genome, ever leaves the vault.

## The GENOME token

GenomesDAO [consolidated its earlier $GENE and $GNOME tokens into a single $GENOME super-token](https://blog.genomes.io/genomesdao-launches-genome-on-base-77707048fcb6), launched on the [Base](https://www.base.org) network and also supported on Ethereum. GENE swaps 1:1 into GENOME and GNOME swaps 10:1, for a fixed total supply of 1 billion GENOME. GENOME is the deflationary utility token pharmaceutical and research buyers spend to query consenting users' vaults — a data-marketplace design where the token is the metering unit for access rather than a speculative governance chip. As with any traded token, live price and market cap move constantly; [CoinGecko](https://www.coingecko.com/en/coins/genomesdao-genome) carries the current figures.

## The upload campaign and the $GENOME Fund

On 16 September 2024 Genomes.io [announced a DNA-upload feature and a dedicated $GENOME Fund](https://www.newswire.com/news/genomes-io-launches-a-dedicated-genome-fund-aiming-to-build-the-22425002), stating the goal of building “1 billion genomes within the next five years.” The feature accepts existing raw data files rather than requiring a fresh sequencing kit, and the release names the three consumer-genomics platforms it is aimed at by name: **23andMe, MyHeritage, and Ancestry.com**. Contributors accrued points rather than immediate tokens, with $GENOME distributed at the end of a campaign that ran through 31 December 2024.

The pitch is worth stating plainly, because it sets up what happened next: GenomesDAO was inviting people who had _already_ handed their genome to a consumer sequencing company to move a copy into a vault they controlled themselves. As of August 2026 the Genomes.io site is live and carries no dated announcement after that campaign.

## The thesis got a live test: 23andMe, 2025

Six months after the upload campaign closed, the largest platform it named entered bankruptcy, and the resulting record is unusually complete because the company was SEC-reporting throughout. On 23 March 2025, 23andMe Holding Co. and certain subsidiaries [filed voluntary petitions under Chapter 11](https://www.sec.gov/Archives/edgar/data/1804591/000119312525060817/d933650d8k.htm) in the United States Bankruptcy Court for the Eastern District of Missouri. Its common stock was [suspended from Nasdaq at the opening of business on 31 March 2025](https://www.sec.gov/Archives/edgar/data/1804591/000095014225001416/eh250629700_8k.htm) and moved to the OTC Pink market under the symbol “MEHCQ.”

What was then sold was the database. The company's [annual report for the fiscal year ended 31 March 2025](https://www.sec.gov/Archives/edgar/data/1804591/000162828025030786/mehcq-20250331.htm) puts it at “approximately 14.4 million and 15.1 million PGS customers” as of 31 March 2025 and 2024 respectively — a roughly 5% decline the filing attributes “primarily as a result of customers electing to delete their data” — falling further to about 14.0 million by 31 May 2025. The same filing reports that the share of customers who had consented to research “remained consistent at 80%” across both years.

The sale ran as an auction. Bidding was held 14–16 May 2025 among [seven qualified bidders](https://www.sec.gov/Archives/edgar/data/1804591/000095014225001416/eh250629700_8k.htm), with Regeneron Pharmaceuticals selected as successful bidder at $256.0 million in cash. TTAM Research Institute — a California nonprofit public benefit corporation and an affiliate of co-founder, former CEO and then-director Anne Wojcicki — then submitted $305.0 million, bidding was [reopened on 4 June 2025](https://www.sec.gov/Archives/edgar/data/1804591/000119312525141090/d75328d8k.htm), and on 13 June TTAM was selected as winning bidder at $305.0 million with Regeneron as backup at $151.0 million. The court approved the sale on 27 June and the transaction [closed on 14 July 2025](https://www.sec.gov/Archives/edgar/data/1804591/000119312525158551/d11473d8k.htm), transferring substantially all assets “free and clear of liens, claims, encumbrances, and other interests.” The remaining shell [renamed itself Chrome Holding Co. on 14 August 2025](https://www.sec.gov/Archives/edgar/data/1804591/000095014225002208/eh250668029_8k.htm).

For a [data DAO](/wiki/desci/research-data-ownership) the sequence is the argument. Every customer's consent had been given to 23andMe; the database changed hands twice in an auction room regardless, and the only lever an individual held was deletion — which, on the company's own numbers, roughly a million people pulled. GenomesDAO's structural answer is the one described above: the genome stays inside an encrypted vault the individual holds, and each query needs that individual's approval, so there is no consolidated database to convey. Whether that holds at the scale a pharmaceutical buyer needs is still unproven — the vault model has never been tested against a fourteen-million-record incumbent's economics — but the failure mode it is designed against is no longer hypothetical.

## How Caper approaches this

GenomesDAO's model — a token that meters paid access to a member-owned asset, with each transaction individually consented — rhymes with how a [caper](/wiki/foundations/what-is-a-caper) treats value. Where a research or data collective wanted a shared treasury rather than a per-vault broker fee, revenue from data licences would [flow into the caper's treasury](/wiki/markets/raising-funds), disbursements to contributors or infrastructure would run through governance-approved [PAYOUT proposals](/wiki/governance/proposals), and members would keep a [participation-weighted claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on the treasury they built. Caper doesn't provide the confidential-compute vault GenomesDAO's privacy model depends on — that is the harder, domain-specific piece — but it does provide the treasury, spending, and exit rails a data DAO would otherwise assemble from scratch.

## External links

- [Genomes.io — official website](https://www.genomes.io)
- [GenomesDAO documentation](https://genomes.gitbook.io/genomes.io-docs)
- [GENOME on Base — GenomesDAO blog](https://blog.genomes.io/genomesdao-launches-genome-on-base-77707048fcb6)
- [GenomesDAO on X](https://x.com/GenomesDAO)
- [Genomes.io launches the $GENOME Fund (16 September 2024)](https://www.newswire.com/news/genomes-io-launches-a-dedicated-genome-fund-aiming-to-build-the-22425002)
- [SEC filings for 23andMe Holding Co. / Chrome Holding Co. (CIK 0001804591)](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001804591&type=8-K&dateb=&owner=include&count=40)

## Gitcoin DeSci Grants

URL: https://caper.network/wiki/desci/ecosystem/gitcoin-desci
Updated: 2026-07-28

|  |  |
| --- | --- |
| **Type** | Funding Platform |
| **Focus** | Quadratic funding for public goods & DeSci |
| **Infrastructure** | Grants Stack, built on Allo Protocol |
| **First DeSci Round** | GR15 (2022) — $567k+ pool, 82 projects, 2,309 donors |
| **Latest Round** | GG24 — Oct 2025, first round of Gitcoin 3.0 |
| **GG24 Distributed** | ~$1.8M across six funding mechanisms |
| **Website** | [gitcoin.co](https://www.gitcoin.co) |

## Overview

[Gitcoin](https://www.gitcoin.co) is the longest-running quadratic funding platform in the Ethereum ecosystem. Its Grants Round 15 (GR15) featured the [first-ever dedicated DeSci Round](https://web.archive.org/web/2023/https://www.gitcoin.co/blog/gr15-results), applying quadratic funding to open science: reimagining the incentives, culture, and infrastructure for research using Web3 tools.

Quadratic funding matches community donations using a formula that weights the _number_ of contributors above the _size_ of each contribution, so a project backed by many small donors receives proportionally more matching than one backed by a few large ones. This democratizes [science funding](/wiki/desci/desci-funding) in ways a traditional grant committee cannot — and it is why the mechanism depends heavily on [sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos): without a way to tell real donors from sockpuppets, the many-small-donors signal can be gamed.

## How the funding works: Allo Protocol & Grants Stack

Gitcoin's funding runs on [Allo Protocol](https://gitcoin.co/apps/allo-protocol), an open, modular allocation standard, surfaced to grant operators through [Grants Stack](https://gitcoin.co/apps/gitcoin-grants-stack) — the open-source platform that ran the Gitcoin Grants Program from 2023 through May 2025 and powered dozens of ecosystem partner rounds. Allo decouples _who is eligible_, _how funds are allocated_, and _how they are distributed_, so a round can swap in [quadratic funding](https://gitcoin.co/mechanisms/quadratic-funding), direct grants, or retroactive funding without rebuilding the plumbing.

[GG24](https://gitcoin.co/case-studies/gg24-first-funding-round-of-gitcoin-3-0) (October 2025) — billed as the first funding round of "Gitcoin 3.0" — leaned into that modularity, running **six allocation mechanisms in parallel**: quadratic funding, deep funding, MACI private voting, [conviction voting](/wiki/dao-governance/concepts/voting/proposal-lifecycle), retroactive funding, and peer-reviewed [hypercerts](/wiki/dao-governance/concepts/treasury/hypercerts). It is the most mechanistically diverse Gitcoin round to date, and a useful live catalogue of the funding designs the broader [DAO treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) world is experimenting with.

## DeSci Round Results & Trajectory

The GR15 DeSci Round saw [2,309 donors crowdfund $67.9k across 82+ projects](https://web.archive.org/web/2023/https://www.gitcoin.co/blog/gr15-results); with matching partners the total pool exceeded $567k. Funded work built new incentives for open practice, out-of-university validation, and shared research infrastructure — an early proof that community-driven science funding was viable.

DeSci was not carved out as a standalone domain in GG24, but the model GR15 established now shows up across the ecosystem: dedicated DeSci rounds on other platforms and the [one-donor-one-signal](/wiki/dao-governance/concepts/voting/token-weighted-voting) logic that [biotech DAO launchpads](/wiki/desci/ecosystem/molecule) borrow when they open community allocation. Gitcoin itself continues to distribute millions per year across open-source rounds, with dynamic quadratic funding adjusting eligibility and caps for fairer distribution.

## How Caper approaches this

Quadratic funding answers "how do you fund good work when a committee can't scale?" by matching against the _breadth_ of small donors. [Caper](/wiki/foundations/what-is-a-caper) answers the same question differently: instead of a periodic matching round, each caper raises continuously from its [bonding curve](/wiki/markets/bonding-curve), and its treasury deploys that capital through [INVEST and PAYOUT proposals](/wiki/governance/proposals) that holders decide by [participation-weighted voting](/wiki/governance/voting). The shared instinct is the same — put allocation in the hands of the many who show up rather than a gatekept panel — but Caper trades the sybil-resistance overhead of a matching round for stake that has to be bought and held on the curve.

## External Links

- [Gitcoin — Official Website](https://www.gitcoin.co)
- [Gitcoin Grants 24 (GG24)](https://grants.gitcoin.co/)
- [GG24: The First Funding Round of Gitcoin 3.0 — Case Study](https://gitcoin.co/case-studies/gg24-first-funding-round-of-gitcoin-3-0)
- [Allo Protocol](https://gitcoin.co/apps/allo-protocol) · [Grants Stack](https://gitcoin.co/apps/gitcoin-grants-stack)
- [GR15 Results & Recap — Gitcoin Blog](https://web.archive.org/web/2023/https://www.gitcoin.co/blog/gr15-results)

## HairDAO

URL: https://caper.network/wiki/desci/ecosystem/hairdao
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Type** | DeSci DAO — hair-loss (androgenic alopecia) research & drug development |
| **Focus** | Funding and owning R&D into new hair-loss treatments; repurposing and reformulating existing molecules |
| **Founded** | 2021 (first IP-NFT transacted Feb 2023) |
| **Founders** | Andrew Verbinnen & Andrew Bakst |
| **Governance** | Token-weighted — [Discord](https://discord.com/) discussion → on-chain vote (VitaDAO model) |
| **Token** | $HAIR (Gnosis Auction launch, Feb 2023) |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO (first IP-NFT out of the bio.xyz pipeline) |
| **IP framework** | [Molecule](/wiki/desci/ecosystem/molecule) [IP-NFTs](/wiki/desci/ip-nfts) |
| **First IP-NFT** | Cutaneon / Dr. Ralf Paus androgenic-alopecia data — $75,000 (Feb 2023) |
| **Website** | [hairdao.xyz](https://www.hairdao.xyz/) |

## Overview

**HairDAO** is a decentralized-science ([DeSci](/wiki/desci/what-is-desci)) collective that funds, coordinates, and _owns_ research into hair loss. It is one of the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) ecosystem's BioDAOs and was the first project to transact an [IP-NFT](/wiki/desci/ip-nfts) out of the bio.xyz accelerator pipeline — the second BioDAO after [VitaDAO](/wiki/desci/ecosystem/vitadao) to use the model at all, per [Molecule's account of the deal](https://molecule.xyz/blog/hairdao-breaking-the-cosmetic-condition-barrier-and-unlocking-new-funding-possibilities-with-ip-nfts). HairDAO exists to close a funding gap that traditional biotech ignores.

## The "cosmetic condition" funding barrier

Hair loss affects roughly [eight in ten men and half of all women](https://www.hairdao.xyz/) over a lifetime, yet HairDAO reports that only about **0.004%** of early-stage R&D funding targets it, and that no genuinely new treatment has reached market since finasteride in 1997. Because androgenic alopecia is classified as a _cosmetic_ rather than a medical condition, it attracts little grant money and little pharma interest despite a large, motivated patient base. HairDAO's thesis is that a community of patients and researchers — the people who most want a cure — can pool capital, direct it at neglected science, and capture the resulting intellectual property collectively rather than surrendering it to a single company.

## The $HAIR token and governance

HairDAO is coordinated by the **$HAIR** token, launched through a [Gnosis Auction in February 2023](https://molecule.xyz/blog/hairdao-breaking-the-cosmetic-condition-barrier-and-unlocking-new-funding-possibilities-with-ip-nfts). Modeled on [VitaDAO](/wiki/desci/ecosystem/vitadao), the token confers proportional voting rights over the treasury's governance, operations, and investment decisions: both academics and informed community members can propose projects, and holders vote on which receive funding. The DAO's first funding decision — acquiring the Cutaneon dataset — passed a Discord vote 94 to 2 before the on-chain IP-NFT was minted. Capital raised by the token, together with revenue from treatments and genomic data, is recycled into the research pipeline.

## Research funded and community-owned IP

HairDAO's first IP-NFT, minted in February 2023, secured initial androgenic-alopecia data from [Dr. Ralf Paus's lab (Cutaneon) for $75,000](https://molecule.xyz/blog/hairdao-breaking-the-cosmetic-condition-barrier-and-unlocking-new-funding-possibilities-with-ip-nfts), with an option for a further $50,000 to test topical T3/T4 thyroid-hormone dosing. From there the DAO built a pipeline of [funded and in-development projects](https://about.hairdao.xyz/project-pipeline), including a pay-for-success verteporfin trial with Dr. Taleb Barghouthi (reducing scarring in hair-restoration procedures), thyroid-hormone derivatives (TRH, T3, T4), reformulated dutasteride delivery, and Twist-1 / YAP-1 inhibitor work.

The defining feature is **ownership**: research HairDAO funds is captured as [IP-NFTs](/wiki/desci/ip-nfts) and patents held by the DAO's treasury, not by an outside firm — so any upside from a successful treatment flows back to the community that paid for the science. This makes HairDAO an early demonstration that a patient community can commission drug research, hold the resulting intellectual property, and steer it toward openness or licensing on its own terms.

## Place in the Bio Protocol ecosystem

HairDAO sits alongside [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity), [AthenaDAO](/wiki/desci/ecosystem/athenadao) (women's health), [ValleyDAO](/wiki/desci/ecosystem/valleydao) (synthetic biology), [CryoDAO](/wiki/desci/ecosystem/cryodao) (cryopreservation), and [Long COVID Labs](/wiki/desci/ecosystem/long-covid-labs) (post-viral illness) as one of the BioDAOs incubated through [Bio Protocol (bio.xyz)](/wiki/desci/ecosystem/bio-xyz). It shares their common toolkit — [Molecule](/wiki/desci/ecosystem/molecule) IP-NFTs for on-chain research ownership and token-weighted governance for allocation — while pioneering the model for a single, tightly-defined disease vertical driven largely by the patients themselves. For the wider mechanics of how these DAOs turn tokens into funded, community-owned science, see [Decentralized Science Funding](/wiki/desci/desci-funding) and [DeSci DAOs](/wiki/desci/desci-daos).

## How Caper approaches this

HairDAO shows a community pooling capital to fund and _own_ research it cares about — exactly the shape [a caper](/wiki/foundations/what-is-a-caper) is built for. Where they differ is in how much a member's _influence_ can be bought.

In a token-weighted BioDAO, voting power tracks the $HAIR balance, which trades freely — so a large enough buyer can acquire a decisive say over which science gets funded. On [Caper](/wiki/foundations/what-is-a-caper), a member's weight is the [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — governance holdings `t` multiplied by an _earned, soulbound_ proof-of-vote record `v` (verified in `contracts/logic/src/lib.rs`: `compute_vote_weight` returns `(held·votes)/(supply·circulation)`; and in `contracts/core/src/caper_dao.rs`, where the vote token is minted one-per-vote at `DIVISIBILITY_NONE` with a depositor rule of `global_caller`, making it non-transferable). The same formula sets a member's [treasury exit share](/wiki/markets/raising-funds), so a caper cannot be quietly captured by a well-funded latecomer: a big bag still counts (`t` is a multiplier, not bagless), but the decisive factor is participation nobody can purchase. For a DeSci community deciding whose research to back, that keeps control with the people actually doing the work.

## Long COVID Labs

URL: https://caper.network/wiki/desci/ecosystem/long-covid-labs
Updated: 2026-08-12

| Name | Long COVID Labs (LCL) |
| --- | --- |
| Type | Patient-led BioDAO / decentralized therapeutics platform |
| Focus | Long COVID & post-viral illness treatment |
| Token | $COVID — governance only, no dividend or revenue rights; 1,000,000,000 fixed supply; transferable since November 2025 |
| Legal wrapper | Long Covid Labs Association, a Swiss non-profit _Verein_ domiciled in the Canton of Zug |
| Founder | Rohan Dixit (ex-Stanford / Harvard-MIT-MGH Martinos Center neuroscientist) |
| Launch | Token auction 9 Jan 2025; [BIO Incubator Cohort 2](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia) |
| Governance | [longcovidlabs.eth](https://snapshot.box/#/s:longcovidlabs.eth) on Snapshot — 6 proposals, most recent closed 7 Oct 2025 |
| Status | 🟢 Active |
| Website | [longcovidlabs.org](https://www.longcovidlabs.org) |

## Overview

[Long COVID Labs](https://www.longcovidlabs.org) (LCL) is a patient-led [decentralized-science](/wiki/desci/what-is-desci) organization building an on-chain platform to find and deliver treatments for [Long COVID](https://www.longcovidlabs.org/post/long-covid-labs-vision-paper) — which it calls "the fastest growing chronic health condition in human history." It was incubated through the [Bio Protocol](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia) launchpad as part of BIO Incubator Cohort 2, alongside [Curetopia](/wiki/desci/ecosystem/curetopia) and [Quantum Biology DAO](/wiki/desci/ecosystem/quantum-biology-dao).

LCL was founded by [Rohan Dixit](https://www.bio.xyz/blog-posts/long-covid-labs-is-accelerating-a-cure-onchain), a former neuroscientist at Stanford and the Harvard-MIT-MGH Martinos Center who contracted Long COVID after a mild 2020 infection and spent 2.5 years self-experimenting with therapies before co-founding the DAO. That origin shapes its defining feature: patients are treated as first-class stakeholders, not subjects — an inversion of a system where, in LCL's framing, "patients are excluded from decisions about their own care."

Where earlier BioDAOs such as [VitaDAO](/wiki/desci/ecosystem/vitadao) organize around funding research and tokenizing its [IP-NFTs](/wiki/desci/ecosystem/molecule), Long COVID Labs is structured as a **therapeutics platform** — its aim is to run trials and get treatments to patients directly, not only to fund upstream science.

## The Long COVID problem

Long COVID affects roughly [100 million people globally](https://www.longcovidlabs.org/post/long-covid-labs-vision-paper) and imposes an estimated **$1 trillion per year** in economic burden, per LCL's vision paper. The paper cites evidence that a single COVID infection is associated with an approximate 3–9 point IQ loss and may accelerate early-onset dementia — framing the condition as both a mass-scale and fast-growing chronic illness that traditional grant-and-trial pipelines are too slow to address.

LCL's thesis is that this mismatch — enormous, urgent patient demand versus a five-to-ten-year academic and regulatory timeline — is exactly the coordination failure a DAO can attack, by pooling patient data, community capital, and researcher effort in one incentive system.

## The $COVID token and governance

Long COVID Labs is a decentralized autonomous organization [wrapped in a Swiss non-profit](https://www.longcovidlabs.org/post/long-covid-labs-vision-paper) and coordinated by the **$COVID** governance token. Of a 1 billion fixed supply — confirmed on Ethereum mainnet by [the token contract's own `totalSupply()`](https://eth.blockscout.com/token/0xC85f5Dd5880D5162fAf5FdB24D40845B7C8F976F), which returns exactly 1e9 — the vision paper allocates:

| Allocation | Share | Terms |
| --- | --- | --- |
| Treasury reserves | 45% | unvested, DAO-controlled |
| Core team | 20% | 4-year vest, 1-year cliff |
| Community auction | 15% | 9 Jan 2025 sale, no vesting |
| Patients | 10% | for trial participation & data |
| Service provider ([BIO](/wiki/desci/ecosystem/bio-xyz)) | 7% | unvested |
| Ecosystem incentives | 3% | — |

The token grants **voting rights only** — holders "do not receive any form of dividend or other revenue rights." Patients themselves hold a dedicated 10% of supply, giving the people who contribute clinical data a durable governance voice over research priorities.

The process is set out in the DAO's own first proposal, [LCL DP-1](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x7cefbd56122cb21bc08a8aba952d35c31bc800a9e2f0e31c55d0ffc42e0d483e), and it is two phases rather than the three a reader might expect. Phase 1 is **four days of informal governance in the public Telegram channel** (`t.me/longcovidlabs`, in the `#Governance` topic, the whole proposal in a single post); it advances only if it collects at least ten 👍 reactions _including at least one from a named core-team member_. Phase 2 is a **three-day binding token vote on [Snapshot](https://snapshot.box/#/s:longcovidlabs.eth)**, one token one vote. DP-1 describes the model as "tokenocratic voting." The [longcovidlabs.eth](https://snapshot.box/#/s:longcovidlabs.eth) space was created 30 January 2025 and counts weight through two [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) `erc20-balance-of` strategies — the liquid $COVID token and a separate vested `vCOVID` contract — so unvested contributor allocations vote alongside circulating supply.

## The executed governance record

Six proposals have gone to a binding vote, all of them in 2025. Read in order they are a single story: a DAO asking its holders three times whether its own token should be tradable.

| Proposal | Closed | Voters | Outcome |
| --- | --- | --- | --- |
| [DP-1](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x7cefbd56122cb21bc08a8aba952d35c31bc800a9e2f0e31c55d0ffc42e0d483e) — governance framework | 8 Feb 2025 | 12 | Passed, 4,162,116 for / 286,078 against |
| [DP-2](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x0200d5b54871d098c607821a4089b3a7c80d102493b43b247af3f6f633a524f1) — transferability & liquidity | 22 Feb 2025 | 45 | **Rejected**, 8,889,203 for / 27,877,130 against |
| [DP-3](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x774609c40ec5b117ec6841f1608d4dbbd7547a60ad6fe213eeda4be5d8fadddd) — transferability re-vote | 22 Jun 2025 | 46 | **Delay** 69,700,473 / Enable now 7,071,203 |
| [DP-4](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0xff4d7c161937b5c78ef6700c5927cecbedfdd0d76a070fae342abe3310db03fc) — contributor allocation framework | 14 Aug 2025 | 11 | Passed, 71,405,569 for / 393,315 against |
| [DP-5](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x36dab178862acf006ffbf308973caa409ce6051a46840cf2050ab8834b9880b0) — annual budget | 14 Aug 2025 | 9 | Passed, 70,302,320 for / 0 against |
| [DP-6](https://snapshot.box/#/s:longcovidlabs.eth/proposal/0x8ddf514864948045bf156468e9d3ec1e223771912a04e03e4c7b5bc81ed434e6) — Token Generation Event | 7 Oct 2025 | 15 | Passed, 4,469,685 for / 1,002,954 against |

DP-2 asked holders to lift the transfer restriction, allocate 3% of supply plus matching treasury ETH to liquidity, and open an ETH/COVID pool. It drew the largest turnout in the DAO's history — 45 voters — and **lost by better than three to one**. Four months later DP-3 put the question again as a binary, with the core team arguing openly for the "no" side: it recommended delay on the grounds that "the core fundamentals (clinical traction and token utility) are not yet in place," and offered holders who wanted out a voluntary peer-to-peer OTC match at the original auction price — explicitly "not a buyback, refund, or liquidity program." Delay won with 90.8% of weight cast.

DP-4 and DP-5 opened the same day in August 2025 and show the concentration underneath those turnout figures. DP-4 set a standardized contributor allocation band of 0.01%–5% of supply on a 4-year vest with a 1-year cliff; DP-5 approved a $1,125,000 twelve-month budget itemised across five lines — $375,000 for an open-source treatment registry, $250,000 for research and evidence acceleration, $250,000 for biomarker development, $150,000 for marketing and growth, and $100,000 for a patient grant fund. Both passed with roughly 71 million tokens of weight cast by **eleven and nine addresses respectively**. The pattern — a ratified budget standing in for continuous votes — is the one described at [bootstrap budgets and ratification votes](/wiki/dao-governance/concepts/treasury/bootstrap-budgets-and-ratification-votes).

DP-6 then authorized the Token Generation Event: launch on Ethereum mainnet on 20 November 2025 in connection with Devconnect, a $COVID/ETH Uniswap v3 pool "at a 0.3% fee tier" funded with $150,000 of treasury ETH plus matching tokens, and — the clause that ended the sequence — authority for the treasury multisig "to pursue additional listings on other DEXs and CEXs without requiring new governance proposals."

## What the chain says happened next

The TGE executed, one day later than the date in the proposal. The live venue is a Uniswap v3 pool at [0x4Ba530…041d3f](https://eth.blockscout.com/address/0x4Ba530E8BBA1BCFD34eb9ab46d9B8ec3a4041d3f), [created at block 23,848,831 on 21 November 2025](https://eth.blockscout.com/tx/0xc45e8db911099479328fc17e83836107ad31e36b9f50ffb6a44681cddb4737fe) by an `execTransaction` on the treasury Safe at `0xab7ca711…c736316` — which is also one of the five addresses listed as administrators of the DAO's Snapshot space. The token's `transfersEnabled()` getter now returns true, and Blockscout counts **18,587 transfers across 293 holders** as of 12 August 2026.

Two details do not match the text holders approved. The pool that exists sits at the **1% fee tier**, not the 0.3% tier DP-6 named — Uniswap's v3 factory returns the zero address for the 0.01%, 0.05% and 0.3% COVID/WETH pools, and there is no Uniswap v2 pair. That is a change of venue parameters rather than a breach: it is precisely the discretion DP-6's final clause granted the multisig. But it is only visible on-chain, because **no proposal has been put to a vote since 7 October 2025** — the DAO's governance record stops at the proposal that authorized it to stop needing one.

The operating programme, meanwhile, is visibly running. LCL's own news index leads with an [FDA-compliant patient registry now open](https://www.longcovidlabs.org/post/patient-registry-long-covid), a [$100,000 patient grant fund taking applications](https://www.longcovidlabs.org/post/patient-grant-fund), a [$22,000 grant to Dr. Michael Peluso](https://www.longcovidlabs.org/post/spike-protein-blood) to study SARS-CoV-2 spike protein persistence in blood, and an [AI tool analysing the Long COVID patient conversation](https://www.longcovidlabs.org/post/ai-social-media). Three of those four map directly onto DP-5's budget lines. What LCL demonstrates is not a dormant DAO but a **decoupled one**: the treasury executes the mandate it was given, and the vote is what granted the mandate rather than what steers it.

## The Adaptive Trial Engine

LCL's core technical bet is an **Adaptive Trial Engine**: instead of a handful of large, sequential trials, the platform is designed to run [thousands of small adaptive clinical trials in parallel](https://www.longcovidlabs.org/post/long-covid-labs-vision-paper), using Bayesian inference to continuously update each treatment's success probability as patient data streams in, and machine learning to reallocate participants toward the arms that are working.

The vision paper's roadmap phases this in: DAO establishment plus initial drug-repurposing studies (Q1 2025), the parallel adaptive-trial platform for antivirals and immune modulators (Q4 2025), scaling to dozens of trials and thousands of participants (Q3 2026), and permanent decentralized-research infrastructure beyond. LCL's [first treatment candidate](https://www.bio.xyz/blog-posts/long-covid-labs-is-accelerating-a-cure-onchain) combines a long-acting monoclonal antibody with a viral-replication inhibitor, and its near-term strategy repurposes existing therapies such as Pemgarda and Paxlovid while contributors from Stanford, Mt. Sinai, and UCSF develop novel treatments. The registry and the patient grant fund are the parts of that roadmap with dated, first-party evidence behind them; the parallel-trial platform itself has no comparable public milestone.

## Data, patients and IP

The model turns patient [data contribution](/wiki/desci/ecosystem/researchhub) into governance stake: patients supply structured trial and real-world data, earn $COVID, and shape which treatments get prioritized — a concrete example of the [research-data-ownership](/wiki/desci/research-data-ownership) thesis that the people who generate biomedical data should share in its value.

On commercialization, LCL describes three IP pathways: licensing university-lab discoveries, licensing existing pharmaceutical IP for Long COVID re-purposing, and sponsoring internal research the DAO owns outright. In each case the stated intent is a "virtuous cycle" — profits from any resulting therapy flow back into the treasury and are reinvested into further research, rather than accruing solely to outside shareholders.

## Place in the Bio Protocol ecosystem

Long COVID Labs sits in the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) (bio.xyz) portfolio alongside [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity), [AthenaDAO](/wiki/desci/ecosystem/athenadao) (women's health), [Cerebrum DAO](/wiki/desci/ecosystem/cerebrum-dao) (brain health), [CryoDAO](/wiki/desci/ecosystem/cryodao) (cryopreservation) and [Curetopia](/wiki/desci/ecosystem/curetopia) (rare disease). During its [January 2025 auction](https://x.com/bioprotocol/status/1876642807475310717), LCL distributed 1% of supply to $BIO holders who participated with ETH — the launchpad's standard curation-and-alignment mechanism.

Its distinguishing move within that set is the therapeutics-platform posture: most BioDAOs fund and tokenize research; LCL is trying to own the trial-to-treatment loop for a single, very large indication.

## How Caper approaches this

Long COVID Labs spent eight months and three votes on a question [Caper](/wiki/foundations/what-is-a-caper) never puts to a vote. A caper's governance token is minted once at creation with **no mint or burn roles at all** and no transfer restriction, and it trades on its [bonding curve](/wiki/markets/bonding-curve) from the first block — there is no transfer switch to flip, no liquidity proposal to lose, and no treasury ETH to pair against it. [Raising funds](/wiki/markets/raising-funds) and enabling trading are the same act.

What _is_ restricted is the thing LCL's design leaves liquid. A caper mints a separate soulbound proof-of-vote token to each member who votes: only the caper's own component can deposit it, so it cannot be transferred between accounts, and a holder can withdraw it for exactly one purpose — to feed it back in on [exit](/wiki/markets/trading). A member's canonical vote weight is _w_ = (_t_ · _v_) / (_V_ · _T_), so holdings and accumulated votes are multiplicative factors: a large holder who has never voted carries zero weight, and so does a frequent voter holding nothing. Buying more still raises your weight — the point is that it is not sufficient on its own.

The other half of the LCL story is the harder one, and Caper answers it structurally rather than culturally. DP-6's mandate to act "without requiring new governance proposals" is what a DAO grants when the cost of a vote is high enough that governing continuously is impractical. In a caper the treasury has no discretionary path at all: every movement of value is a [typed proposal](/wiki/governance/proposals) that passed — _PAYOUT_, _INVEST_, _DIVEST_, _VOTE_, or (for $CAPER, executive-only) _UPGRADE_ — so there is no standing authorization for a multisig to exercise, because there is no multisig.

## Molecule

URL: https://caper.network/wiki/desci/ecosystem/molecule
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Type** | DeSci Infrastructure |
| **Founded** | 2020 |
| **Focus** | Tokenized research IP; on-chain research accounts |
| **Core primitive** | [Molecule Labs (V3)](https://docs.molecule.xyz/technical-deep-dive/onchain-lab) — LabNFT + one ERC-20 IP Token per Lab |
| **Legacy primitive** | [IP-NFT V2](/wiki/desci/ip-nfts) + Tokenizer (Ethereum, [marked UNMAINTAINED](https://docs.molecule.xyz/references/contracts)) |
| **Ecosystem token** | [BIO](https://www.bio.xyz/bio-token) (via Bio Protocol) |
| **Chain** | Base (Labs core, chain ID 8453); Ethereum Mainnet (legacy) |
| **Status** | 🟢 Active |
| **Website** | [molecule.xyz](https://www.molecule.xyz) |

## Overview

Molecule is the infrastructure layer of decentralized science, providing the [IP-NFT](/wiki/desci/ip-nfts) framework that underpins most biotech DAOs. The platform lets research communities [fund biomedical research and trade the resulting intellectual property on-chain](https://www.molecule.xyz), turning years of locked, illiquid scientific output into assets with price discovery and secondary markets.

Molecule's core innovation is attaching legal IP rights to an NFT, creating an asset class that a community can co-own and govern. The platform spans longevity, brain health, women's health, psychedelics, cell therapy and climate research, and is the tokenization engine behind the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO ecosystem.

## How IP-NFTs and IP Tokens work

An **IP-NFT** is a single non-fungible token that carries the legal rights to a research project — its data, licensing terms and any downstream commercial upside. Molecule's [open-source IP-NFT contracts](https://github.com/moleculeprotocol/IPNFT) reached V2 in 2024, standardizing this as reusable building blocks for the DeSci economy.

A single NFT is a poor governance and funding instrument, so Molecule added a **Tokenizer** contract that minted an ERC-20 [IP Token (IPT)](/wiki/desci/ip-nfts) against an IP-NFT. Fractionalizing the IP-NFT into IPTs distributed ownership across many holders, funded the research through their purchases, and let that group of holders collectively govern the asset as it moved through the R&D pipeline. IPTs can also gate access to proprietary data and route IP-licensing revenue back to holders.

This is the on-chain analogue of a cap table for a research program — a design that sits squarely inside the [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) question of how a token confers real economic and governance rights rather than pure speculation. In 2025 Molecule extended the model toward [bridging tokenized IP into the wider real-world-asset (RWA) market](https://www.molecule.to/blog/molecule-protocol-v2-bridging-the-future-of-decentralized-science-into-rwas).

### V3: the Lab replaces the IP-NFT

That first-generation stack is now history. Molecule's [contract index](https://docs.molecule.xyz/references/contracts) heads its Ethereum and Sepolia IPNFT sections “UNMAINTAINED” and lists the live deployment as “Molecule Labs core (v0.1.0)” on Base. The V3 primitive is a **Lab**: [“an NFT (ERC-721) that is permanently bound to its own smart contract wallet (ERC-6551)”](https://docs.molecule.xyz/technical-deep-dive/onchain-lab) with account abstraction (ERC-4337), installable modules (ERC-7579) and an attestation registry (ERC-7484) gating what can be installed. The research project is no longer a token pointing at an asset; it is an account that holds its own treasury, data anchor and licences, and transferring the LabNFT hands over the whole thing in one ERC-721 transfer.

Tokenization moved with it: the **OclTokenizer** [deploys one fractional ERC-20 IP Token per Lab, gated by a signed membership agreement](https://docs.molecule.xyz/references/contracts/tokenizer), each as an EIP-1167 clone with its own address. Molecule also documents a [Coin-to-Company module](https://docs.molecule.xyz/technical-deep-dive/rwa-equity) that states plainly that “Tokens are not equity” and routes holders who want shares through a lock-and-KYC path into ordinary off-chain share agreements. The full generational comparison is on the [IP-NFTs and IP Tokens](/wiki/desci/ip-nfts) page.

## IP as a treasury asset

For a science DAO, the tokenized IP is not a side product — it is the treasury's core holding. A [VitaDAO](/wiki/desci/ecosystem/vitadao) or [AthenaDAO](/wiki/desci/ecosystem/athenadao) funds a study, receives an IP-NFT, and that asset (plus any licensing income) is what the community stewards. This makes [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) for a DeSci DAO a question of managing a portfolio of illiquid, high-variance research bets rather than a stack of liquid tokens, and it is why the Molecule + [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) stack pairs IP tokenization with a launchpad and staking layer that keeps the community funding and curating the pipeline.

## Products

**Molecule Labs:** the platform at [labs.molecule.xyz](https://labs.molecule.xyz), where researchers create and manage Labs — the on-chain research accounts that hold a project's token, treasury and data room.

**Data rooms and access control:** research files are client-side encrypted and released against on-chain conditions, with roles and expiry resolved by the [AccessResolver](https://docs.molecule.xyz/technical-deep-dive/data/data-privacy-and-access) — the mechanism that lets a Lab grant a collaborator or an AI agent scoped, expiring access without handing over ownership.

**Documentation and contracts:** developer and concept guides at [docs.molecule.xyz](https://docs.molecule.xyz/), with the legacy IP-NFT contracts and subgraphs at [github.com/moleculeprotocol/IPNFT](https://github.com/moleculeprotocol/IPNFT).

**Pump.science:** Molecule founder/CEO Paul Kohlhaas also launched [Pump.science](/wiki/desci/ecosystem/pump-science), a Solana tokenized-experiment launchpad that funds longevity compound trials through freely tradeable tokens ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)) — the market-driven counterpart to Molecule's deliberative model.

## How Caper approaches this

Molecule solves the _asset_ side of DeSci — making research IP ownable and tradable. A [caper](/wiki/foundations/what-is-a-caper) addresses the _organization_ side: it folds the fundraise (a bonding-curve sale), the treasury, on-chain proposals (PAYOUT / INVEST / DIVEST / VOTE) and an always-available, participation-weighted pro-rata exit into one primitive. A research community could hold its Molecule IP-NFT inside a caper's treasury and let members fund, direct and exit the project through a single contract rather than stitching together a token sale, a multisig and a separate governance tool.

## External Links

- [Molecule — Official Platform](https://www.molecule.xyz)
- [Molecule Labs — create and manage a Lab](https://labs.molecule.xyz)
- [Molecule Documentation](https://docs.molecule.xyz/)
- [Molecule — deployed contracts (Base Labs core; legacy IPNFT marked UNMAINTAINED)](https://docs.molecule.xyz/references/contracts)
- [Molecule IP-NFT contracts on GitHub](https://github.com/moleculeprotocol/IPNFT)

## PeptAI (PEPTAI)

URL: https://caper.network/wiki/desci/ecosystem/peptai
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Name** | PeptAI — an autonomous peptide-discovery **BioAgent** on [Bio Protocol](https://www.bio.xyz/) |
| **Type** | AI research agent with its own token and treasury — not a member-run DAO |
| **Research focus** | Computationally designed peptide binders and agonists against protein targets, validated in a wet lab |
| **Token** | PEPTAI, launched on [Base, 14 May 2026](https://phemex.com/news/article/bio-protocol-launches-peptai-token-on-base-chain-with-ai-integration-81461) |
| **Funding route** | A Bio Protocol [Ignition Sale](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launcher) — a fixed-window USDC raise allocated by pledged BioXP |
| **Sale result** | [32x+ oversubscribed — 1.6M+ USDC from 1.4K+ participants](https://www.bio.xyz/blog-posts/bio-monthly-may-2026-peptai-ignition-sale-bio-on-robinhood-vebio-staker-rewards) |
| **Staker allocation** | 20% of supply to [veBIO stakers](https://www.bitget.com/amp/news/detail/12560605412339), 20% claimable at TGE and the rest vesting over six months |
| **Notable results** | OX2R-004, an ADHD-receptor peptide agonist designed in 24 hours (Apr 2026); [SPR-validated VEGFR2 binders](https://www.bio.xyz/blog-posts/bio-monthly-june-2026-openlabs-launch-desci-berlin-peptais-first-wet-lab-results) (Jun 2026). Pending: [four KISS1R / OX2R candidates sent to a wet lab](https://www.bio.xyz/blog-posts/bio-monthly-july-2026-the-white-house-backs-open-science-peptai-goes-to-the-lab-research-agents) (announced Aug 2026, no results yet) |
| **Primary sources** | [app.bio.xyz/agents/peptai](https://app.bio.xyz/agents/peptai) · [docs.bio.xyz](https://docs.bio.xyz/) · [Bio blog](https://www.bio.xyz/blog) |
| **Related** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) · [Molecule](/wiki/desci/ecosystem/molecule) · [VitaDAO](/wiki/desci/ecosystem/vitadao) · [What is DeSci](/wiki/desci/what-is-desci) |

## Overview

**PeptAI** is a _BioAgent_: an autonomous research agent launched on [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) that designs peptide drug candidates computationally, ranks them, and pushes the survivors into physical wet-lab testing. It has its own token, its own treasury, and its own public results feed — but no membership, no proposals and no voters. That makes it structurally unlike every other organisation in this directory, and it is the reason the page exists: PeptAI is the clearest live example of an emerging DeSci shape in which the _agent_, not a community, is the thing being funded.

Bio Protocol describes the agent as running designed candidates through [an eight-gate validation pipeline](https://app.bio.xyz/agents/peptai), publishing each result on-chain so the reasoning behind a candidate can be inspected before anyone spends money synthesising it. Only candidates that clear the gates are sent for synthesis and binding assays. The claim being tested is a narrow one — not that an agent can invent a drug, but that it can cut the cost and latency of the first screening step far enough to make small, community-scale research budgets go further.

## What it has actually produced

Two results are worth separating from the marketing around them, because both were reported with a target, a method and a cost.

- **OX2R-004 (April 2026).** A novel peptide agonist aimed at the orexin-2 receptor, a target of interest in ADHD and narcolepsy research, [designed in roughly 24 hours with an initial wet-lab validation cost of about $500–600](https://www.ainvest.com/news/bio-protocol-surges-bioxp-upgrade-ai-driven-desci-rotation-2605/). The number that matters there is not the 24 hours but the validation cost: it is small enough that a single failed hypothesis is not a budget event.
- **VEGFR2 binders (June 2026).** Agent-designed binders against [VEGFR2, a cancer-relevant receptor, confirmed by surface plasmon resonance](https://www.bio.xyz/blog-posts/bio-monthly-june-2026-openlabs-launch-desci-berlin-peptais-first-wet-lab-results) — PeptAI's first reported wet-lab confirmation. Bio reports the assay results being fed back into the next design cycle, which is the part that distinguishes this from a one-off screen.
- **KISS1R and OX2R candidates (announced 11 August 2026, not yet run).** PeptAI confirmed its next two programmes — KISS1R, a fertility target, and OX2R again, for ADHD and sleep — with its agents designing two lead peptides for each. Bio is explicit that the four candidates ["so far exist only as predictions on a computer"](https://www.bio.xyz/blog-posts/bio-monthly-july-2026-the-white-house-backs-open-science-peptai-goes-to-the-lab-research-agents) and are heading to a lab for the first time, to be synthesized and then tested on living cells carrying the target receptor for whether they switch it on, how strongly, and how selectively. Listed here as a pending experiment rather than a result, which is the distinction this page exists to keep.

Neither result is a drug. Both are early binding data, the stage at which the great majority of candidates fail, and neither has been independently replicated — the [reproducibility problem](/wiki/desci/reproducibility-crisis) that DeSci set out to address applies to agent-generated results exactly as it applies to human ones. What is genuinely new is that the hypotheses, the ranking and the outcomes are published on-chain rather than sitting in a private pipeline.

## How it was funded: the Ignition Sale

PeptAI did not raise from a token sale in the usual sense, nor from a DAO treasury vote. It was launched through Bio Protocol V2's **Launcher**, whose [Ignition Sale](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launcher) mechanism is worth understanding on its own terms, because it is a genuinely different answer to the raise-allocation problem than either a fixed-price sale or a [bonding curve](/wiki/markets/bonding-curve):

- The sale runs in USDC for a fixed window and must hit a stated raise goal to close at all. Miss it, and commitments are returned.
- Participants commit capital _and_ pledge **BioXP** — points earned by staking BIO or ecosystem tokens, which [expire roughly 14 days after they are earned](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launchpad-faq). Anyone can join with no BioXP at a floor weight.
- When a sale is oversubscribed, allocation is pro-rata to pledged BioXP, capped so no single wallet takes more than [0.5% of the tokens on offer](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launchpad-faq). Unused commitments and points are returned.
- On a successful close, the raised USDC is paired with tokens into a liquidity pool rather than being handed over as a lump sum.

PeptAI's sale closed [more than 32x oversubscribed, with over 1.6M USDC committed by more than 1,400 participants](https://www.bio.xyz/blog-posts/bio-monthly-may-2026-peptai-ignition-sale-bio-on-robinhood-vebio-staker-rewards); PEPTAI then listed on [Base on 14 May 2026](https://phemex.com/news/article/bio-protocol-launches-peptai-token-on-base-chain-with-ai-integration-81461). Twenty per cent of supply was routed to veBIO stakers, 20% of it claimable at TGE and the remainder vesting over six months, with early full claims forfeiting the unvested portion.

The design is deliberately anti-whale in the same family as the mechanisms catalogued under [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics): the scarce good is not capital but time-decaying, stake-earned priority. Whether that survives contact with capital at scale is an open question — points that can be minted by spending BIO are still, at the margin, purchasable.

## BioAgent or BioDAO? Why the distinction matters

Bio Protocol now launches [three asset types through the same Launcher](https://alearesearch.substack.com/p/bio-protocol-ai-native-desci-funding): IP tokens, BioDAOs and BioAgents. The first BioAgent, **Aubrai**, directs capital to longevity research; PeptAI is the one that has published wet-lab confirmation. In June 2026 Bio added [OpenLabs](https://cryptobriefing.com/bioprotocol-openlabs-desci-berlin/), a front end where an idea attracts contributors, agents draft the votes and progress summaries, bounties fund the work, and a project can graduate to the Launcher.

For anyone reading this wiki as a governance reference, the important thing is what a BioAgent token does _not_ obviously carry. A [VitaDAO](/wiki/desci/ecosystem/vitadao)-style BioDAO token is a membership claim: it votes on which research to fund and, through [Molecule](/wiki/desci/ecosystem/molecule)'s IP-NFT machinery, on what happens to the resulting intellectual property. Bio's public documentation for the Launcher and its [V2 FAQ](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launchpad-faq) sets out how allocation works in detail, but does not set out what governance rights an agent's token confers over the agent's treasury, its research direction, or the [data and IP it generates](/wiki/desci/research-data-ownership).

That gap is the substantive question, not a pedantic one. An agent has no equivalent of [low turnout](/wiki/dao-governance/concepts/analysis/voter-apathy), because there is no electorate to turn out; it also has no equivalent of a member forcing a decision. In a member DAO, holders who dislike the direction can vote, and failing that, leave. Where the funded entity is a model and a lab budget rather than a membership, "exit" reduces to selling on the open market at whatever price is there — which is the same dependency that shows up repeatedly in [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail). Progressive [governance minimisation](/wiki/dao-governance/concepts/fundamentals/governance-minimization) is a defensible destination for a protocol whose rules are settled; it is a harder argument for an entity whose entire job is to keep making discretionary calls about what to research next.

## How Caper approaches this

PeptAI is a useful contrast because it isolates one variable: what a funded community's token is actually a claim _on_. In a [caper](/wiki/foundations/what-is-a-caper), that claim is explicit in the contract. A member who wants out calls `exit`, hands back their governance tokens and their earned vote tokens together, and receives a proportional share of the treasury — no proposal, no vote, no counterparty. The share is computed as `(holdings × votes) / (vote supply × circulating supply)`, so it reflects both what a member put in and the participation they actually earned; the governance tokens are then sold back into the [bonding curve](/wiki/markets/bonding-curve) in the same transaction.

That is a narrower claim than "capers do science better" — they do not, and PeptAI's cost-per-hypothesis result is a real contribution this wiki has no equivalent for. The point is only that a member-funded research treasury can be built so that leaving is a contract call rather than a market order, and so that the right to leave does not depend on anyone else agreeing.

## External links

- [PeptAI on Bio Protocol — agent page](https://app.bio.xyz/agents/peptai)
- [Bio Monthly, June 2026 — OpenLabs launch and PeptAI's first wet-lab results](https://www.bio.xyz/blog-posts/bio-monthly-june-2026-openlabs-launch-desci-berlin-peptais-first-wet-lab-results)
- [Bio Monthly, May 2026 — the PeptAI Ignition Sale](https://www.bio.xyz/blog-posts/bio-monthly-may-2026-peptai-ignition-sale-bio-on-robinhood-vebio-staker-rewards)
- [Bio Protocol docs — Launcher and Ignition Sale mechanics](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launcher)
- [Bio Protocol docs — Bio V2 launchpad FAQ](https://docs.bio.xyz/bio/introduction/bio-protocol-v2/launchpad-faq)

## PsyDAO

URL: https://caper.network/wiki/desci/ecosystem/psydao
Updated: 2026-08-01
Verified: 2026-08-01

|  |  |
| --- | --- |
| **Type** | DeSci DAO |
| **Focus** | Psychedelic science & culture |
| **Raise** | ~$2M ($PSY token sale) |
| **Grants** | 6 awarded ($280k); Alchemist micro-grants (≤$2k) |
| **Governance** | Ostrom-inspired dual-token ($PSYC / $PSY) |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) |
| **Status** | Active — site reports a live node, grants and on-chain treasury |
| **Website** | [psydao.world](https://psydao.world) |

## Overview

PsyDAO is [a decentralized collective advancing psychedelic science through community-funded research and open intellectual property](https://psydao.world). It promotes progress via distributed coordination, crowdfunding, and collective ownership of IP so psychedelic medicine and knowledge stay accessible rather than enclosed. It sits within the broader [DeSci](/wiki/desci/what-is-desci) movement as one of the field's culture-and-science hybrids.

Governance uses an [Ostrom-inspired dual-token system](https://psydao.world): $PSYC holders steer research direction while $PSY functions as the wider ecosystem and membership token. The [$PSY sale raised roughly $2 million for psychedelic science](https://mirror.xyz/0x3ccF80a0f26ED8BC2E11d2a4e0813816048BCA38/zP8Adajzgf07b1Pl857gHGDv9DW93sKlSr6wBwrEiHA).

## Research & grants

PsyDAO has awarded six grants totalling about $280k across science, technology, and culture — spanning next-gen empathogen (MDMA-prodrug) optimization, endogenous-DMT research commons, a psychedelics-and-longevity comparison study, dissociative-drug development, a multi-agent AI research-discovery system, and token-incentivized open-science tooling. Alongside the larger grants it runs an Alchemist micro-grant track offering awards up to ~$2k to researchers, artists, and community builders.

Grant direction and treasury allocation are decided [on-chain by token holders](/wiki/governance/voting), and funded work is released toward an open-IP commons rather than locked behind patents.

## How Caper approaches this

PsyDAO's core loop — raise a community treasury, then let members vote grants out of it toward open science — is the exact shape a [caper](/wiki/foundations/what-is-a-caper) runs natively. On Caper, the raise happens on a [bonding curve](/wiki/markets/bonding-curve) into the caper's own treasury, each grant is a governance-approved [PAYOUT proposal](/wiki/governance/proposals) that moves a chosen amount to the grantee, and [voting weight is stake weighted by participation](/wiki/governance/voting-mechanisms) rather than split across two token classes. Members also keep a [pro-rata exit claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on the undeployed treasury — a built-in accountability lever a dual-token grants DAO usually has to design separately.

## External links

- [PsyDAO — official website](https://psydao.world)
- [$PSY raises $2M — PsyDAO on Mirror](https://mirror.xyz/0x3ccF80a0f26ED8BC2E11d2a4e0813816048BCA38/zP8Adajzgf07b1Pl857gHGDv9DW93sKlSr6wBwrEiHA)
- [PsyDAO writing — Paragraph (current publication)](https://paragraph.com/@psydao-2)
- [Bio Protocol ecosystem](https://www.bio.xyz)

## Pump.science (RIF, URO)

URL: https://caper.network/wiki/desci/ecosystem/pump-science
Updated: 2026-07-25

| Name | Pump.science (RIF, URO) |
| --- | --- |
| Type | Decentralized-science (DeSci) funding platform — a tokenized-experiment launchpad, not a token-voting DAO |
| Focus | Financing longevity / healthspan research by turning individual compounds into openly tradeable tokens whose market attention pays for real lab experiments |
| Chain | Solana |
| Tokens | $RIF (Rifampicin) and $URO (Urolithin A) — one token per compound under study |
| Launched | November 2024 (a spin-off of the pump.fun memecoin launchpad) |
| Backers | Founded by Paul Kohlhaas, founder/CEO of [Molecule](/wiki/desci/ecosystem/molecule) / [BIO Protocol](/wiki/desci/ecosystem/bio-xyz) |
| Lab partners | Ora Biomedical (WormBot, _C. elegans_) and Tracked Biotechnologies (FlyBox, fruit flies) |

## Overview

**Pump.science** is a Solana-based protocol that finances [decentralized-science](/wiki/desci/what-is-desci) research into longevity compounds by _gamifying_ the funding step. It is a spin-off of the memecoin launchpad [pump.fun](https://pump.fun): instead of launching a joke coin, a researcher launches a token that stands for a specific real-world compound, and the trading demand for that token pays for the compound to actually be tested in a lab ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)). It launched in November 2024 and its first two experiments, **$RIF** and **$URO**, briefly became two of the most-watched tokens in crypto, drawing wide attention to [DeSci](/wiki/desci/desci-daos) as a category.

Pump.science matters to a DAO reference because it is the sharpest live example of a funding model the rest of the field treats cautiously: **market speculation as the grant committee**. Where a research DAO like [VitaDAO](/wiki/desci/ecosystem/vitadao) deliberates over which projects to fund, Pump.science lets an open market decide by buying — and it wires that market directly to a bench experiment.

## How a compound becomes a tradeable experiment

The pipeline is deliberately simple. A compound is issued as a token on pump.fun's [bonding curve](/wiki/markets/bonding-curve). According to founder Paul Kohlhaas, once a compound's token crosses a **$10,000 market cap**, "the experiment data is deployed live on Pump Science" — the trading interest has cleared the (very low) bar to fund a real trial, and results then stream back against the token ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)). Because a single automated experiment costs on the order of **$300**, even a modest speculative market can bankroll a full run.

The result is a feedback loop unlike anything in traditional grant funding: attention becomes capital, capital becomes an experiment, and the experiment's data feeds back to the people holding the token. Its critics note the obvious hazard — the same loop rewards hype over rigor, and a compound's token price is not evidence about the compound.

## RIF and URO: the first two experiments

**$RIF** represents [rifampicin](https://en.wikipedia.org/wiki/Rifampicin), an antibiotic being screened for whether it slows aging in model organisms; **$URO** represents [urolithin A](https://en.wikipedia.org/wiki/Urolithin_A), a pomegranate-derived compound studied for cellular "clean-up" (mitophagy). Both launched in November 2024 and spiked violently — on 18 November 2024, RIF's token reached roughly a $227M market cap and URO around $112M, each up tens of thousands of percent over the prior week ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)).

Those valuations then fell sharply from their peaks, and the team said it would **focus on RIF and URO** — running mouse experiments before introducing any new compound tokens, and pausing further launches until security audits of the application and smart contracts were complete ([ChainCatcher](https://www.chaincatcher.com/en/article/2154094)). The episode is now a standard case study in how a gamified funding mechanism can pull enormous capital and attention into obscure geroscience overnight — and how quickly that attention leaves.

## The lab layer: WormBot and FlyBox

What separates Pump.science from a pure memecoin is that the experiments are real and outsourced to specialist labs. Compounds are screened in worms (_C. elegans_) at **Ora Biomedical** on its **WormBot**, and in fruit flies at **Tracked Biotechnologies** on its **FlyBox** ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)). Ora Biomedical describes the WormBot as "a high-throughput robotics platform combined with neural net AI to perform high-throughput health and survival analysis in worms," feeding a broader effort to screen compounds for lifespan extension at scale ([Ora Biomedical](https://orabiomedical.com/science/)).

This layer is why holders receive something other than price action: standardized survival-curve data on the compound their token names. It is also the honest limit of the model — worm and fly lifespan screens are early, exploratory signals, several translational steps removed from a human longevity claim.

## Tokens, IP rights, and the BIO connection

Pump.science's tokens are pitched as more than speculation: they "represent real-world [intellectual property](/wiki/desci/ip-nfts) governance rights to the underlying compounds' data and to the experiments being traded" ([Unchained](https://unchainedcrypto.com/decentralized-science-jumps-54-led-by-vitadao-as-well-as-pump-sciences-rif-and-uro/)). That threads the platform into the wider [Molecule](/wiki/desci/ecosystem/molecule) / [BIO Protocol](/wiki/desci/ecosystem/bio-xyz) ecosystem, since founder Paul Kohlhaas leads both. On 25 December 2024, BIO Protocol announced it would airdrop **50 million BIO** tokens proportionally to existing RIF and URO holders, pending governance approval to bridge BIO to Solana ([Bitget News](https://www.bitget.com/news/detail/12560604452292)).

So the token a speculator buys nominally carries a claim on a research asset — a design that borrows the [IP-NFT](/wiki/desci/ip-nfts) logic Molecule pioneered for [VitaDAO](/wiki/desci/ecosystem/vitadao), but delivers it through a freely tradeable, meme-launchpad token rather than a deliberative DAO treasury.

## Is Pump.science a DAO?

Not in the token-voting sense, and this reference says so plainly — much as it does for [ResearchHub](/wiki/desci/ecosystem/researchhub). Pump.science is a **funding platform and market**, not a governed organization: there is no proposal-and-vote treasury steering the protocol, and the decisive mechanism is a price crossing a threshold, not a member vote. Its tokens confer nominal IP-governance rights over specific experiments, but "which compound gets funded" is decided by open-market buying, not by governance.

It earns a place in the DAO-industry directory precisely as the boundary case: the point where [DeSci funding](/wiki/desci/desci-funding) stops looking like a DAO and starts looking like a prediction-and-speculation market wired to a lab bench. That makes it the most useful contrast in the [BioDAO](/wiki/desci/desci-daos) set for thinking about who should actually control community-funded research.

## How Caper approaches this

Pump.science and [Caper](/wiki/foundations/what-is-a-caper) sit at opposite poles of one question: how much of a community-funded effort's steering should be _for sale_. Pump.science makes almost all of it tradeable — a compound gets funded when its freely transferable token clears a market-cap bar, so buying pressure is the allocation mechanism. Caper deliberately removes the decisive slice from the market: voting on a caper mints a _soulbound, non-transferable_ proof-of-vote token (indivisible, and locked to its holder — its deposit authority is the component itself, with updates permanently denied, per `contracts/core/src/caper_dao.rs`). A member's on-chain weight is `compute_vote_weight = (t·v)/(V·T)` in `contracts/logic/src/lib.rs` — their token holdings _times_ their earned votes, over the totals — and that same weight sets each member's [exit](/wiki/governance/proposals) redemption before the vote tokens are burned.

The honest read is that each optimizes for something real. Pump.science maximizes liquid, permissionless attention — its whole thesis is that an open market can fund obscure science faster than any committee. Caper's earned, un-sellable weight is built for the opposite case: when you specifically do not want who-decides to be purchasable, and you want the people steering to be the ones who can't simply cash out of the consequences.

## Quantum Biology DAO

URL: https://caper.network/wiki/desci/ecosystem/quantum-biology-dao
Updated: 2026-08-10

| Name | Quantum Biology DAO |
| --- | --- |
| Type | Decentralized-science (DeSci) BioDAO — foundational research + scientific instrumentation |
| Focus | Quantum biology: the physics of weak magnetic-field effects on living cells (oxidation, repair, division rates) |
| Token | $QBIO (governance & funding — no equity or revenue rights). [Ethereum ERC-20](https://etherscan.io/token/0x3E6A1b21bd267677Fa49BE6425aEbe2fc0f89bDE), supply 404,185,232; plus [vQBIO](https://etherscan.io/token/0x637b118738CCF4146e6679ff620FdDF30a6f0868) (vesting), supply 150,000,000 |
| Chain | Ethereum (governance). [Bridged to Solana](https://solscan.io/token/qbioCGDnUBGX5qcK1Fc4zg19GaQEPmxHFMPMZQm4LZ8) since March 2025 — 25.8M QBIO wrapped, no vote attached |
| Governance | [Snapshot `qbio.eth`](https://snapshot.box/#/s:qbio.eth) — 28 proposals, 34 followers, quorum 13,500,000 QBIO |
| DAO co-founders | Clarice Aiello (CSO) & Geoff Anders (CEO) |
| Institute officers (2026) | Todd Thaxton (CEO), Alessandro Lodesani (COO), Clarice Aiello (Chair of the Board & President of the Scientific Advisory Board) |
| Launchpad | [BIO Protocol](https://app.bio.xyz/launchpad/Quantum%20Biology%20DAO) (bio.xyz) — Incubator Cohort 2 |
| Notable | Building a quantum microscope with the Quantum Biology Institute; TGE January 2025; [$1.2M grant to the Institute](https://www.quantumbiology.eco/blog/quantum-biology-institute-receives-1-2-million-grant-to-advance-research-in-quantum-biology) announced April 2026 |
| Status | 🟢 Active |
| Website | [quantumbiology.xyz](https://www.quantumbiology.xyz/) · [blog](https://www.quantumbiology.eco/blog) · [Institute](https://www.quantumbiology.org/) · [Incubator](https://quantumbiology.inc/) |

## Overview

Quantum Biology DAO is a [BioDAO](/wiki/desci/desci-daos) funding a corner of science most drug-focused DeSci projects never touch: **quantum biology**, the study of how quantum-mechanical effects — coherence, entanglement, spin — shape processes inside living cells. Where [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity), [CryoDAO](/wiki/desci/ecosystem/cryodao) (biostasis), and [Curetopia](/wiki/desci/ecosystem/curetopia) (rare disease) each organise around a _therapeutic_ goal, Quantum Biology DAO organises around a _physical_ question and the instrument needed to answer it. It [launched publicly in October 2024](https://www.quantumbiology.eco/blog/quantum-biology-dao-launches) out of research originally based at UCLA, and is part of the [BIO Protocol](https://docs.bio.xyz/bio/introduction/concepts/biodaos) (bio.xyz) network of decentralized-science DAOs.

The DAO was [admitted to the BIO Incubator's second cohort](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia) on 17 October 2024, alongside [Long COVID Labs](/wiki/desci/ecosystem/long-covid-labs) and [Curetopia](/wiki/desci/ecosystem/curetopia) — the three early admissions that seeded Cohort 2.

The organisation is really **three bodies under one brand**, and keeping them apart is necessary to read anything about it accurately: the **DAO** (token, treasury, votes) at quantumbiology.xyz; the **Quantum Biology Institute**, a US non-profit that employs the scientists and runs the labs, at quantumbiology.org; and the **Quantum Biology Incubator**, a Delaware C-corporation [chartered to spin quantum-biology research into companies](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia), at quantumbiology.inc. The DAO does not do science. It votes on money that the Institute spends, and the split shows up in the record below: the two halves have kept very different rhythms.

## The science: weak magnetic fields and living cells

Quantum biology asks whether biological systems exploit quantum effects that survive the warm, wet, noisy interior of a cell — long assumed too chaotic to preserve quantum states. The DAO's stated aim is to [understand the physics behind weak magnetic-field effects](https://www.quantumbiology.eco/blog/quantum-biology-dao-launches) so that cellular processes can be deliberately influenced: the team names **oxidation rates, cellular repair, and cell-division rates** as targets. If weak, precisely-tuned magnetic fields can nudge these processes, the applications span health and longevity, biomanufacturing, and drug discovery.

This is deliberately upstream, high-risk basic science — the kind that struggles for grant funding precisely because it questions a settled assumption. That funding gap is exactly the [problem DeSci exists to attack](/wiki/desci/what-is-desci).

## The inaugural result, and what it actually claims

Most BioDAO pages in this directory describe a research programme. This one has a published dataset to point at, which makes it unusually easy to check. The Institute's first result is a preprint posted to bioRxiv on 13 October 2024 and revised on 16 October: [_Weak magnetic field effects in biology are measurable — accelerated Xenopus embryogenesis in the absence of the geomagnetic field_](https://www.biorxiv.org/content/10.1101/2024.10.10.617626v2) (doi 10.1101/2024.10.10.617626), by A. Lodesani, G. Anders, L. Bougas, T. Lins, D. Budker, P. Fierlinger and C. D. Aiello, with Aiello corresponding for the Quantum Biology Institute. Two of the authors are the DAO's own principals: Anders is its CEO, Lodesani is now the Institute's COO.

The claim is narrower than the headline. The authors report that _Xenopus laevis_ embryos develop measurably faster inside an engineered hypomagnetic enclosure of **less than 1 nT** than in Earth's ambient field of roughly **50 µT**, with effects visible from one day post-fertilization, and they explicitly note that **no definitive biophysical mechanism** accounts for it — the quantum explanation is the one they favour, not the one they demonstrate. The stated purpose of the experiment is to settle the _reality_ of the effect, not its cause.

The open-science claim holds up on inspection. All data and analysis code sit in a public MIT-licensed repository, [Quantum-Biology-Institute/Weak-magnetic-field-effects-in-biology-are-measurable](https://github.com/Quantum-Biology-Institute/Weak-magnetic-field-effects-in-biology-are-measurable), created 18 September 2024 and last pushed 11 October 2024, and the preprint is CC-BY. What has _not_ happened is peer review: bioRxiv's own record still lists no journal publication for the preprint, roughly twenty-two months after v2. For a DAO whose pitch is that community capital can fund science conventional funders skip, the gap between a released dataset and a reviewed paper is the part of the thesis still outstanding — a general point taken up in [DeSci funding](/wiki/desci/desci-funding).

## The quantum microscope and the Institute's lab work

The DAO's flagship project is a **quantum microscope** — an instrument built [to observe quantum phenomena happening in real time](https://www.quantumbiology.eco/blog/quantum-biology-dao-launches) inside living cells, developed in partnership with the [Quantum Biology Institute](https://www.quantumbiology.org/), a US non-profit. Building the tool is the point: much of quantum biology has been stuck on the lack of instruments that can measure quantum states in a biological sample without destroying them. Funding an instrument rather than a molecule makes Quantum Biology DAO structurally distinct from every IP-NFT-based BioDAO in this directory, which fund a [research asset](/wiki/desci/ip-nfts) that resolves to intellectual property.

The underlying research raised roughly [$3M in its first three years](https://www.bio.xyz/blog-posts/bio-incubator-cohort-2-early-admissions-long-covid-labs-quantum-biology-dao-curetopia) from government and private sources at UCLA before moving into the DAO structure. The Institute now runs its own labs from a Los Angeles headquarters, and in April 2025 announced a research partnership with the [J. Craig Venter Institute](https://www.quantumbiology.eco/blog/j-craig-venter-institute-x-quantum-biology-institute-collaboration) to study how microbial model organisms respond to weak magnetic fields, using JCVI's genomics and multiomics capability. Its funding case is that the shielded enclosures and spectroscopic tools it is building will be [shared experimental infrastructure available to researchers across institutions](https://www.quantumbiology.eco/blog/quantum-biology-institute-receives-1-2-million-grant-to-advance-research-in-quantum-biology) rather than a private asset — which is the specific reason a non-profit, not the Incubator, receives the DAO's grant money.

## People

Quantum Biology DAO is co-founded by [Clarice Aiello (Chief Scientific Officer) and Geoff Anders (Chief Executive Officer)](https://www.quantumbiology.eco/blog/quantum-biology-dao-launches). Aiello is a physicist who led the quantum-biology research group at UCLA; Anders founded the research organisation Leverage. Naming a credentialed principal investigator, rather than pseudonymous stewards, is characteristic of the [bio.xyz BioDAO model](https://docs.bio.xyz/bio/introduction/concepts/biodaos), where a real lab sits behind the token.

The Institute has since built out a separate officer team, and the two sets of titles are easy to conflate. As of the April 2026 grant announcement, the [Institute's CEO is Todd Thaxton and its COO is Alessandro Lodesani](https://www.quantumbiology.eco/blog/quantum-biology-institute-receives-1-2-million-grant-to-advance-research-in-quantum-biology), with **Aiello as Chair of the Board and President of the Scientific Advisory Board** rather than in an executive role; Brian Ross is named as a research scientist working in the Institute's molecular biology lab. Aiello remains the public face of the science — she is scheduled to speak on the evidence-based longevity panel at [SynBioBeta 2026 in San Jose](https://www.quantumbiology.eco/blog/clarice-aiello-to-speak-at-synbiobeta-2026) on 7 May 2026.

## The $QBIO token

Quantum Biology DAO held its token generation event in [January 2025 on the BIO Protocol launchpad](https://app.bio.xyz/launchpad/Quantum%20Biology%20DAO) — the [QBIO/WETH auction (#560)](https://auctions.bio.xyz/auction/560). $QBIO is a **governance and funding token, not equity**: like other bio.xyz BioDAOs it carries the right to vote on research direction and grant allocation, curated by [$BIO holders](https://docs.bio.xyz/bio/introduction/concepts/biodaos) who stake into and co-own the BioDAO through the launchpad.

Read on-chain, the token is two contracts rather than one. [QBIO](https://etherscan.io/token/0x3E6A1b21bd267677Fa49BE6425aEbe2fc0f89bDE) (`0x3E6A…9bDE`, 18 decimals) reports a total supply of **404,185,232**. Alongside it sits [vQBIO, the “QBIO Vesting Token”](https://etherscan.io/token/0x637b118738CCF4146e6679ff620FdDF30a6f0868) (`0x637b…0868`), supply **150,000,000** — a separate, non-tradable claim representing locked allocations. Both are counted for governance, which matters enormously and is taken up in the next section.

**The Solana leg does not vote.** Following an on-chain vote in January 2025, QBIO was [bridged to Solana in March 2025](https://www.quantumbiology.eco/blog/qbio-is-live-on-solana) via Portal Bridge, tradable on Raydium, with the DAO citing access and liquidity. The wrapped mint `qbioCGDn…m4LZ8` [currently holds 25,795,697 QBIO](https://solscan.io/token/qbioCGDnUBGX5qcK1Fc4zg19GaQEPmxHFMPMZQm4LZ8), about 6.4% of the Ethereum supply. But both of the DAO's Snapshot voting strategies are `erc20-balance-of` calls against **Ethereum** contracts, so a holder who bridges to Solana keeps the asset and silently loses the franchise. Nothing announces this at the bridge. It is a clean, checkable instance of a general problem catalogued under [DAO metrics and analytics](/wiki/dao-governance/concepts/analysis/dao-metrics-and-analytics): a token's circulating supply and its _votable_ supply are not the same number, and multi-chain expansion widens the gap.

## The governance record

Quantum Biology DAO votes on [Snapshot, in the `qbio.eth` space](https://snapshot.box/#/s:qbio.eth): 28 proposals, 34 followers, quorum 13,500,000 QBIO. The whole record is public, and read end to end it is one of the more legible small-DAO case studies available — a complete arc from launch enthusiasm to a working oligarchy, in nineteen months.

**Turnout collapsed while voting power rose.** The first three proposals, in January 2025, drew **46, 44 and 37 voters** and decided 23.1, 25.7 and 16.6 million QBIO of voting power. Across the ten proposals held in 2026, the median turnout is **10 voters** and the low is 6 — against 34 space followers — while voting power per proposal has typically run 50 to 210 million. Both movements have the same cause: the retail cohort stopped showing up, and the large holders did not. This is the standard shape described in [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy), visible here at a scale small enough to count wallet by wallet.

**Three wallets hold every vesting token, and all three run the space.** Reading `balanceOf` on the vQBIO contract: the entire 150,000,000 vQBIO supply sits in exactly three addresses at **50,000,000 each** — `0x47ed3d53…`, `0x25e34eff…` and `0x9f1d91ed…` — and all three appear in the [space's list of four administrators](https://snapshot.box/#/s:qbio.eth). Their _liquid_ QBIO holdings are 200,001, 63,949 and 0 tokens respectively. Because Snapshot counts vQBIO at parity with QBIO, those three wallets carry **27.1%** of the 554,185,232-token voting base on the strength of tokens they cannot sell. That is the inverse of what a vesting schedule is normally sold as doing: rather than deferring influence until a lock-up proves commitment, it grants full influence immediately and defers only the ability to exit. The general mechanism is covered in [token unlocks and vesting schedules](/wiki/economics/token-unlocks-and-vesting).

**The one defeat was the budget, and the budget passed anyway.** Of 28 proposals, exactly one failed to carry: [DP-23, the Annual 2026 Budget](https://snapshot.box/#/s:qbio.eth/proposal/0x10d996fc8428d52a0419856d119909077795a660da860f48238acfb846ec4ead), on 20 February 2026, rejected 152,776,435 against to 56,771,107 for. It also drew the highest turnout since launch week — 17 voters — and split the administrators: `0x47ed3d53…` voted for, `0x25e34eff…` against. Every one of the ten smallest voters backed it, contributing 348,896 votes between them, or 0.17% of everything cast. Over the four months that followed, the DAO passed the same budget in pieces: a Media Director in April, an [Operations Budget in May](https://snapshot.box/#/s:qbio.eth), a [Communications Budget in May](https://snapshot.box/#/s:qbio.eth/proposal/0x9f5d41129649b1c3b452919354a5774cf6601f685c3787f652d5d9d40d35f344), and a Comms/Events/Other Budget on 30 June — each unanimous, each on 6 to 11 voters. An omnibus that lost a contested vote became four line items that won uncontested ones.

**Quorum is arithmetic, not a guarantee.** Proposals before late May 2025 carry a quorum of 1 (the first, 0); the 13,500,000 threshold appears from DP-19 onward. That threshold is 2.4% of the combined QBIO + vQBIO voting base — and it is not what actually gates outcomes, because any single one of the three vesting wallets clears it more than three times over on its own. When they sit out, the arithmetic is stark: [DP-29, the 2026 Communications Budget](https://snapshot.box/#/s:qbio.eth/proposal/0x9f5d41129649b1c3b452919354a5774cf6601f685c3787f652d5d9d40d35f344), closed on 6 voters and **404,104** votes, or **3.0% of the stated quorum** and 0.07% of the voting base, with a single wallet supplying 68.6% of it. A fixed-constant quorum set against a supply the constant does not track is a recurring design fault, not a local one.

**The DAO has started formalising the concentration.** On 11 June 2026 it passed [DP-30, “Establish Large Token Holder Council”](https://snapshot.box/#/s:qbio.eth/proposal/0x34f5c9932ee2140e9ee4a1f2e84b18a36d9761731a975127678071ca5856dc4b) — 8 voters, 100,629,242 for, 50,214 against — and, on the same day with the same 8 voters, a Transparency and Reporting Measures proposal. Read together, the two are an honest read of the situation by the people in it: with turnout in single digits and three admin wallets holding a quarter of the votable supply, the DAO chose to name its large-holder body rather than pretend the general vote was deciding things.

**Both halves paused, and both restarted.** No proposal was posted between 5 August 2025 and 20 February 2026, a gap of six and a half months, and the ecosystem newsroom ran silent over almost exactly the same window (23 June 2025 to 21 April 2026). Governance then resumed at a steady clip — ten proposals between February and June 2026 — and the funded science continued regardless: the vote on [DP-25, a six-month grant to the Institute](https://snapshot.box/#/s:qbio.eth/proposal/0x527d2b23b50c6fbdc0259e43b0e7b6eacbc1c686c4e38644df1f14bb0eb28fc4) carried on 16 April 2026 with 14 voters, and five days later the newsroom announced the [$1.2 million grant](https://www.quantumbiology.eco/blog/quantum-biology-institute-receives-1-2-million-grant-to-advance-research-in-quantum-biology). On that vote, four wallets — the three vesting holders plus one 26.3-million-token address — supplied **99.8%** of the voting power; the other ten voters supplied 0.2%. Two numbers in the proposal sequence, DP-18 and DP-22, have no Snapshot proposal at all, and the [technical roadmap](https://www.quantumbiology.eco/roadmap) still reads “Version 1.0 | Latest update: 13 October 2024”.

## Working groups

Off-chain, the DAO organises through [three working groups](https://www.quantumbiology.eco/blog/meet-the-working-groups-of-the-quantum-biology-dao) announced in May 2025: **Science** (reading and interpreting quantum-biology research for the community), **Communications** (outreach and education), and **Operations** (tracking contributor involvement and coordinating projects), each led by a designated contributor. The structure has been amended by vote more than once — a Working Groups proposal in January 2025, an update in May 2025, and a Science Working Group restructure carried on 17 May 2026 with 12 voters. Working groups are the standard answer to the coordination problem described in [SubDAOs and working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups); here they carry more weight than usual, because they are where the contributors who cannot outvote the vesting holders actually do the work.

## Place in the DeSci landscape

Within the [Molecule / bio.xyz](/wiki/desci/ecosystem/molecule) lineage, Quantum Biology DAO occupies a rare niche. Most BioDAOs are _therapeutic-area_ DAOs that fund a pipeline toward a drug or intervention. Quantum Biology DAO is a _foundational-science-and-tooling_ DAO: its deliverable is knowledge and an instrument, and its bet is that discovery upstream of any single disease unlocks many downstream applications. That places it closer in spirit to a research-infrastructure play than to a [single-asset IP-NFT](/wiki/desci/ip-nfts) bet — a useful data point for anyone mapping how far the [DeSci funding model](/wiki/desci/desci-funding) can stretch beyond the drug-development template it was first built for.

It is also, on the evidence above, a useful data point about the _governance_ half of DeSci. The science kept moving: a public dataset, a JCVI partnership, a funded lab in Los Angeles, a grant approved on schedule. The decentralization did not. Whether that matters depends on what the token was sold as — a claim on a research agenda, or a ticket to decide it.

## How Caper approaches this

Quantum Biology DAO is a science-funding organisation, not a governance protocol, so [Caper](/wiki/foundations/what-is-a-caper) is not a competing tool. But its record is a clean illustration of two things Caper's design takes a different position on.

The first is what a token is worth in a vote. Caper computes a member's vote weight as `(held × votes) / (supply × circulation)` — holdings multiplied by votes actually cast. Because the two are multiplied, a holding that has never voted contributes nothing at all: a member's first vote stores zero, and weight only accumulates through participation. A block of tokens cannot, on its own, carry a decision. That is a deliberately different answer to the situation above, where a locked allocation counts at full strength from day one.

The second is what a disengaged holder can do instead of abstaining. In Caper the same weight that governs a vote also sets a member's share on [exit](/blog/the-exit-right), so leaving is a computed right rather than a sale into whatever liquidity exists. A holder who no longer agrees with the direction is not left choosing between a vote that cannot move the outcome and a market that may not be there. See [how Caper proposals work](/wiki/governance/proposals) and [how a caper raises funds](/wiki/markets/raising-funds).

## Rejuve.AI

URL: https://caper.network/wiki/desci/ecosystem/rejuve-ai
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Type** | DeSci network / longevity data union |
| **Founded** | 2021 (SingularityNET spin-off) |
| **Focus** | AI-driven longevity research; member-owned health data |
| **Founders** | Jasmine Smith (CEO), Dr. Deborah Duong (CTO), Dr. Ben Goertzel (Chief AI Scientist) |
| **Token** | RJV (utility & membership; launched 2023) |
| **Networks** | Ethereum + Cardano |
| **Product** | Rejuve Longevity app (launched 31 March 2025) |
| **AI stack** | OpenCog Hyperon; BayesExpert; Modular Transformer VAE |
| **Status** | 🟢 Active |
| **Website** | [rejuve.ai](https://www.rejuve.ai) |

## Overview

**Rejuve.AI** is a decentralized longevity research network that rewards ordinary people for contributing health data and AI models toward the science of extending healthy human lifespan. Founded in 2021 as a spin-off of [SingularityNET](https://singularitynet.io/ecosystem/rejuve-ai/) — the decentralized-AI project led by Dr. Ben Goertzel — it sits at the intersection of [decentralized science](/wiki/desci/what-is-desci) and artificial general intelligence. Where a classical [longevity BioDAO](/wiki/desci/ecosystem/vitadao) funds drug programs through [IP-NFTs](https://www.rejuve.ai/tokens), Rejuve pursues a different lever: pool the everyday health signals of a global membership, feed them to longevity-focused AI, and share the resulting value back with the people who supplied the data.

That makes Rejuve a clear example of a [data-ownership DAO (a "data union")](/wiki/desci/research-data-ownership) — the same archetype as genomic-data network [GenomesDAO](/wiki/desci/ecosystem/genomesdao), but broadened from sequencing to the full stream of consumer health data (wearables, surveys, lab reports) and paired with an [AI research engine](https://www.rejuve.ai/). Its leadership team — CEO Jasmine Smith, CTO Dr. Deborah Duong, and Chief AI Scientist Dr. Ben Goertzel — ties the project directly into the [SingularityNET and Cardano ecosystems](https://developers.cardano.org/blog/2024-02-19-february/).

## The data-union model

Rejuve's core mechanism is an explicit two-sided exchange: contribute value to the network, receive [RJV tokens](https://www.rejuve.ai/tokens) in return. The network recognises two kinds of contribution — **health data** supplied through the app, and **AI models** supplied through the Global Collaboration Network (GCN). Members earn RJV by [completing health surveys, uploading time-series data from wearables, joining focused data-gathering events, participating in Rejuve or partner-sponsored clinical trials, and referring others](https://www.rejuve.ai/tokens) — and, crucially, by having their data actually used in a study or lead to new research or therapies.

This is the DeSci answer to the extractive Web2 health-data economy, where a platform monetises user data and keeps the upside. Rejuve inverts it: the [contributor is the owner](https://techinformed.com/a-coffee-withjasmine-smith-ceo-rejuve-ai/), consent and permissions are tracked on-chain, and the mission is to keep the resulting longevity insights [affordable and accessible](https://singularitynet.io/ecosystem/rejuve-ai/) rather than locked behind a clinic paywall.

## RJV token and the NFT layer

The [RJV utility token launched in 2023](https://medium.com/singularitynet/rejuve-network-token-launch-a-leap-forward-in-quest-to-apply-ai-and-blockchain-to-human-longevity-8f405d5beb85), minted on both Ethereum and Cardano. It is the membership token of the Rejuve Network: it is earned by data and model contributors, and it is spent in the app's **Rewards Store** for discounts on wearables, medical tests, consultations, longevity therapies, and supplements — closing the loop so that the token's utility is health, not speculation.

Two NFT types sit alongside RJV to encode ownership rather than transactions:

- **Data NFT** — a unique NFT minted per member and linked to their _RejuveID_, which records and manages the permissions attached to that member's data.
- **Product NFT** — a _fractionalized_ NFT allocated across everyone who contributed the data or effort behind a given product, so that downstream commercial value flows back proportionally to contributors.

The fractionalized Product NFT is the structural echo of the [IP-NFT](https://www.molecule.xyz/) model pioneered by [Molecule](/wiki/desci/ecosystem/molecule) and [VitaDAO](/wiki/desci/ecosystem/vitadao), applied to [data contributions](/wiki/desci/research-data-ownership) instead of a single research program.

## The AI research engine

What separates Rejuve from a pure data cooperative is the AI it feeds. The network's models are built on [SingularityNET's AGI stack](https://singularitynet.io/ecosystem/rejuve-ai/), including the [OpenCog Hyperon](https://www.rejuve.ai/) framework. Rejuve's stated aim is not to fit surface correlations but to build _mechanistic_, dynamic models of human biology — combining neural nets, Bayesian networks, and simulation. Two named architectures anchor the current suite: **BayesExpert**, a probabilistic reasoning engine, and a **Modular Transformer VAE** neural network, together intended to produce a simulated model of a member's body with tailored, personalised longevity insights.

This AGI-adjacent ambition — treating aging as a systems-modelling problem — is what places Rejuve at the frontier where [DeSci](/wiki/desci/what-is-desci) meets decentralized AI, and distinguishes it from BioDAOs whose value is a therapeutic pipeline rather than a model.

## The Longevity app

Rejuve's consumer front door is the **Rejuve Longevity** mobile app, [released on iOS and Android on 31 March 2025](https://en.cryptonomist.ch/2025/03/31/earn-tokens-while-improving-your-health-rejuve-ai-launches-the-longevity-app-to-revolutionize-longevity-research/) after a 4,000-person beta. It lets a global audience monitor health metrics, connect wearables, receive personalised insights, and accumulate RJV along the way — the on-ramp that turns the data-union thesis into a product ordinary people can actually use. Coverage at launch framed it as an attempt to give [fairer access to longevity advice and treatments](https://agetechworld.co.uk/medtech-devices/ai-powered-app-to-provide-longevity-advice-reward-users-with-crypto-tokens-to-contribute-to-de-sci-project/), with crypto rewards as the incentive to contribute; the app calculates its recommendations from [over 370 biomarkers, more than 300 of them fed into the AI](https://agetechworld.co.uk/medtech-devices/ai-powered-app-to-provide-longevity-advice-reward-users-with-crypto-tokens-to-contribute-to-de-sci-project/), and CEO Jasmine Smith pitched the point as much political as technical — “that progress shouldn't be gatekept.”

## Governance and structure

Rejuve is best understood as a **decentralized network with a token-membership economy** inside the SingularityNET ecosystem, rather than an on-chain token-voting [DAO](/wiki/desci/desci-daos) in the Governor/Snapshot mould. RJV signifies membership and participation, and the NFT layer distributes ownership of data and product value; the network's direction is steered through the SingularityNET orbit and the Rejuve team rather than a formal proposal-and-vote treasury. In the DeSci landscape it is a reminder that "decentralization" spans a spectrum — from full on-chain governance to member-owned data cooperatives — and that the value being decentralized here is _data and its upside_, not just a treasury vote.

## References

- [Rejuve.AI — official site](https://www.rejuve.ai/)
- [Rejuve.AI — Tokens (RJV, Data NFT, Product NFT, earning methods)](https://www.rejuve.ai/tokens)
- [Rejuve.AI — Longevity app](https://www.rejuve.ai/longevity-app)
- [SingularityNET — Rejuve.AI ecosystem profile](https://singularitynet.io/ecosystem/rejuve-ai/)
- [Ben Goertzel — Rejuve Network Token Launch (SingularityNET, 2023)](https://medium.com/singularitynet/rejuve-network-token-launch-a-leap-forward-in-quest-to-apply-ai-and-blockchain-to-human-longevity-8f405d5beb85)
- [Rejuve Longevity app launch announcement](https://www.crypto-reporter.com/press-releases/rejuve-ai-longevity-app-launch-singularitynet-spin-off-offers-rjv-tokens-in-exchange-for-longevity-data-94119/)
- [The Cryptonomist — Rejuve.AI launches the Longevity App (31 March 2025)](https://en.cryptonomist.ch/2025/03/31/earn-tokens-while-improving-your-health-rejuve-ai-launches-the-longevity-app-to-revolutionize-longevity-research/)
- [AgeTech World — AI-powered app to provide fairer access to longevity advice and treatments (3 April 2025)](https://agetechworld.co.uk/medtech-devices/ai-powered-app-to-provide-longevity-advice-reward-users-with-crypto-tokens-to-contribute-to-de-sci-project/)
- [TechInformed — interview with CEO Jasmine Smith](https://techinformed.com/a-coffee-withjasmine-smith-ceo-rejuve-ai/)
- [Cardano Developer Portal — Rejuve.AI feature](https://developers.cardano.org/blog/2024-02-19-february/)

## ResearchHub (ResearchCoin)

URL: https://caper.network/wiki/desci/ecosystem/researchhub
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Name** | ResearchHub / ResearchCoin (RSC) |
| **Type** | Open-science publishing and peer-review network with a token-denominated reward layer |
| **Founded** | Proposed February 2019; [ResearchHub Technologies, Inc. founded January 2020](https://www.sec.gov/Archives/edgar/data/1679788/000167978826000045/coin-20260424.htm) |
| **Founders** | [Brian Armstrong (CEO) and Patrick Joyce (COO)](https://barmstrong.medium.com/update-on-researchhub-and-researchcoin-4029941647b8) |
| **Token** | ResearchCoin (RSC) – [Ethereum ERC-20](https://etherscan.io/token/0xD101dCC414F310268c37eEb4cD376CcFA507F571), bridged 1:1 to [Base](https://basescan.org/token/0xFbB75A59193A3525a8825BeBe7D4b56899E2f7e1). Fixed 1,000,000,000 supply, fully pre-mined |
| **Governance** | Off-chain [Snapshot signalling](https://snapshot.box/#/s:researchhub.eth) (RSC balance-weighted), no quorum, proposal rights gated to four addresses – _not_ binding on-chain execution |
| **Peer review** | [$150 USD equivalent in RSC](https://docs.researchhub.com/researchhub-foundation/programs-and-initiatives/peer-review-program/peer-review-guidelines) per approved review; ORCID + identity verification required |
| **Journal** | ResearchHub Journal (ISSN 3070-3395), launched late 2024 – [12 papers published all-time](https://www.researchhub.com/journal) as of July 2026 |
| **Related** | [Decentralized publishing & peer review](/wiki/desci/decentralized-publishing) · [What is DeSci](/wiki/desci/what-is-desci) · [Molecule](/wiki/desci/ecosystem/molecule) |

**ResearchHub** is an open-science platform that pays researchers in its own token, **ResearchCoin (RSC)**, for work the academic system normally extracts for free – above all **peer review**. It is the most-cited working instance of the paid-review thesis described in [decentralized publishing and peer review](/wiki/desci/decentralized-publishing), and it is unusual among [DeSci organizations](/wiki/desci/desci-daos) in that it is not an [IP-NFT](/wiki/desci/ip-nfts) funding vehicle at all: it sells no research assets and owns no patents. Its product is the _reviewing and publishing layer_ itself.

It is also the DeSci project with the most direct line to a public company. ResearchHub was founded by **Brian Armstrong**, the chairman and CEO of Coinbase, and RSC now trades on Coinbase – an arrangement Coinbase discloses in its own [proxy statement](https://www.sec.gov/Archives/edgar/data/1679788/000167978826000045/coin-20260424.htm) as a related-party transaction, quoted in full below.

This page describes what the network verifiably _is_, which is narrower than how it is often described. ResearchHub is frequently called a DAO. Its own documentation says it functions _“like”_ one. On inspection the RSC contract has no voting machinery, votes are non-binding signals, and execution runs through small multisigs – a gap this page documents in detail.

## Origin and corporate structure

The idea was published on 25 February 2019 in Armstrong's essay [“Ideas on how to improve scientific research”](https://barmstrong.medium.com/ideas-on-how-to-improve-scientific-research-9e2e56474132), which argued that science's core problems were incentive problems: reviewers work unpaid and uncredited, publishers capture the value, and replication earns nothing. RSC was proposed as the missing reward unit. [Armstrong later described](https://barmstrong.medium.com/update-on-researchhub-and-researchcoin-4029941647b8) ResearchHub as “a project I co-founded with Patrick Joyce,” and noted that “a separate foundation, the ResearchHub Foundation, created ResearchCoin.”

The structure has three parts that are easy to conflate:

- **ResearchHub Technologies, Inc.** – a Delaware corporation. Coinbase's [2026 proxy statement](https://www.sec.gov/Archives/edgar/data/1679788/000167978826000045/coin-20260424.htm) states plainly: “In January 2020, Mr. Armstrong founded ResearchHub Technologies, Inc., a scientific research development platform, where he currently serves as Chief Executive Officer and a member of the board of directors.” Its [Form D](https://www.sec.gov/Archives/edgar/data/1981409/000198140923000001/primary_doc.xml) lists Patrick Joyce as COO and director.
- **The ResearchHub Foundation** – issuer of RSC and operator of the grants and peer-review programs.
- **The token** – RSC, held by the public, the company, and the founders.

Fundraising is documented in SEC filings rather than press releases, and the filings are the more precise source. The 2023 round [offered $5,266,546 and sold $4,462,576](https://www.sec.gov/Archives/edgar/data/1981409/000198140923000001/primary_doc.xml) to four investors, led by [OSS Capital](https://oss.capital/portfolio/research-hub/); a [second round](https://www.sec.gov/Archives/edgar/data/1981409/000198140925000001/primary_doc.xml) sold $2,000,000 to two investors from February 2025. Coverage describing a clean “$5M raise” is quoting the offering size, not the amount sold.

## ResearchCoin (RSC): a reward token, not a governance token

RSC is an ordinary fixed-supply ERC-20. The [Ethereum contract](https://etherscan.io/token/0xD101dCC414F310268c37eEb4cD376CcFA507F571) (`0xD101dCC414F310268c37eEb4cD376CcFA507F571`) reports a `totalSupply` of exactly 1,000,000,000 RSC, fully pre-mined at the [1 August 2020 token generation event](https://docs.researchhub.com/researchcoin/rsc-tokenomics/rsc-emission-schedule) – there is no mint function. The [Base contract](https://basescan.org/token/0xFbB75A59193A3525a8825BeBe7D4b56899E2f7e1) is a bridged representation, [“backed 1:1 by the main token on Ethereum”](https://docs.researchhub.com/researchcoin/rsc-tokenomics); the two balances are not additive, so the true supply is 1B, not the ~1.07B a naive sum suggests.

The contract carries no `delegate`, `getVotes`, or checkpointing functions – none of the ERC20Votes machinery that on-chain token governance requires. This is the technical reason RSC cannot cast a binding on-chain vote, and it is a deliberate design, not an oversight: RSC is a _reward and reputation_ unit.

[Distribution](https://docs.researchhub.com/researchcoin/rsc-tokenomics/rsc-distribution-chart) is documented as “60% distributed to the community and users of ResearchHub, with a maximum emission of 5% per year,” “20% retained by ResearchHub Technologies, Inc.,” “10% retained by ResearchHub's founders,” and “10% reserved for future ResearchHub employees.” The Foundation “may receive 1% per year (10M RSC)” of the community emission.

The consequence is that the 60% community share is a _schedule_, not a present-tense fact. [About 221 million RSC circulate](https://www.coingecko.com/en/coins/researchcoin) against the 1B supply – roughly 22% – meaning the large majority of the token still sits undistributed at the company, the founders, and the Foundation more than five years after the TGE. Emission is capped at 5% per year, so full community distribution is a decade-scale process by construction.

RSC is earned through peer review, bounties, and (historically) upvotes, and is spent on funding proposals, bounties, and journal fees. ResearchHub takes [“a 9% fee on any amounts funded to proposals”](https://docs.researchhub.com/researchhub/product-features/fund/funders-and-donors).

## Paid peer review and the ResearchHub Journal

The paid-review program is ResearchHub's most concrete contribution and the part most worth studying. The [published guidelines](https://docs.researchhub.com/researchhub-foundation/programs-and-initiatives/peer-review-program/peer-review-guidelines) are specific: **“$150 USD equivalent in ResearchCoin (RSC) per approved high-quality review”**, with “a maximum of two paid reviews per paper,” reviewers limited to “up to 2 reviews per week,” reviews of “up to 3,000 words,” and payment “approximately 10 days after acceptance.”

The sybil defence is identity, not stake: to be paid, reviewers must “verify their identity” and “authenticate ORCID.” Notably, _no PhD or publication record is required_ – reviews are editorially vetted before payment rather than gated by credential beforehand. This is the inverse of the traditional model's trust assumption, and the honest open question is whether editorial vetting scales as well as reputational gatekeeping.

The **ResearchHub Journal** (ISSN 3070-3395) applies the model to a full journal. It runs a publish-review-curate flow: submissions are posted as preprints with DOIs regardless of outcome, review is unblinded in both directions, and it is issueless. It advertises review in [“~14 days” with a decision within 21 days](https://www.researchhub.com/journal), against an article processing charge now listed at **$300** – reduced from the [$1,000 quoted at launch](https://blog.researchhub.foundation/the-researchhub-journal/).

Its output is the number to sit with. Querying ResearchHub's own journal feed for published articles returns **12 papers in total** since launch, spanning July 2025 to April 2026, with nothing published in the roughly three months to July 2026. The journal is also not yet indexed in [DOAJ](https://doaj.org/) or OpenAlex; ResearchHub's documentation promises indexing only in the future tense. A 14-day review promise is a real improvement over a 6-month one, but it has so far been exercised at a rate of well under one paper a month.

## Governance: signalling, not token voting

ResearchHub is routinely listed among DAOs, and its documentation says it functions “like a decentralized autonomous organization,” with “token holders of ResearchCoin voting on proposals.” That second clause overstates what exists, and the gap is instructive for anyone studying [on-chain versus off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance).

What is verifiable from the [researchhub.eth Snapshot space](https://snapshot.box/#/s:researchhub.eth) and the token contract:

- **No on-chain vote is possible.** RSC has no ERC20Votes functions, so no binding token vote can be executed by the token itself.
- **Voting is off-chain Snapshot only**, using `erc20-balance-of` on the Ethereum and Base contracts – plain [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) in signalling form. Across the space's entire history there have been **29 proposals**.
- **There is no quorum.** The space's `quorum` is unset.
- **Proposal rights are gated.** The space sets `onlyMembers: true` with three admins and one member – four addresses may propose. It is not open proposal-making.
- **Votes do not execute.** Snapshot results are signals; the treasuries are multisigs, and moving funds requires the signers, not the vote.

Turnout reflects this. The most recent proposal, [RIP-24 (19 January 2026)](https://snapshot.box/#/s:researchhub.eth), drew **five voters** casting about 53,000 RSC – against a supply of a billion. ResearchHub's own team acknowledged the underlying design early: on [Hacker News in 2021](https://news.ycombinator.com/item?id=27271366) a team member wrote that “RSC is 100% pre-mined” and “for every coin held, an individual wallet gets one vote. This means that the biggest hodlers of RSC will have the most influence.”

The accurate description is therefore: **off-chain, non-binding, balance-weighted signalling with gated proposal rights, no quorum, and multisig execution.** That is a legitimate way to run a company-led open-science platform – but it is a company with a suggestion box, not a DAO in the token-voting sense, and the wiki records it as such.

## Criticism and conflicts of interest

**The Coinbase relationship is disclosed, and the disclosure is the story.** Coinbase's [DEF 14A proxy statement filed 24 April 2026](https://www.sec.gov/Archives/edgar/data/1679788/000167978826000045/coin-20260424.htm) lists RSC under related-party transactions, stating verbatim:

> “In the first quarter of 2025, ResearchCoin was approved for listing on our retail trading platform by the digital asset support group of Coinbase, Inc. in accordance with our digital asset support policies and procedures. Mr. Armstrong, our Chairman & Chief Executive Officer, is a co-founder and Chief Executive Officer of ResearchHub Technologies, Inc., the creator of ResearchCoin, and holds a significant percentage of ResearchCoin's market capitalization. We recognized revenue of approximately $201,273 from ResearchCoin in the year ended December 31, 2025.”

Two things follow. Coinbase itself concedes that its CEO “holds a significant percentage” of the market cap of a token his exchange lists, and it quantifies its own revenue from it. Coinbase's stated procedural answer is that [“Brian is not a reviewing or approving member of the Coinbase Digital Asset Support Group”](https://www.theblock.co/post/364847/coinbase-lists-researchcoin-rsc-brian-armstrong-desci). Readers should note the timeline runs from Q1 2025 approval to the [31 July 2025](https://www.coinbase.com/en-gb/blog/increasing-transparency-for-our-listings-process) public listing.

**Reward farming is self-admitted.** The clearest evidence is ResearchHub's own proposal RIP-22 (June 2025), which removed the 0.01 RSC upvote reward, stating that “while rewarding upvotes was originally intended to encourage participation and reward high quality content, in practice it has created an easy opportunity for spam users and bots to extract value from the ResearchHub community.” This is the predictable failure of paying for a cheap, unverifiable action, and it is a compact case study for [sybil resistance](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks): the fix was to stop paying for the action that could not be verified, and keep paying for the one that could be reviewed.

**The market has been unkind.** RSC trades around [$0.077, roughly 95% below its $1.51 all-time high of 5 January 2025](https://www.coingecko.com/en/coins/researchcoin), for a market capitalization near $17M. Because reviewer pay is denominated in _USD_ and settled in RSC, the price collapse does not cut a reviewer's headline $150 – but it does mean the Foundation spends far more RSC per review than it once did, and it weakens the token's story as an appreciating claim on future science.

Two frequent misattributions are worth correcting. The Scholarly Kitchen's well-known critique of paid review is a _generic_ argument that does not mention ResearchHub and predates the journal by years; and critic David Gerard's [write-up](https://pivot-to-ai.com/2025/03/09/scientific-peer-review-by-ai-with-its-own-cryptocurrency-as-promoted-in-nature/) describes ResearchHub as “founded by crypto exchange Coinbase,” which is incorrect – it was founded by Coinbase's CEO personally, a distinction the SEC filing makes precisely. Substantive independent coverage of ResearchHub remains thin; the filings are better sources than the journalism.

## How Caper approaches this

ResearchHub and [Caper](/wiki/foundations/what-is-a-caper) are solving different problems – ResearchHub pays for scientific labour, which a caper does not do – but they collide on one question: **what should a token actually measure?**

ResearchHub answers it by splitting the two roles and letting one wither. RSC is a reward unit, so it does its job well: a review is verifiable work, and paying for it in a transferable token is coherent. But because RSC is _also_ the governance instrument, and because it is transferable and 78% undistributed, governance inherits a token that was never designed to carry it – hence no quorum, four permitted proposers, and five voters on the most recent proposal. Influence there is priced; anyone can buy RSC without ever reviewing a paper.

A caper keeps the two units separate. Governance weight is computed by `compute_vote_weight` (`contracts/logic/src/lib.rs`) as `(held × votes) / (vote_supply × circulation)` – the product of what you hold and the votes you have actually cast. The vote token is minted with `DIVISIBILITY_NONE` and a depositor rule that only accepts a deposit from the DAO's own frame (`contracts/core/src/caper_dao.rs`), which makes it **soulbound**: it is earned by voting and cannot be bought, sold, or delegated. The same helper computes the treasury share paid out by `exit()`, which then burns the tokens – so voice and exit are the same number.

This is not a claim that a caper's weight ignores your holdings. It does not: `held` is a multiplicative factor, and a large position matters. The difference is that it is _only_ a factor. Capital alone cannot capture a caper, because the other factor – the earned, non-transferable record of having shown up – is not for sale at any price. ResearchHub demonstrates the value of paying for verifiable work; a caper applies the same instinct to governance itself, and makes the earned part the part you cannot buy.

The honest concession: ResearchHub's notion of contribution is far richer than a caper's. It knows a good review from a bad one, because a human read it. A caper knows only whether you voted. That is a much poorer signal – deliberately so, because it is the only one a contract can verify without a judge.

## References and further reading

- [Brian Armstrong, “Ideas on how to improve scientific research” (25 February 2019)](https://barmstrong.medium.com/ideas-on-how-to-improve-scientific-research-9e2e56474132) – the founding essay.
- [Coinbase Global, DEF 14A proxy statement (24 April 2026)](https://www.sec.gov/Archives/edgar/data/1679788/000167978826000045/coin-20260424.htm) – the related-party disclosure and the January 2020 founding date.
- [ResearchHub documentation](https://docs.researchhub.com/) – tokenomics, distribution, fees, and peer-review guidelines.
- [researchhub.eth Snapshot space](https://snapshot.box/#/s:researchhub.eth) – the full proposal and vote history.
- [ResearchHub on GitHub](https://github.com/ResearchHub) – the platform is actively developed and open source.
- [ResearchCoin on CoinGecko](https://www.coingecko.com/en/coins/researchcoin) – market data and circulating supply.

See also: [Decentralized publishing & peer review](/wiki/desci/decentralized-publishing), [DeSci DAOs](/wiki/desci/desci-daos), [Molecule](/wiki/desci/ecosystem/molecule), [Bio Protocol](/wiki/desci/ecosystem/bio-xyz), and [Token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting).

## UltraRare Bio

URL: https://caper.network/wiki/desci/ecosystem/ultrarare-bio
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Type** | DeSci media & research |
| **Focus** | DeSci education, curation, advocacy |
| **Key output** | DeSci Wiki, UltraRare Podcast |
| **Curated by** | Jocelynn Pearl (Ph.D.) |
| **Landscape by** | Dani Bergey, Katie Koczera |
| **DeSci Wiki status** | **Frozen** – the document's own log records its last update as 19 January 2024 |
| **Website** | ultrarare.bio is offline (DNS resolves, HTTPS times out) |
| **X (Twitter)** | [@UltraRareBio](https://x.com/UltraRareBio) |

## Overview

UltraRare Bio is a [decentralized-science](/wiki/desci/what-is-desci) media and research team that produced two of the field's foundational reference works: the [DeSci Wiki](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/) – a directory of DeSci projects, DAOs and communities – and the UltraRare Podcast covering developments across the ecosystem.

The DeSci Wiki is curated by Jocelynn Pearl, Ph.D., with the Decentralized Science Landscape figure created by the UltraRare Bio team including Dani Bergey and Katie Koczera. For the movement's first years it was the map everyone used, and it is still the best single record of what DeSci looked like before the 2024 BioDAO wave. It is no longer current, and the section below sets out exactly where it stops.

## The DeSci Wiki

The document catalogs the ecosystem across roughly fifteen categories: [DeSci DAOs](/wiki/desci/desci-daos), decentralized science ecosystems, scientific publishing, [IP-NFTs](/wiki/desci/ip-nfts) and IP tokens, decentralized biotech and biopharma, focused research organizations, science NFTs, decentralized financing of science, data storage and blockchain protocols, social communities, and a reading list. Entries carry links, core-team names, and in many cases a curator's note on what the project actually is.

The most useful part is the one most directories omit. An **Archived Projects** section holds fourteen wound-down efforts – OpenAccessDAO, Agora Labs, Framework Bio, Impact Finance, BioDAO, CRISPR DAO, DeSci Nerdery, DeBio Network, DeNature DAO, NeuraDAO, LYNX, Planck, OpenNMN and Moon Rabbit – each kept in place with a dated note explaining the call: "server now dead", "Twitter and Discord has been inactive for >1year", "Group has disassembled and is no longer active (contacted Sam Nehme who was a founder)". Deliberately preserving the dead alongside the living is what made the document a record of the ecosystem's evolution rather than a snapshot of its winners.

## Where the record stops

The document's own _Updates and General Info_ block states the intent to integrate missing projects "~once per week". The last update it logs is **19 January 2024**, and the contents bear that out. All 46 social links in it point at `twitter.com`; not one points at `x.com`. The dated articles it collects cluster on 2022. And it contains no entry at all for the wave of BioDAOs that has defined the field since: [CryoDAO](/wiki/desci/ecosystem/cryodao), whose first proposal opened seven weeks before that last update, is absent, as are AxonDAO, Quantum Biology DAO, DermaLabs, Long COVID Labs and Pump.science. [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) appears only under its pre-rebrand name, Bio.xyz, as one ecosystem entry among ten.

Two entries show the freeze from the inside. GenomicDAO and Jocelyn DAO both carry unresolved reader comments in the margin – "has been sunset", "I believe also sunset" – and both still sit in the live directory rather than in the Archive section built for exactly that. Somebody did the work of flagging them; nobody was left to move them.

None of this makes the document worthless, and the wiki links it for what it is: an unusually careful primary record of DeSci from roughly 2021 to the end of 2023, including a curated account of which early projects died and why. It is not a current directory, and readers who treat it as one will conclude the field stopped growing in January 2024.

## Place in the ecosystem

UltraRare Bio is not itself a DAO – it was the movement's _discovery layer_. A field of hundreds of small, fast-moving [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) is only navigable if someone keeps a neutral, current map of who exists and who has shut down, and that map is what routed new funders, scientists and contributors to the right [project](/wiki/desci/ecosystem/vitadao). It complemented the funding-and-tokenization stack ([Bio Protocol](/wiki/desci/ecosystem/bio-xyz), [Molecule](/wiki/desci/ecosystem/molecule)): curation media answered "what is out there," while the launchpad and IP-NFT layers answered "how do you fund and own it."

Its stall leaves that job open, and the gap is not cosmetic. Deciding whether a DeSci project is still alive is genuinely hard work – it means checking domains, forums, vote records and social accounts one at a time, and being willing to write down that something has died. The DeSci Wiki's archive shows what that costs and what it is worth. This wiki's own [DeSci DAO](/wiki/desci/desci-daos) coverage tries to carry the same discipline forward, and the same maintenance burden is why so few directories survive their founders' attention.

## External Links

- [DeSci Wiki – full project directory](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/) – live, but last updated 19 January 2024
- [UltraRare Bio on X](https://x.com/UltraRareBio) (the former ultrarare.bio site is offline)

## ValleyDAO

URL: https://caper.network/wiki/desci/ecosystem/valleydao
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Type** | DeSci DAO — climate biotech & synthetic biology R&D |
| **Focus** | Funding synthetic biology research with climate and industrial applications |
| **Governance** | Two-tier — Discourse discussion → [Snapshot](https://snapshot.org) vote |
| **Token** | GROW (Ethereum, Base, Solana) |
| **Holders** | 1,200+ GROW holders; 4,000+ community members (self-reported) |
| **Treasury** | ~$4M (self-reported) |
| **Portfolio** | 5 funded projects & spinouts; grants up to $200k, target <2 months to decision |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO |
| **IP framework** | [Molecule](/wiki/desci/ecosystem/molecule) [IP-NFTs](/wiki/desci/ip-nfts) |
| **First IP-NFT** | "SavedApe" — microbial lipid production, Imperial College London (Aug 2023) |
| **Website** | [valleydao.bio](https://www.valleydao.bio) |

## Overview

ValleyDAO is a [decentralized science (DeSci)](/wiki/desci/what-is-desci) organization that funds [synthetic biology research with climate and industrial applications](https://www.valleydao.bio) — engineering biological systems (microbes, yeasts, enzymes) to make materials and chemicals that today depend on fossil inputs. It operates as a BioDAO within the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) ecosystem, using the same [Molecule](/wiki/desci/ecosystem/molecule) tokenization stack as sibling BioDAOs such as [VitaDAO](/wiki/desci/ecosystem/vitadao) and [CryoDAO](/wiki/desci/ecosystem/cryodao).

The thesis is that early-stage synthetic biology is chronically under-funded by traditional grants and venture capital: promising academic work stalls in the "valley of death" between a publication and a fundable company. ValleyDAO routes community capital directly to that stage in exchange for a governed share of any resulting intellectual property.

## Mission and focus

ValleyDAO frames its pipeline as [climate biotech](https://www.valleydao.bio/grow) — research where engineered biology can displace a carbon-intensive incumbent process. Representative directions include microbial production of oils, proteins and biodegradable materials, carbon-capturing organisms, and fermentation routes to industrial chemicals. Projects are sourced from academic labs, reviewed by the community, and funded only if token holders vote to back them.

This narrows the broad DeSci mandate: where [VitaDAO](/wiki/desci/ecosystem/vitadao) funds longevity and [CryoDAO](/wiki/desci/ecosystem/cryodao) funds cryopreservation, ValleyDAO concentrates on synthetic biology with a commercial and environmental payoff, so that licensing income or startup equity can flow back to the DAO treasury.

## The GROW token and governance

[GROW](https://www.valleydao.bio/grow) is ValleyDAO's governance token, deployed across Ethereum, Base and Solana with 1,200+ reported holders. It carries two rights: voting on which research proposals the DAO funds and how the resulting [IP-NFTs](/wiki/desci/ip-nfts) are licensed, and — via those IP-NFTs — a claim on downstream proceeds if a funded project generates licensing revenue or equity.

Governance runs in two tiers, a pattern common across BioDAOs: proposals are first discussed on a [Discourse forum](https://snapshot.org) where members give feedback and refine terms, then move to [Snapshot](https://snapshot.org) for binding token-weighted votes. Because ValleyDAO sits inside [Bio Protocol](/wiki/desci/ecosystem/bio-xyz), secondary-market liquidity for GROW is managed at the protocol layer rather than by the DAO itself — a division of labour that lets the DAO concentrate on [curation and governance](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) rather than market-making.

## Research funded: the SavedApe IP-NFT

ValleyDAO's first funded project, minted as the ["SavedApe" IP-NFT](https://molecule.xyz/blog/valleydao-imperial-college-london) in August 2023, backed [Dr Rodrigo Ledesma-Amaro's lab at Imperial College London](https://molecule.xyz/blog/valleydao-imperial-college-london) with £228,000 to engineer the oleaginous yeast _Yarrowia lipolytica_ for sustainable, industrial-scale production of oils — a route to replacing extractive or fossil-derived lipids used across food, cosmetics and biofuels.

The intellectual property from the work is held in an [IP-NFT](/wiki/desci/ecosystem/molecule) whose licensing and commercialization the DAO governs with GROW. This is the mechanism that distinguishes DeSci funding from a grant: the community that pays for the research retains a durable, tradable stake in whatever it produces, rather than handing the upside to a university tech-transfer office or a downstream acquirer.

The portfolio has since widened well past that first mint, and the funding labels on [ValleyDAO's own projects page](https://www.valleydao.bio/projects) now split it in two. Three are community-funded research grants: **Cocoa ZERO** ($300,000), Ledesma-Amaro's follow-on at Imperial growing cocoa lipids by precision fermentation to about 90% of cocoa butter; **Forge** ($200,000), Dr Anna Kaksonen's integrated biomining work at CSIRO turning electronic waste into a domestic source of critical minerals; and **Hempy** ($115,000), Prof. Georg Gübitz's enzymatic softening of hemp fibre at the Austrian Centre of Industrial Biotechnology. Three are spinouts carrying conventional equity: **Tattva** ($70,000 equity financing), engineering cyanobacteria into carbon-negative construction materials; **BioHalo** ($1.9M raised externally), precision biohalogenation aimed at biodegradable substitutes for PFAS fluoropolymers; and **SynbioCAD**, an AI strain-design platform still in incubation.

That split is the interesting part. The IP-NFT is the instrument for the research tranche; once a project becomes a company, ValleyDAO's exposure runs through ordinary equity instead – the same [coin-to-company transition](/wiki/desci/ip-nfts) that Molecule's own documentation now makes explicit across DeSci, where tokens confer no legal ownership and a shareholding is acquired off-chain.

## Place in the Bio Protocol ecosystem

ValleyDAO is one of the 11+ specialized BioDAOs incubated by [Bio Protocol](/wiki/desci/ecosystem/bio-xyz), alongside [VitaDAO](/wiki/desci/ecosystem/vitadao) (longevity), [AthenaDAO](/wiki/desci/ecosystem/athenadao) (women's health), [PsyDAO](/wiki/desci/ecosystem/psydao) (psychedelic science) and [CryoDAO](/wiki/desci/ecosystem/cryodao) (cryopreservation). Each is a domain-specific fund with its own token and treasury, while Bio Protocol supplies the shared launchpad, curation market (staking BIO to admit new DAOs) and liquidity layer.

For a fuller map of how these pieces fit together, see [What is DeSci](/wiki/desci/what-is-desci), [IP-NFTs](/wiki/desci/ip-nfts) and the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) overview.

## How Caper approaches this

ValleyDAO shows the BioDAO shape at work: a specialized community raises a token, funds research, and governs the resulting IP — but it leans on Bio Protocol for the launchpad and on Molecule for the IP-NFT layer, and on Discourse plus Snapshot for governance. A [caper](/wiki/foundations/what-is-a-caper) folds those separate layers into one primitive: the raise (a [bonding curve](/wiki/markets/bonding-curve)), the treasury, the on-chain proposal system ([PAYOUT / INVEST / DIVEST / VOTE](/wiki/governance/proposals)) and a participation-weighted [exit](/wiki/governance/execution) – whose treasury share is the member's canonical vote weight `(t·v)/(V·T)`, consuming both the governance tokens and the soulbound vote tokens rather than paying out by balance – ship together, so a community funding a project does not have to assemble four tools to do it. The mission is shared — get capital to under-funded work and let the people who funded it keep a real stake — and the difference is packaging.

## VitaDAO

URL: https://caper.network/wiki/desci/ecosystem/vitadao
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Type** | DeSci DAO – longevity research |
| **Founded** | June 2021 (first DeSci DAO) |
| **Focus** | Funding early-stage longevity & aging science |
| **Token** | VITA (governance-only, ERC-20) |
| **Governance** | Snapshot (gasless, shielded); weight = VITA held. 129 proposals, 1,150,000 VITA quorum, 7-day voting period; most recent created 9 Sep 2025 |
| **Governance forum** | gov.vitadao.com – **offline**; the hostname stopped resolving during 2026 and no replacement is named. [Archived copy](https://web.archive.org/web/20260421071625/https://gov.vitadao.com/) |
| **Legal steward** | Vitality Now, a Swiss association (Verein) – [VDP-160](https://web.archive.org/web/20250114000031/https://gov.vitadao.com/t/vdp-160-vitality-now-association-setup-the-new-legal-steward-for-vitadao/1753), Dec 2024 |
| **Ecosystem** | [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) BioDAO |
| **IP model** | [IP-NFTs](/wiki/desci/ip-nfts) ([Molecule](/wiki/desci/ecosystem/molecule) tooling); VITA-FAST / VITA-RNA IP tokens |
| **Track record** | 31 projects funded, ~$4.7M deployed, 8 IP tokens generated, 3 companies spun out |
| **Notable backers** | Pfizer Ventures, Shine Capital, Balaji Srinivasan |
| **Chain** | Ethereum |
| **Website** | [vitadao.com](https://www.vitadao.com) |

## Overview

VitaDAO is [a community-owned collective that funds and advances early-stage longevity science](https://www.vitadao.com) – the first [decentralized science (DeSci)](/wiki/desci/what-is-desci) DAO, launched in June 2021 out of a [whitepaper by Tyler Golato and Paul Kohlhaas](https://www.vitadao.com/images/vita-labs/VitaDAO_Whitepaper.pdf) of [Molecule](/wiki/desci/ecosystem/molecule), and since grown into the largest organisation in the field. Its aim is to extend human healthspan by pooling community capital to de-risk translational aging research that traditional grant pipelines and venture funds routinely skip.

VitaDAO operates as a BioDAO within the [Bio Protocol](/wiki/desci/ecosystem/bio-xyz) ecosystem (the network Molecule grew into) and holds a 21 million BIO allocation from Bio Protocol's bio/acc rewards programme in recognition of its founding role. [VDP-161](https://web.archive.org/web/20250114004345/https://gov.vitadao.com/t/vdp-161-bio-token-airdrop-to-vitadao-community/1755) put 6.9 million of that allocation back out to the community as an airdrop – 80% (5.52M BIO) to VITA holders and 20% (1.38M BIO) to holders of its IP tokens, tiered by size of holding – and kept the remaining 14.1 million BIO in treasury to fund science. The stake gives VitaDAO a vote in governing new BioDAO launches and ecosystem incentives.

The DAO reports [31 projects funded and roughly $4.7M deployed](https://www.vitadao.com), split across 3 target-discovery, 18 drug-discovery, 3 preclinical and 3 clinical drug-development projects, with 8 IP tokens generated and 3 companies founded.

## Governance and the VITA token

$VITA is a [governance-only token](https://www.vitadao.com/blog/beginners-guide-to-vita-token): it confers no dividend and exists to steer the DAO. Voting happens on [Snapshot in a gasless, shielded format](https://web.archive.org/web/20241116133836/https://gov.vitadao.com/t/how-to-vote-on-snapshot/490) – members must hold VITA in an Ethereum wallet, weight scales with the number of tokens held, and results stay hidden until the vote closes so early tallies don't sway later voters. This is textbook [token-weighted governance](/wiki/dao-governance/concepts/voting/voting-and-delegation), and it inherits token-weighted governance's core tension: influence tracks holdings, not contribution.

Funding decisions escalate by size, and the ladder is written down rather than left to convention. Under the [VitaDAO constitution](https://web.archive.org/web/20260519191733/https://gov.vitadao.com/t/vitadao-governance/787), a spend of $10,000 or less needs two working-group stewards to approve; above $10,000 and below $25,000, VitaCore approves by majority vote; from $25,000 to $50,000 the community decides by majority vote on the Discourse forum; and at $50,000 and above the decision goes to VITA holders on Snapshot. Any proposal from the Longevity Dealflow working group goes to Snapshot regardless of size. The constitution writes its top two tiers with a `≤` where the sense requires the opposite bound, so the numeric boundaries read as overlapping, but the escalation it describes is unambiguous: the larger the cheque, the wider the body that has to agree. Day-to-day work runs through specialist working groups (dealflow, tokenomics, awareness, legal and more) staffed by community stewards rather than a single executive team.

Turnout at the binding stage is small in absolute terms and lopsided in outcome. [The vote.vitadao.eth Snapshot space](https://snapshot.box/#/s:vote.vitadao.eth) has carried 129 proposals against a 1,150,000 VITA quorum; the [VDP-163 FOXO3 oligos](https://web.archive.org/web/20250911080521/https://gov.vitadao.com/t/vdp-163-funding-foxo3-oligos-revised/2033) funding vote closed on 16 September 2025 with 17 voters and 6,618,900 VITA cast entirely For, zero Against and zero Abstain, and the January 2025 BIO airdrop vote drew 37. Those are typical: proposals that reach Snapshot have usually been settled on the forum first, so the on-chain vote ratifies rather than decides – a pattern this wiki covers under [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy). That space has recorded no new proposal since 9 September 2025.

## The Vitality Now Association

In December 2024 VitaDAO's community approved [VDP-160, establishing Vitality Now](https://web.archive.org/web/20250114000031/https://gov.vitadao.com/t/vdp-160-vitality-now-association-setup-the-new-legal-steward-for-vitadao/1753), a Swiss association (Verein), as the DAO's legal steward. The binding vote closed on 7 January 2025 with 862,378 VITA For, none Against and 334,534 Abstaining – 1,196,911 cast in total by 37 voters, roughly 4% clear of the space's 1,150,000 quorum, with more than a quarter of the weight cast declining to take a side. The proposal's framing is explicit about the division of labour: decision power stays with VitaDAO's governance mechanisms, and the association executes those decisions inside Swiss and international law.

What the association actually holds is the part worth reading closely. Under VDP-160 it becomes the ultimate beneficial owner of all Pods – the semi-autonomous working units such as the Longevity Pod and the Web3 Pod – and it may own or control holding companies that manage projects and IP portfolios. It signs agreements with research institutions, core and strategic contributors, and service providers; it oversees IP acquisition, licensing and enforcement; and it manages contributors' multisignature wallets and payment streams alongside the Pods. Operational detail is delegated to VitaDAO's Guardians, the body responsible for strategic planning and the DAO's budgetary framework.

This is the standard shape of a [DAO legal wrapper](/wiki/dao-governance/concepts/membership/dao-legal-structures): a recognised entity that can hold title, sign contracts, and answer to a regulator, sitting beneath a token vote that cannot do any of those things. The trade is equally standard. Everything the association controls – the IP portfolio, the holding companies, the multisigs, the contributor agreements – is governed on-chain only to the extent the association chooses to follow the vote, and members' recourse if it does not is Swiss association law rather than a smart contract.

## IP-NFTs and tokenized research

The mechanism that distinguishes VitaDAO from an ordinary grants pool is how it holds what it funds. Rather than handing out cash and walking away, VitaDAO captures the intellectual property of funded projects as [IP-NFTs](/wiki/desci/ip-nfts) – on-chain assets, built with [Molecule](/wiki/desci/ecosystem/molecule)'s tooling, that the community can govern, license, and commercialise. This turns research IP into a treasury asset the DAO co-owns instead of an outcome it merely sponsors.

VitaDAO went a step further with **VITA-FAST**, [the first IP-NFT to be fractionalised into an ERC-20 IP token](https://www.vitadao.com/blog/announcing-the-vita-fast-token-sale-for-viktor-korolchuk-lab). VITA-FAST represents shared ownership of the "Discovering Novel Autophagy Activators" IP-NFT from the Korolchuk Lab at Newcastle University, and its holders directly govern licensing decisions and experiment priorities for that specific research line. This is [tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) in its most literal DeSci form: a tradeable claim minted directly against a real, governed research asset.

The second IP token, **VITA-RNA**, shows what the pattern looks like once a programme is running for years. Its IP-NFT was tokenized in January 2024 and raised $300,000 for ARTAN Bio, whose lead candidate ARTAN-102 is an engineered suppressor tRNA delivered via AAV9 that reads through premature stop codons to restore full-length protein. The programme's milestones are reported through governance: two lead candidates validated in vitro from an initial screen of 15 oligos in October 2024, a first in vivo study in June 2025 reporting no adverse effects and broad biodistribution including the brain, and GMP process development at Lonza through September 2025. The reporting cadence is the point – an IP token gives holders a reason to be told, and a forum thread to be told in.

## Funding, Pfizer, and the token-versus-value question

In January 2023 VitaDAO closed [a $4.1 million round](https://www.vitadao.com/blog/vitadao-closes-4-1m-fundraising-round-with-pfizer-and-shine-capital) whose backers included Pfizer Ventures, Shine Capital, L1 Digital, Beaker DAO, Spaceship DAO, and individuals such as Balaji Srinivasan and Joe Betts-LaCroix – following [Pfizer's initial $500k VITA purchase](https://longevity.technology/news/pfizer-invests-500k-in-vitadao-to-accelerate-longevity-rd/) in September 2022 that made it the first pharmaceutical company to hold a governance token and vote on a DAO proposal.

That commercialisation raised a familiar structural problem. In April 2023 VitaDAO members [voted to create a for-profit company](https://www.coindesk.com/business/2023/04/05/pfizer-backed-vitadao-votes-on-creating-for-profit-company-to-fund-longevity-research) to carry assets through the capital-intensive stages a community treasury can't underwrite – the same token-versus-equity split [AthenaDAO](/wiki/desci/ecosystem/athenadao) later reached for with AthenaBIO. A freely-traded governance token's price drifts away from the value of the underlying science, so the DAO governs and sources while separate legal vehicles hold and commercialise the work. The Vitality Now structure above is where that split ended up: an association at the top, Pods beneath it, and holding companies beneath those.

## The senior review, and a proposal that never reached a vote

Token voting decides whether a grant is popular. It does not decide whether the science is any good, and VitaDAO layers a scored expert gate in front of the vote to close that gap. The clearest published example is [VDP-164](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052), proposed on 16 September 2025: a $500,000 loan to VITARNA/ArtanBIO, recoverable in a later fundraise, to fund GMP manufacturing and non-GLP toxicology in non-human primates ahead of a targeted 2026 IND submission.

After the forum poll, four reviewers – two biotech entrepreneurs, one biotech VC and one pharma VC, two of them former scientists – scored the proposal out of 5 across seven categories. The published averages were Team Expertise 3.0, Feasibility & Data 2.5, Commercial Potential & Impact 2.0, Novelty & Market Advantage 3.0, IP Defensibility 3.5, Relevance to Longevity 2.5 and Deal Terms 2.5, for an **overall conviction score of 2.3 against an average of 3.7 for past funded projects**. Asked whether they would endorse it, one reviewer said only after more robust delivery, efficacy and IP data; one said conditionally, contingent on a rigorous preclinical package and a narrowed initial indication; and one said no, on the grounds that the mechanism had not been shown to address a meaningful driver of aging.

Publishing the digest then produced a second argument, about the review rather than the science. On 26 February 2026 a member [objected in the thread](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052) that only a qualitative summary had been posted, and asked for the reviewer document and the team's written response to be published in full; ARTAN Bio's own chief executive agreed, writing that the community should be able to read the reviews rather than rely on anonymous reviewers whose credentials no one could check. VitaDAO replied on 3 March 2026 that the format matched previous proposals and that it was open to sharing more detail. Nobody posted again.

The governance outcome is the part that generalises. VDP-164 has never appeared on [VitaDAO's Snapshot space](https://snapshot.box/#/s:vote.vitadao.eth), whose most recent proposal was created on 9 September 2025 – a week before VDP-164 was posted. The constitution's escalation ladder says a request this size needs the community's approval _and_ a Snapshot vote, and a Longevity Dealflow proposal needs the Snapshot vote whatever its size; in practice the proposal has spent its entire life at the forum-and-review stage, and the binding vote it would have to clear has not been called. A scored expert gate is a real answer to token voting's competence problem, and this is its characteristic failure mode: a low score does not reject a proposal, it strands one, and the record of what happened next lives in a forum thread rather than in a vote anyone can point to. The same tension runs through [scoring and review gates](/wiki/dao-governance/concepts/analysis/scoring-and-review-gates) and [DAO procurement and RFPs](/wiki/dao-governance/concepts/analysis/dao-procurement-and-rfps), where a scoring panel decides who is even eligible to be voted on, and through [DeSci funding](/wiki/desci/desci-funding) more broadly.

## The forum went offline, and took the record with it

Every VitaDAO source cited above once pointed at `gov.vitadao.com`, the DAO's Discourse forum. As of 8 August 2026 that hostname no longer resolves. It is a CNAME to `vitadao.hosted-by-discourse.com`, and the target carries no address record at either Cloudflare's or Google's public resolver, so a request fails before it reaches a server – the signature of a hosted Discourse instance that has been shut down rather than moved. The Internet Archive's last successful capture of the forum is 7 June 2026; the VDP-164 thread was last captured on 21 April 2026, and its last post is dated 3 March 2026.

Nothing on VitaDAO's own site names a replacement, and the site has not noticed. The homepage's structured-data FAQ still answers "How can researchers apply for VitaDAO funding?" by telling them to [submit a proposal through the governance forum at gov.vitadao.com](https://www.vitadao.com) – the DAO's front door is routing new research proposals to an address that stopped resolving.

What survived is the half of the stack the DAO does not host. The [vote.vitadao.eth Snapshot space](https://snapshot.box/#/s:vote.vitadao.eth) still returns all 129 proposals, their choices, their per-option scores and their voter counts to any keyless query, because a Snapshot vote is a signed message on shared infrastructure rather than a page on a rented one. Every figure in the sections above that comes from a ballot – VDP-160's 862,378 For against 334,534 Abstain, VDP-163's 17 voters – was re-read from that hub this week. Every figure that comes from deliberation is now cited through the Internet Archive, which is a fallback and not a source of record: it holds what a crawler happened to reach, not what the forum held.

The pattern generalises past VitaDAO, and it cuts in a direction most DAOs have not priced. A DAO that keeps its binding votes on-chain and its reasoning on a hosted forum has split its record across two very different durability guarantees, and the reasoning is the half that goes first. It is also the half that carries the most decisions: under VitaDAO's own ladder everything below $50,000 is settled by stewards, by VitaCore, or by a forum poll, and none of those leave an on-chain trace. So does a proposal that is scored, argued over, and then never put to a vote. A forum is not an archive, and a DAO that treats it as one is one unpaid invoice away from losing the part of its history that explains the votes.

## How Caper approaches this

The token-versus-value gap VitaDAO patches with a legal wrapper and a separate commercial vehicle is the seam a [caper](/wiki/foundations/what-is-a-caper) is built to close. On Caper, contributed capital flows into the caper's own [bonding-curve](/wiki/markets/bonding-curve) treasury rather than into a free-floating governance token whose price detaches from the work – value accrues to the treasury itself, and members hold a [participation-weighted claim](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) on it. Research spending is authorised the way any spend is: a [PAYOUT proposal](/wiki/governance/proposals) that moves a chosen currency and amount from the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) to a lab once members [vote it through](/wiki/governance/voting). Voting weight is stake weighted by participation rather than raw token balance, so the people funding the science keep governance coupled to their exposure – and there is no separate equity vehicle to stand up to keep the token's price from wandering off from the value being built.

Caper has no view on which science is worth funding, and nothing in the protocol substitutes for the expert judgement a senior review supplies. What it does change is where a proposal can stall: every proposal a caper's members raise runs to a decision on-ledger, so a funding request either passes or fails on the record rather than lapsing between a review and a vote that is never called. There is also no size threshold below which a spend skips the record: a caper's treasury pays out on an executed proposal, and the proposal, each ranked ballot cast against it, and its execution are all state and events on the caper's own component. The one other way value leaves a caper's treasury is a member taking their exit, and that too is a ledger event rather than a decision recorded somewhere else. It is a narrower record than a forum thread, and the trade is honest: less discussion preserved, none of what is preserved revocable by a lapsed hosting bill.

## External links

- [VitaDAO – official website](https://www.vitadao.com)
- [VitaDAO on Snapshot (vote.vitadao.eth)](https://snapshot.box/#/s:vote.vitadao.eth) – the live vote record, 129 proposals
- [VitaDAO whitepaper (PDF)](https://www.vitadao.com/images/vita-labs/VitaDAO_Whitepaper.pdf)
- [VitaDAO governance forum](https://web.archive.org/web/20260421071625/https://gov.vitadao.com/) – _archived_; gov.vitadao.com no longer resolves ([category index, 7 June 2026](https://web.archive.org/web/20260607104504/https://gov.vitadao.com/categories))
- [VitaDAO Governance constitution](https://web.archive.org/web/20260519191733/https://gov.vitadao.com/t/vitadao-governance/787) – _archived_; the escalation ladder and proposal types
- [VDP-160 – Vitality Now Association setup](https://web.archive.org/web/20250114000031/https://gov.vitadao.com/t/vdp-160-vitality-now-association-setup-the-new-legal-steward-for-vitadao/1753) – _archived_
- [VDP-161 – BIO token airdrop to the VitaDAO community](https://web.archive.org/web/20250114004345/https://gov.vitadao.com/t/vdp-161-bio-token-airdrop-to-vitadao-community/1755) – _archived_
- [VDP-164 – $500K VITARNA loan, with the senior-review digest](https://web.archive.org/web/20260421081428/https://gov.vitadao.com/t/vdp-164-vitadao-funding-proposal-500k-loan-to-advance-vitarna-through-non-glp-toxicology-toward-2026-ind-submission/2052) – _archived_
- [VitaDAO on X](https://x.com/vitadao)

## Airdrops and token distribution

URL: https://caper.network/wiki/economics/airdrops-and-token-distribution
Updated: 2026-08-02

| Mechanism | A one-off distribution of tokens to addresses selected by a rule – usually retroactive, always free to the recipient |
| --- | --- |
| Canonical example | [Uniswap’s UNI launch](https://blog.uniswap.org/uni), 16 September 2020: 400 UNI claimable by each of 251,534 addresses that had ever called the v1 or v2 contracts |
| What it buys | Holders, a claim on decentralised distribution, and – when the token is a governance token – an electorate |
| What it costs | Supply given away to recipients selected by a proxy, not by contribution; up to 66% of it sold quickly ([Messias, Yaish & Livshits 2025](https://arxiv.org/abs/2312.02752)) |
| Core design problem | Every eligibility rule is public before it is applied, so it is farmable – see [Sybil resistance in DAOs](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) |
| Related | [Liquidity mining](/wiki/economics/liquidity-mining) · [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) · [Retroactive public-goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) · [Token unlocks and vesting](/wiki/economics/token-unlocks-and-vesting) |

An **airdrop** distributes a token for free to a set of addresses chosen by a rule. In practice the rule is retroactive: a snapshot is taken of past on-chain behaviour, a formula converts that behaviour into an allocation, and anyone who matches can claim. The mechanism does three jobs at once, which is both why it is ubiquitous and why it is hard to judge. It puts a token in many hands, which is what “decentralised distribution” means to a regulator and to a market maker alike. It rewards people who used a protocol before it had a token, which is the only compensation early users ever get. And when the token carries votes, it hands out an electorate – it is a governance event, not just a marketing one.

That third job is the one the DAO industry keeps underweighting. An airdrop of a governance token is a decision about who will hold voting power for the life of the organisation, made by a team, before launch, on the basis of a proxy for contribution that everyone can read and most people can game. This page traces how the mechanism was designed, what the measurements say about whether it works, and what it does to governance afterwards.

## The Uniswap template

Uniswap’s [UNI announcement](https://blog.uniswap.org/uni) of 16 September 2020 set the shape almost every later airdrop copied. One billion UNI were minted at genesis, released over four years, split “60.00% to Uniswap community members”, 21.266% to team and future employees, 18.044% to investors and 0.69% to advisors – the last three tranches on four-year vesting. Fifteen percent of supply, 150,000,000 UNI, was distributed retroactively against a snapshot dated 1 September 2020.

The retroactive tranche is where the template lives. Four hundred UNI were claimable by each address that had ever called the [Uniswap](/wiki/daos/dexs/uniswap-dao) v1 or v2 contracts – 251,534 historical user addresses – with a pro-rata tranche of 49,166,400 UNI for the 49,192 historical liquidity providers, and 1,000 UNI each for the 220 holders and redeemers of the protocol’s SOCKS token. A flat grant for having shown up, a proportional grant for having supplied capital, and a small collector’s tranche.

Three features of that design became defaults. The snapshot predates the announcement, so behaviour after the announcement cannot qualify. Eligibility is binary at the margin – one transaction, ever, is enough. And the allocation is flat across a very wide band, so the marginal reward for the 500th transaction is zero. Each of those choices is defensible on its own and each of them is a farming instruction once the rule is known in advance.

## Designing the criteria: Optimism’s six rules

[Optimism’s](/wiki/daos/networks/optimism-collective) first airdrop is the clearest published example of an airdrop designed as a selection problem rather than a payout. Its [own documentation](https://github.com/ethereum-optimism/community-hub/blob/main/pages/op-token/airdrops/airdrop-1.mdx) records 248,699 eligible addresses against a snapshot of 25 March 2022, allocated by six distinct criteria sets – two for OP Mainnet usage and four for behaviour on Ethereum L1 – which stack, so an address matching several receives the sum.

The four L1 criteria are the interesting part, because they are explicit statements about what the Foundation wanted to buy. _DAO Voters_: 84,015 addresses at 271.83 OP each, qualifying by having voted on or authored at least one on-chain proposal or two Snapshot proposals, filtered to “active DAOs” with at least five proposals and five votes each, and – against Snapshot spam – restricted to voters in the top 99.9% of voting power in each DAO. _Multisig Signers_: 19,542 addresses. _Gitcoin Donors_: 23,925. _Users Priced Out of Ethereum_: 74,272. On top of those sat overlap bonuses that paid steeply for breadth – 2,707 addresses matching four categories, 627 matching five, and 45 matching six, the last receiving 27,534.98 OP.

Read as a governance act, this is an electorate deliberately recruited from people who had already voted somewhere else. Whether that worked is an empirical question the same document cannot answer, and the honest reading of the later turnout record on most L2 governance – see [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) – is that prior voting history bought less durable participation than the design assumed.

## Points, and the arms race with farmers

[Arbitrum](/wiki/daos/networks/arbitrum-dao) replaced criteria sets with a points score. Its [eligibility and distribution specification](https://docs.arbitrum.foundation/airdrop-eligibility-distribution) allocated 11.62% of initial supply – 1.162 billion ARB – through a scheme that awarded points for bridging, for transacting across distinct time periods of two, six and nine months, for interaction counts at 4, 10, 25 and 100 contracts, and for aggregate transaction and bridging value crossing $10,000, $50,000 and $250,000. Three points was the eligibility floor and 15 the cap; three points paid 1,250 ARB and twelve or more paid 10,250. Activity before the Nitro upgrade counted double.

The anti-farming rules are stated just as plainly, and they are subtractive rather than exclusionary: one point removed if every transaction in the wallet fell inside a single 48-hour window, and one point removed if the wallet held under 0.005 ETH and had touched fewer than two smart contracts. A wallet could lose two points and still qualify. The third rule was harder: outright disqualification for any address flagged during the [Hop protocol Sybil bounty](https://github.com/hop-protocol/hop-airdrop), an open GitHub repository where anyone could file a report clustering addresses by funding source, timing and behavioural signature.

That cross-reference is the most instructive detail in the whole episode. One protocol’s crowdsourced Sybil list became a second protocol’s disqualification input, which means the industry’s de facto identity layer for airdrops was a bug-bounty issue tracker. It also means a farmer’s cost of being caught compounds across drops, which is the only anti-Sybil pressure in the system that scales. The underlying problem does not go away: as long as eligibility is a published function of on-chain behaviour, generating qualifying behaviour is a business, and it is cheaper than the reward whenever the reward is generous.

## What the measurements show

The first broad empirical study of the mechanism, [“Airdrops: Giving Money Away Is Harder Than It Seems”](https://arxiv.org/abs/2312.02752) by Johnnatan Messias, Aviv Yaish and Benjamin Livshits (arXiv:2312.02752, submitted December 2023, last revised July 2025), examined nine major airdrops across Ethereum and Layer-2 ecosystems. Its central finding is that “a substantial share of tokens – up to 66% in some cases – are rapidly sold, often in recipients’ first post-claim transaction.”

The authors attribute the pattern to farmers who optimise against the published eligibility criteria “to extract value without contributing meaningfully to the ecosystem”, and their Arbitrum case study shows the activity spike around the snapshot failing to convert into sustained use. They name the recurring design pitfalls directly: Sybil vulnerability, poor incentive alignment, and governance-token misuse.

The last of those is the one this wiki cares most about. Selling on claim is a price event and a defensible one – a recipient who never wanted the token converts it. But a governance token sold on claim does not disappear; it moves to whoever will pay for it, which is a transfer of voting power to buyers selected by nothing except willingness to bid. An airdrop that is 66% sold has, in governance terms, run a rather inefficient token sale with extra steps. This is the sharpest practical argument for the position that distribution and enfranchisement should be separate decisions – see [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) and [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics).

## Unclaimed tokens: expire, or push

Every airdrop leaves supply unclaimed, and the two large L2 drops resolved it in opposite directions on nearly the same date. Arbitrum ran a hard claim window: claims opened at Ethereum block 16890400 on 23 March 2023 and [closed](https://docs.arbitrum.foundation/airdrop-eligibility-distribution) at block 18208000 on 24 September 2023, with unclaimed ARB returning to the DAO treasury. Optimism did the reverse – on 15 September 2023 it [sent the unclaimed OP directly](https://github.com/ethereum-optimism/community-hub/blob/main/pages/op-token/airdrops/airdrop-1.mdx) to the addresses that were eligible to claim it, ending the airdrop by delivery rather than by expiry.

The choice is a governance choice, not an operational one. Expiry concentrates the distribution on the attentive and returns the rest to a treasury the existing holders control. Pushing delivers to everyone the rule selected, including the inattentive, and creates voting power in wallets whose owners never took an action to accept it. Neither is obviously right; what matters is that the decision is usually made after the fact, by whoever controls the distributor contract, without a vote.

## How Caper approaches this

Caper has no airdrop, and the reason is structural rather than stylistic. Every governance token enters circulation through a purchase against the caper’s [bonding curve](/wiki/markets/bonding-curve) – the contract’s `buy_token` path is the only route by which supply is sold, priced off circulation at the time of the buy. There is no snapshot, no eligibility function, and therefore no rule to farm; the thing an airdrop tries to approximate with proxies is replaced by the plainest possible signal, which is that someone paid.

Voting weight is also not a straight function of the bag. A member’s weight is computed as `(held_amount × members_votes) / (vote_supply × tokens_in_circulation)` – the product of their governance holdings and their vote tokens, over the corresponding totals. Vote tokens are soulbound: they are minted directly into the voter’s account by the caper’s own state component, which is the only frame permitted to deposit them, and they are burned when the member leaves. They cannot be bought from a seller, which means the half of the weight that an airdrop would have handed out is not transferable at all.

The same expression is what a departing member redeems against. On [exit](/wiki/foundations/what-is-a-caper) a member returns both their vote tokens and their governance tokens and receives that share of the treasury – so the exit route for someone who no longer wants in is a redemption at their own weight, rather than a sale of voting power into the market. That is the specific failure mode the 66% figure above describes, addressed at the point where it occurs.

## References and further reading

- [Introducing UNI](https://blog.uniswap.org/uni) – Uniswap’s launch announcement, 16 September 2020: the genesis split, the 1 September snapshot, and the per-address retroactive allocations
- [Optimism Airdrop 1](https://github.com/ethereum-optimism/community-hub/blob/main/pages/op-token/airdrops/airdrop-1.mdx) – the Optimism community hub’s own record of the six criteria sets, the per-category address counts and allocations, and the September 2023 push of unclaimed OP
- [$ARB airdrop eligibility and distribution specifications](https://docs.arbitrum.foundation/airdrop-eligibility-distribution) – the Arbitrum Foundation’s points table, anti-Sybil deductions, and the block heights bounding the claim window
- [hop-protocol/hop-airdrop](https://github.com/hop-protocol/hop-airdrop) – the open Sybil-report repository whose flagged addresses were reused as a disqualification input by later drops
- [Airdrops: Giving Money Away Is Harder Than It Seems](https://arxiv.org/abs/2312.02752) – Johnnatan Messias, Aviv Yaish and Benjamin Livshits, arXiv:2312.02752; nine airdrops measured, up to 66% of tokens sold rapidly

Related pages: [Liquidity mining and mercenary capital](/wiki/economics/liquidity-mining) · [Mechanism design](/wiki/economics/mechanism-design) · [Sybil resistance in DAOs](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) · [Retroactive public-goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) · [Voting and delegation](/wiki/dao-governance/concepts/voting/voting-and-delegation)

## Blockchain and capital markets

URL: https://caper.network/wiki/economics/capital-markets
Updated: 2026-07-27

|  |  |
| --- | --- |
| **Topic** | How distributed-ledger technology changes capital formation and securities-market structure |
| **Key concepts** | Disintermediation, decentralized finance, transaction costs, market infrastructure |
| **Framing** | Schumpeterian creative destruction — innovation displacing incumbent firms and practices |
| **Related** | [Raising funds](/wiki/markets/raising-funds) · [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) · [Token valuation](/wiki/economics/token-valuation) · [Liquidity bootstrapping pools](/wiki/economics/liquidity-bootstrapping-pools) |

**Blockchain and capital markets** refers to the application of distributed-ledger technology to the systems through which businesses raise capital and investors hold and trade financial claims. Capital markets have historically relied on chains of intermediaries — banks, brokers, exchanges, clearinghouses, and transfer agents — to establish trust between strangers. A blockchain maintains a shared, tamper-resistant record without a central operator, which allows some of those functions to be performed by open protocols instead.

The academic literature approaches this shift from two directions: a microeconomic strand examining how decentralization changes the business models of finance, and a market-infrastructure strand that places blockchain among a succession of technologies reshaping how securities are traded and capital is raised. A macroeconomic frame comes from work on Schumpeterian creative destruction, in which technological innovation displaces incumbents and generates short-run turbulence alongside long-run productivity gains.

## Decentralized business models and disintermediation

In an influential analysis of blockchain's disruption of finance, Chen and Bellavitis argue that blockchain technology [reduces transaction costs, generates distributed trust, and empowers decentralized platforms](https://doi.org/10.1016/j.jbvi.2019.e00151), potentially providing a new foundation for decentralized business models. They draw a sharp distinction from earlier waves of financial technology: where fintech largely substituted banks with technology companies, blockchain enables true disintermediation, turning previously infeasible business models into viable ones.

The authors identify four decentralized financial business models: decentralized currencies (with Bitcoin as a form of "digital gold"), decentralized payment services, decentralized fundraising through ICOs and IEOs — directly a new capital-formation channel — and decentralized contracting through smart contracts and peer-to-peer lending, the same substrate on which [decentralized autonomous organizations](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) operate. Compared with traditional financial services, decentralized finance (DeFi) services tend to be [more decentralized, innovative, interoperable, borderless, and transparent](https://doi.org/10.1016/j.jbvi.2019.e00151). On this view, DeFi can broaden financial inclusion, facilitate open access, encourage permissionless innovation, and create new opportunities for entrepreneurs; decentralization can reduce transaction costs and create network effects without incurring the costs of monopoly.

The same analysis is explicit about the limits of the model. Key challenges include fraud vulnerabilities, cryptocurrency volatility, regulatory uncertainty, and technical constraints. Building distributed trust on decentralized platforms can itself be costly, and decentralized systems face tensions between transparency and privacy as well as gaps in accountability.

## The economics of technology in securities markets

The disintermediation thesis sits within a broader economics literature on technology and market structure. Malinova surveys the [economic implications of fintech innovation for securities and capital markets](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3461760), outlining the key economic issues, reviewing the relevant literature, and identifying open questions. The survey is organized around the technological developments affecting capital-market infrastructure and data analytics — electronic trading venues and high-frequency trading, blockchain technology, cloud computing, and machine learning — placing distributed ledgers as one of several forces remaking market plumbing rather than an isolated phenomenon. It also covers new investment and financing tools enabled by these advances, including exchange-traded funds and blockchain-based assets: technology reshaping both the trading side and the capital-raising side of markets. How such blockchain-based assets are priced is treated separately under [token valuation](/wiki/economics/token-valuation).

## Creative destruction and uncertainty

The macroeconomic frame for episodes in which a new technology displaces incumbent practices is Schumpeterian creative destruction. Sedláček models [counter-cyclical uncertainty fluctuations as a by-product of technology growth](https://doi.org/10.1093/jeea/jvz047): in a firm-dynamics model with endogenous technology adoption, faster technology growth widens the dispersion of firm-level productivity shocks, a benchmark measure of uncertainty. Faster technology growth spurs a creative-destruction process in which firms adopting the newest technology vintage enjoy productivity gains and create jobs, while non-adopters face rising labor costs, shed workers, and shut down more often — producing a temporary "Schumpeterian downturn." In contrast to uncertainty-driven business-cycle models, these uncertainty spikes are associated with positive long-run effects: aggregate productivity rises as more firms adopt the leading technology and obsolete production units are weeded out.

The empirical evidence supports this mechanism. Structural VARs on U.S. data from 1977 to 2014 show that after positive technology shocks, firm-level uncertainty, job creation, and job destruction all rise while aggregate employment falls temporarily. On average, about one quarter (27%) of the business-cycle variation in uncertainty is driven by technology shocks alone, and [more than two thirds of the uncertainty spike around the 2001 dot-com bubble was growth-driven](https://doi.org/10.1093/jeea/jvz047), whereas the Great Recession spike was essentially unrelated to technology shocks.

This framework offers a lens for interpreting volatility in blockchain finance: the dot-com episode shows that turbulence and elevated uncertainty accompanying a genuine technology wave can coexist with underlying productive change. Whether blockchain-based finance follows the same pattern is an empirical question the model does not itself address.

## Relevance to Caper

Launchpads occupy the primary-market layer of decentralized finance. Where traditional capital formation is episodic and gated — an IPO or venture round occurs once, on negotiated terms, through intermediaries — a launchpad makes capital formation continuous and permissionless. On Caper, [capers](/wiki/foundations/what-is-a-caper) raise capital through bonding-curve markets that quote a continuous price, and token holders govern through on-chain proposals; see [raising funds](/wiki/markets/raising-funds). This places launchpad fundraising within the decentralized-fundraising business model that Chen and Bellavitis identify as a new capital-formation channel, implemented as standing market infrastructure rather than a one-off issuance event.

## References

1. Yan Chen and Cristiano Bellavitis (2020). [Blockchain disruption and decentralized finance: The rise of decentralized business models](https://doi.org/10.1016/j.jbvi.2019.e00151). Journal of Business Venturing Insights, Vol. 13, e00151.
2. Katya Malinova (2019). [Economics of Technology, Securities and Capital Markets](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3461760). SSRN Working Paper No. 3461760.
3. Petr Sedláček (2020). [Creative Destruction and Uncertainty](https://doi.org/10.1093/jeea/jvz047). Journal of the European Economic Association, Vol. 18, Issue 4, pp. 1814–1843.

## Commons governance and collective action

URL: https://caper.network/wiki/economics/commons-governance
Updated: 2026-08-12

|  |  |
| --- | --- |
| **Topic** | Collective action; common-pool resources; institutional economics of self-governance |
| **Key figures** | Elinor Ostrom, Garrett Hardin, Michael Cox |
| **Core claim** | Communities can and do govern a shared resource without privatization or a central authority — when their institutions satisfy a set of empirically recurring design principles |
| **Related** | [Schelling points and coordination](/wiki/economics/schelling-points) · [Transaction costs and property rights](/wiki/economics/transaction-costs) · [How DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) |

## The tragedy of the commons — and why it is not inevitable

In 1968 the ecologist Garrett Hardin argued in [“The Tragedy of the Commons”](https://www.garretthardinsociety.org/articles/art_tragedy_of_the_commons.html) (_Science_ 162, 1243–1248) that a resource open to all is doomed: each user rationally takes as much as they can, the costs are shared by everyone, and the resource collapses. Hardin saw only two escapes — privatize the resource, or hand it to a coercive central authority (“Leviathan or private property”).

The political economist **Elinor Ostrom** spent four decades showing that this dichotomy is false. Studying real irrigation systems, fisheries, forests and pastures that had been managed sustainably for centuries, she documented a third path: **self-governance by the users themselves**. In 2009 she became the first woman awarded the Nobel Memorial Prize in Economic Sciences, [“for her analysis of economic governance, especially the commons”](https://www.nobelprize.org/prizes/economic-sciences/2009/ostrom/facts/) (shared with Oliver Williamson).

Her central correction: Hardin’s tragedy describes _open access_ (no rules, no boundary, no accountability), not a _commons_. A commons is a common-pool resource governed by an identifiable community under rules that the community makes and enforces. The interesting question is not _whether_ commons can survive but _which institutional arrangements_ let them survive — the subject of her 1990 book [_Governing the Commons_](https://www.cambridge.org/core/books/governing-the-commons/A8BB63BC4A1433A50A3FB92EDBBB97D5) (Cambridge University Press).

## Ostrom’s eight design principles

From the cases that endured, Ostrom distilled eight **design principles** — institutional features that long-lived, self-governed commons share. They are descriptive regularities, not a blueprint, but they hold up: a 2010 review by Michael Cox and colleagues, [“A Review of Design Principles for Community-based Natural Resource Management”](https://ecologyandsociety.org/vol15/iss4/art38/main.html) (_Ecology and Society_ 15(4):38), re-examined 91 studies and found the principles broadly empirically supported, refining the original eight into eleven.

The refinement is worth reading rather than citing, because it says which principles carry the empirical weight. Cox and colleagues coded **91 studies covering 77 cases**, and every principle came out with at least twice as many supportive as unsupportive cases; a Fisher’s exact test between the presence of a principle and reported success was significant at the 5% level for all of them _except_ principle 8, nested enterprises, which reached only 10%. Their reformulation splits principles 1, 2 and 4 in two and leaves 3, 5, 6, 7 and 8 exactly as Ostrom wrote them — which is how eight becomes eleven. Boundaries divide into **user** boundaries and **resource** boundaries (the first strongly supported, the second only moderately); congruence divides into congruence with local conditions and the proportionality of appropriation to provision; and monitoring divides into **social** monitoring, users watching one another, and **environmental** monitoring, users watching the resource. Cox notes that this last split is deliberately not the one used in the coding, where the two halves were the presence of monitors at all (moderately supported) and whether those monitors were themselves community members (very strongly supported) — the single strongest result in the review, and the one that most directly contradicts the instinct to hire an outside auditor.

1. **Clearly defined boundaries.** Who has rights to the resource, and where the resource ends, are both unambiguous.
2. **Congruence.** The rules for taking from and contributing to the commons fit local conditions, and benefits are proportional to costs.
3. **Collective-choice arrangements.** Most of those affected by the rules can participate in changing them.
4. **Monitoring.** Monitors who watch resource conditions and behaviour are accountable to the users — often are the users.
5. **Graduated sanctions.** Violations draw penalties that escalate with severity and history, not a single all-or-nothing punishment.
6. **Conflict-resolution mechanisms.** Cheap, fast, local arenas exist to resolve disputes among users and with officials.
7. **Minimal recognition of rights to organize.** External authorities do not challenge the community’s right to devise its own institutions.
8. **Nested enterprises.** For larger systems, governance is organized in multiple layered tiers rather than one monolithic body.

## Polycentric governance

The eighth principle points to Ostrom’s wider thesis, set out in her Nobel lecture [“Beyond Markets and States: Polycentric Governance of Complex Economic Systems”](https://www.nobelprize.org/uploads/2018/06/ostrom_lecture.pdf) (2009). Complex resource problems are best handled not by a single global optimizer but by **many overlapping, semi-autonomous decision centres** — polycentricity — that each operate at their own scale and interact through rules of mutual adjustment. No unit is sovereign over the whole; robustness comes from redundancy and local adaptation rather than central design.

This is a direct rejection of the Leviathan-or-market framing. It also anticipates a structural pattern that reappears in [subDAOs and working groups](/wiki/dao-governance/concepts/membership/subdaos-and-working-groups): a treasury or protocol that grows past what one assembly can competently govern tends to fracture into nested units with delegated scope.

## DAOs as digital commons

A DAO treasury is a textbook common-pool resource: a shared pool that any member can draw on, where one member’s spending diminishes what remains for the rest. That makes Ostrom’s principles a useful lens for reading DAO mechanism design — and for reading [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail), which is usually a failure to satisfy one of them:

- **Boundaries** → token-holding or membership NFTs define who may draw on the treasury and vote; weak [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) is a broken boundary.
- **Collective choice** → on-chain [proposals](/wiki/governance/proposals) and voting are the arena where members change the rules.
- **Monitoring** → a public ledger makes every transfer observable, the cheapest monitoring institution ever built.
- **Graduated sanctions** → slashing, streaming with clawback, and [rage-quit / exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) escalate consequences short of expulsion.
- **Conflict resolution** → [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance), dispute oracles and challenge windows are the low-cost arenas Ostrom’s sixth principle calls for.
- **Nested enterprises** → subDAOs, pods and grant programs give a large DAO the polycentric structure the eighth principle predicts.

Where the principles are hard to satisfy on-chain, the failure modes are predictable: absent monitoring incentives, a [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) is quietly captured; absent a real conflict-resolution arena, disputes escalate straight to forks and exits. The recurring lesson from [institutional economics](/wiki/economics/transaction-costs) holds here — with positive transaction costs, the rules and who gets to make them determine the outcome.

## Principle 3 and the delegated commons

The principle a DAO is most likely to satisfy on paper and lose in practice is the third: _most of those affected by the rules can participate in changing them_. Token voting satisfies it by construction, and then the DAO discovers that an electorate cannot be summoned for routine business and starts handing recurring decisions to committees, stewards and auto-adjusting modules. Each of those grants is rational on its own terms, and collectively they move rule-making out of the arena where the affected users sit.

Ostrom's framework does not forbid this — principle 8 explicitly expects layered, nested decision centres in any large system — but it does supply the test. A nested tier is legitimate in her account when the users retain the ability to constitute and re-constitute it; a mandate that never expires and is never revisited is a tier the users no longer choose. That is the distinction [standing authorizations and delegated mandates](/wiki/dao-governance/concepts/treasury/standing-authorizations) examines mechanism by mechanism, and the reason it turns out that DAOs bound delegated authority by magnitude, direction and frequency but almost never by duration. Read against principle 3, an expiry is not an extra safeguard; it is the thing that keeps the delegation a delegation.

The measurable version of the failure is not a lost vote but the absence of votes beside continuing treasury activity, which is exactly the diagnostic Ostrom's monitoring principles ask a commons to run on itself — and the review above found that monitoring works best when the monitors are the users. See also [voter apathy](/wiki/dao-governance/concepts/analysis/voter-apathy) and [council dissolution](/wiki/dao-governance/concepts/analysis/council-dissolution).

## How Caper approaches this

Caper’s answer leans hardest on Ostrom’s first and sixth principles — a hard boundary and a cheap way out of a dispute. Every member holds a **credible, priced exit**: rather than being outvoted and locked in, a member can always leave and withdraw their canonical share of the common treasury. That share is not negotiated or discretionary — it is the same weight the protocol uses for voting, fixed by formula.

Because the exit is costless and formula-fixed, a faction that captures a majority cannot strand a minority in a treasury it no longer trusts — the minority walks with its share. In Ostrom’s terms, a guaranteed exit is both a clear boundary and a low-cost conflict-resolution mechanism, and it changes the collective-action calculus before any vote is cast. See [what is a caper](/wiki/foundations/what-is-a-caper) and [rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights).

## References

- Garrett Hardin, [“The Tragedy of the Commons”](https://www.garretthardinsociety.org/articles/art_tragedy_of_the_commons.html), _Science_ 162 (1968), 1243–1248.
- Elinor Ostrom, [_Governing the Commons: The Evolution of Institutions for Collective Action_](https://www.cambridge.org/core/books/governing-the-commons/A8BB63BC4A1433A50A3FB92EDBBB97D5), Cambridge University Press, 1990.
- The Nobel Prize, [Elinor Ostrom — Facts (2009)](https://www.nobelprize.org/prizes/economic-sciences/2009/ostrom/facts/).
- Elinor Ostrom, [“Beyond Markets and States: Polycentric Governance of Complex Economic Systems”](https://www.nobelprize.org/uploads/2018/06/ostrom_lecture.pdf), Nobel Prize Lecture, 2009.
- Michael Cox, Gwen Arnold & Sergio Villamayor-Tomás, [“A Review of Design Principles for Community-based Natural Resource Management”](https://ecologyandsociety.org/vol15/iss4/art38/), _Ecology and Society_ 15(4):38, 2010.

## Curation markets

URL: https://caper.network/wiki/economics/curation-markets
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Topic** | Token-based mechanisms for putting staked capital behind community curation of lists, recommendations, and projects |
| **Introduced by** | Simon de la Rouviere (2017) |
| **Key mechanism** | Continuous token minting and redemption along a bonding curve; tokens staked to signal support |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve) · [Token valuation](/wiki/economics/token-valuation) · [Voting mechanisms](/wiki/governance/voting-mechanisms) |

**Curation markets** are crypto-economic mechanisms in which a community buys, holds, and stakes tokens attached to a shared topic — a list, a set of recommendations, a registry of projects — so that token prices and staking patterns serve as a continuously updated, financially backed signal of what deserves attention. Because influencing the signal requires putting capital at risk, curation markets give participants skin in the game: curators who back valuable entries share in the value created around the topic, while those who back poor ones stand to lose their stake.

The model was introduced by Simon de la Rouviere in 2017, and related designs from the same period include curved token bonding and token-curated registries. It also attracted early criticism — notably from de la Rouviere himself — for incentive failures that can reward virality over quality.

## Continuous token models

The founding proposal, published in May 2017, defined a curation market as a model that [allows groups to more effectively coordinate and earn from value they co-create around shared goals](https://medium.com/@simondlr/introducing-curation-markets-trade-popularity-of-memes-information-with-code-70bf6fed9881). Rather than selling a fixed supply through an initial coin offering, the market mints its token continuously: anyone can buy new tokens at a price that grows more expensive as more tokens are in circulation, with payments accumulating in a communal deposit. Holders then bond their tokens to curators per sub-topic, who curate information with backing proportional to the tokens staked behind them, and any holder can exit by burning tokens to withdraw a proportional share of the deposit. The proposal shipped with alpha smart-contract code for Ethereum.

De la Rouviere elaborated the pricing side later that year as [curved token bonding](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5): the buy price is hardcoded according to an algorithmic curve of the current supply, the reserve remains locked in the smart contract rather than held by any party, and holders sell back into the communal pool along a sell curve. This gives the token continuous liquidity without an ICO, and because tokens are cheaper when supply is low, early buyers receive more tokens for the same price — a built-in reward for early, correct signalers. The effect is to make curation liquid: the token's market price functions as a standing, tradable [valuation](/wiki/economics/token-valuation) of the topic itself. Projects adopting bonding curves for curation and coordination at the time included Meme Factory, Ocean Protocol, 1Hive, Zap Store, and OSCoin.

## Token-curated registries

A closely related design is the token-curated registry (TCR), specified by Mike Goldin in [Token-Curated Registries 1.0](https://medium.com/@ilovebagels/token-curated-registries-1-0-61a232f8dac7) as a scheme for producing curated lists. A candidate seeking listing stakes a minimum deposit denominated in the registry's intrinsic token; any token holder may challenge the application by matching that deposit; and a [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting), [commit-reveal vote](/wiki/governance/voting-mechanisms) among holders decides the outcome. The loser's forfeited deposit is split, with a fixed dispensation percentage paid to the winning party and the remainder distributed to voters on the majority side. Goldin's incentive argument is that while token holders have a tactical incentive to reject every candidate and collect forfeited deposits, they hold a stronger strategic interest in a registry that is valuable and non-empty, because the token's worth depends on the quality of the list it curates.

## The desire-paths metaphor

In a 2018 essay, [Desire Paths & Markets for Recommendation](https://medium.com/@simondlr/desire-paths-markets-for-recommendation-e701aa835013), de la Rouviere borrowed the landscape notion of desire paths — the worn grass trails that emerge from repeated walking, as against officially paved pathways — as an analogy for crypto-economic protocol design. In his formulation, “the rules become desire paths: we follow them because others paved the way”: communities entrench in existing systems through familiarity rather than because those systems are optimal. The essay also stresses how many interdependent parameters these designs involve — supply, collateral, pricing functions, and, in token-curated registries, “even more knobs to consider” — which makes outcomes hard to predict once the rules are immutably encoded on-chain.

## Incentive problems and markets for recommendation

The same essay warns that naive curation markets carry perverse incentives: applied directly, they can promote viral information without substance over quality information, an effect de la Rouviere compares to Bitcoin's unintended energy-consumption incentives. His playlist example is illustrative: “Applying a curation market directly to a playlist might lead to the most viral playlist, not the most nuanced playlist.”

The proposed mitigation is to reframe curation markets as _markets for recommendation_: rather than treating the market's output as the sole source of truth, it serves as a recommendation layer with human oversight — in the playlist case, the market produces recommendations for the playlist owner to choose from and add. De la Rouviere acknowledges the trade-off that “having human (or other) stop-gaps does mean that social scalability is hampered somewhat,” but argues that accepting such “meatspace interference” lets designers learn from live markets and “start with curation markets much sooner.” He frames this graduated, human-in-the-loop approach as a way to experiment with token-bonded signaling while reducing the risk of system-wide failure from mis-designed immutable incentives.

## What became of the design

Curation markets and token-curated registries were widely discussed between 2017 and 2019 and are, as deployed mechanisms, largely dormant. The code is the clearest record. Goldin’s [generic TCR reference implementation](https://github.com/skmgoldin/tcr) last received a commit in **March 2022**. The [adChain registry contracts](https://github.com/AdChain/AdChainRegistry), the design’s flagship deployment and the case study the TCR 1.0 paper was written around, last received one in **February 2018**. District0x’s [Meme Factory](https://github.com/district0x/memefactory), the best-known consumer application of a curved-bonding curation market, last received one in **June 2023**. The `adchain.com` domain is live, but it now fronts a digital-advertising verification product rather than a token-curated registry.

What outlived the market is the primitive underneath it. The TCR’s core loop, stake a deposit, let anyone challenge it by matching the stake, resolve by token vote, and split the loser’s forfeit between the winner and the voters who backed them, is recognisably the structure of decentralised arbitration and of optimistic dispute resolution: see [Kleros](/wiki/dao-governance/tooling/voting/kleros) and [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance). The pricing half also survived on its own, detached from curation, in [bonding curves](/wiki/markets/bonding-curve) and in [liquidity bootstrapping pools](/wiki/economics/liquidity-bootstrapping-pools). The part that did not survive is the specific claim these designs were built on: that a token price is a good enough proxy for quality to be used as the output itself. De la Rouviere’s own 2018 correction, that a curation market should feed a recommendation layer with a human in the loop rather than serve as the source of truth, reads in hindsight less like a refinement than like the reason the pure form was not deployed at scale.

## How Caper approaches this

A launchpad is itself an attention-allocation problem: many projects compete for a limited pool of capital and community focus. Caper, a DAO launchpad on the Radix network, applies the core logic of curation markets to [raising funds](/wiki/markets/raising-funds): backers put capital at risk in a project's token and receive governance rights along with guaranteed sellback liquidity — mechanics directly analogous to the buy and sell sides of a [bonding curve](/wiki/markets/bonding-curve). A project token's price thus operates as a liquid, standing signal of how much support the community believes that project deserves, and backers can exit if that belief changes. The incentive caveats above apply equally: pure price signals can reward visibility over substance, which is one argument for pairing market signals with the governance rights backers hold rather than treating the market as the sole arbiter of merit.

## References

1. Simon de la Rouviere (2017). [Introducing Curation Markets: Trade Popularity of Memes & Information (with code)!](https://medium.com/@simondlr/introducing-curation-markets-trade-popularity-of-memes-information-with-code-70bf6fed9881). Medium.
2. Simon de la Rouviere (2017). [Tokens 2.0: Curved Token Bonding in Curation Markets](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5). Medium.
3. Mike Goldin (2017). [Token-Curated Registries 1.0](https://medium.com/@ilovebagels/token-curated-registries-1-0-61a232f8dac7). Medium.
4. Simon de la Rouviere (2018). [Desire Paths & Markets for Recommendation](https://medium.com/@simondlr/desire-paths-markets-for-recommendation-e701aa835013). Medium.

## Fee switches and value accrual

URL: https://caper.network/wiki/economics/fee-switches-and-value-accrual
Updated: 2026-08-09

| Concept | Fee switch — diverting a share of protocol revenue from service providers to the DAO and its token |
| --- | --- |
| Also called | Protocol fee, value accrual, revenue switch |
| Who pays | Usually liquidity providers or lenders, out of fees they previously kept in full |
| Where the money goes | Burn · open-market buyback · distribution to stakers · retained treasury |
| Landmark case | Uniswap — voted on from 2021, activated December 2025 by [UNIfication (proposal 93)](https://vote.uniswapfoundation.org/proposals/93) |
| Related | [Liquidity mining](/wiki/economics/liquidity-mining) · [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) · [Token valuation](/wiki/economics/token-valuation) |

A **fee switch** is a governance-controlled parameter that takes a slice of the fees a protocol already charges its users and routes it to the protocol itself rather than to the people supplying the service. It is the mirror image of [liquidity mining](/wiki/economics/liquidity-mining): where liquidity mining pays tokens _out_ to rent capital, a fee switch brings revenue _in_, and the governance question shifts from how much to emit to who receives the income and in what form. Because the fee comes out of someone's existing revenue — usually liquidity providers — turning one on is a redistribution inside the protocol's own economy, not free money, which is why the largest DAOs argued about it for years before flipping the switch.

## What a fee switch actually switches

Most DeFi protocols charge a fee at the point of use: a swap fee on an [automated market maker](/wiki/economics/capital-markets), an interest spread on a lending market, a redemption fee on a stablecoin. In the standard design that fee is paid entirely to the counterparties who take the risk — liquidity providers, depositors, stakers. A fee switch inserts a second recipient: the contract keeps a configurable fraction and sends it somewhere the DAO controls.

The switch itself is usually trivial in code — a factory owner setting a fee numerator — and hard in governance, for three reasons that recur in every fee-switch debate:

- **It is taken from someone.** Raising the protocol's cut lowers LP returns, and liquidity is mobile; a protocol that taxes its LPs while a fee-free fork exists invites them to leave.
- **It changes what the token is.** A token that receives a stream of protocol revenue looks materially more like a security in several jurisdictions than one that only votes, which kept counsel cautious and votes non-binding for years.
- **It forces a distribution question.** Once revenue exists, governance must decide between burning it, buying the token back, paying it to stakers, or banking it — and each choice creates a different constituency inside the DAO.

## Four years of votes, no fee: the Uniswap record

[Uniswap](/wiki/daos/dexs/uniswap-dao)'s governance record is the clearest primary-source account of how long the question stayed open. The [Snapshot space](https://snapshot.box/#/s:uniswapgovernance.eth) shows a fee-switch vote as early as 25 July 2021 (“Turning on the fee switch for V2”, 354 voters), a July 2022 temperature check for ETH/USDC and USDC/USDT pools, a consensus check for a three-pair pilot that closed 9 August 2022 with 2,373 voters, a three-part “Making Protocol Fees Operational” vote on fee options, deployment chain and treasury asset that closed 1 June 2023, and a “V3 Fees: Factory Owner Amendment” vote that closed 9 March 2024 with 50.2M UNI of weight behind it.

None of them resulted in a fee being charged in production. The pattern — repeated large-turnout votes in favour of the principle, followed by no on-chain activation — is itself the lesson: a fee switch is not blocked by the vote count but by the legal, competitive and operational questions that sit underneath it. Uniswap only began charging protocol fees on Ethereum mainnet in late December 2025.

## UNIfication: what turning it on looked like

The change arrived as a single bundled proposal, [UNIfication](https://blog.uniswap.org/unification), which passed with [125,342,017 UNI for and 742 against](https://vote.uniswapfoundation.org/proposals/93) and executed on 28 December 2025. It is worth reading as a template, because it shows how much rides alongside the switch:

- **The fee.** On v2, the LP fee drops from 0.30% to 0.25% and the protocol takes 0.05% — the LPs pay for it directly. On v3 the protocol fee is one quarter of the LP fee in smaller pools and one sixth in larger ones, rolled out first across the pools representing most of mainnet LP fees.
- **The destination is a burn, not a treasury.** Fees are used to remove UNI from circulation rather than to fund the DAO, sidestepping the question of who spends the money.
- **A retroactive burn.** Exactly 100,000,000 UNI was sent from the Timelock to [0x000…dEaD](https://eth.blockscout.com/address/0x000000000000000000000000000000000000dEaD) in the execution transaction, as an estimate of what the switch would have destroyed had it been live since launch. "Burn" is the convention rather than the mechanism: the UNI contract has no burn function, so the _supply itself never moves_ — it is still exactly 1,000,000,000 UNI, with 10.8% of it now parked at an address nobody holds a key to. The on-chain detail is on [Uniswap DAO](/wiki/daos/dexs/uniswap-dao).
- **Adjacent revenue.** Unichain sequencer fees, net of L1 data costs and the 15% share to Optimism, feed the same burn; the proposal put those at roughly $7.5M annualised.
- **An offsetting spend.** The same proposal created a 20M UNI annual growth budget paid quarterly from 1 January 2026, and moved Foundation operations into Uniswap Labs — deflation on one side, an ongoing issuance commitment on the other.

## The burn is a market, not a transfer

The mechanism Uniswap shipped is more interesting than “fees buy tokens.” Fees accumulate on each chain in a _TokenJar_, and searchers claim those accumulated fees by paying UNI, which is bridged back to Ethereum mainnet and sent to the burn address — on Arbitrum Orbit chains through a releaser contract named `ArbitrumOrbitResourceFirepit`. The protocol never has to sell the fee assets or hold an inventory: it auctions them to searchers and denominates the price in the token it wants destroyed, which is why the burn works identically on any chain the DEX deploys to.

By the [July 2026 Robinhood Chain expansion vote](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xc5fd6e916655b293c903b060906c994ff1ff1df348336b3b3e22ceecd2d13d7c), protocol fees had reached ten chains beyond mainnet — Arbitrum, Base, OP Mainnet, Worldchain, X Layer, Soneium, Zora, Celo, BNB Chain and Polygon — and the same proposal records a single-day record of 186,000 UNI burned in June 2026. Uniswap deployed to Robinhood Chain at that chain's 1 July 2026 mainnet debut and crossed $1bn of cumulative swap volume there within ten days.

UNIfication also changed the _governance_ of the parameter, not just its value: fee-parameter proposals now skip the RFC stage and go straight to a five-day Snapshot followed by an on-chain vote. A fee switch that is expected to move often needs a fast path, and building one is part of the design. The [v4 protocol fee activation](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x3fda3c04fa106ad45173011ef4dfa5db2f14cd35c3c3a7a40f067a44cbadd5f4) ran through it in July 2026 and drew the first substantial dissent of the rollout — 19.3M UNI for against 1.0M explicitly opposed, from 132 voters.

## Where the revenue goes: four routes

Once a protocol collects revenue, four destinations dominate practice, and each one distributes benefit differently:

- **Burn.** Revenue buys the governance token and destroys it. The benefit is spread pro-rata across every holder through supply reduction, requires no claim, and creates no ongoing entitlement — the Uniswap route.
- **Buyback and hold.** Revenue buys the token into a treasury or trust rather than destroying it, keeping the tokens available for future use. It is reversible, which is both the feature and the objection.
- **Distribution to stakers.** Revenue is paid to holders who lock or stake, concentrating the benefit on committed holders — the [vote-escrow](/wiki/dao-governance/concepts/voting/vote-escrow) logic applied to income rather than emissions, and the version that most resembles a dividend.
- **Retention.** Revenue simply accrues to the [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) and is spent by proposal. Maximum flexibility, minimum legibility — holders get nothing until governance decides they do.

The choice is not primarily financial. Burning and distributing hand value to holders automatically; retaining hands it to whoever controls the proposal process. A DAO with weak [participation](/wiki/dao-governance/concepts/analysis/voter-apathy) that retains revenue is choosing to concentrate power, whatever the spreadsheet says.

## Aave: what a discretionary buyback does under stress

[Aave](/wiki/daos/lending/aave-dao) took the buyback route and its governance forum documents, unusually clearly, what happens when revenue falls. The [Aavenomics implementation](https://governance.aave.com/t/arfc-aavenomics-implementation-part-one/21248) gave a finance committee a mandate to buy AAVE on the secondary market at $1M per week. In [March 2026 the DAO proposed cutting the programme](https://governance.aave.com/t/arfc-buyback-program-budget-adjustment/24229) from roughly $50M to $30M a year — about $577K a week, down from $962K — citing borrow fee revenue roughly 25% off its peak, with January 2026 at $7.95M against $13.5M in January 2025.

Then the buybacks stopped altogether. A [forum thread opened 18 May 2026](https://governance.aave.com/t/restart-aave-buy-backs/24936) asked governance to restart them, with contributors noting that the pause landed while the token traded far below its highs — exactly when a confidence-signalling buyback is most wanted and least affordable. The thread closed in July without a decision recorded in it; the direction governance took instead was to remove the discretion, replacing committee-executed purchases with an automated, non-discretionary engine.

That arc is the general lesson of discretionary value accrual: a buyback funded from revenue and executed by a committee is procyclical twice over — the revenue falls when the market falls, and the committee's appetite falls with it. Automation is not a yield improvement; it is a governance decision to remove a lever that gets pulled at the worst time.

## Jupiter: the allocation itself becomes the recurring vote

[Jupiter](/wiki/daos/dexs/jupiter) routes 50% of protocol fees into buying JUP for its _Litterbox Trust_, with the other half funding development, operations, incentives and ecosystem growth. Because that split is a governance parameter rather than a constant, it becomes a standing subject of debate: a [proposal posted 30 May 2026](https://discuss.jup.ag/t/increase-the-litterbox-buyback-allocation-from-50-to-70/40136) asks to raise the buyback allocation from 50% to 70% and to burn the purchased tokens outright instead of holding them in trust, which would cut the operating budget to 30%.

This is the fee switch's second-order effect and the one DAO treasurers should plan for. Turning it on does not settle anything — it converts an operating budget into a percentage that holders can vote to reduce, and every subsequent bull market makes “burn more, spend less” an easy proposal to write and a hard one to argue against.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no fee switch to vote on, because the fee is on from the first trade. Every buy and sell against the [bonding curve](/wiki/markets/bonding-curve) pays a trade fee — 0.5% in the deployed contract — taken off the gross. The buy-side fee is deposited into that caper's own treasury as part of the same call that mints the tokens; the sell-side fee goes to the $CAPER treasury at the protocol level. The rate is a protocol parameter set by the admin key, not a per-DAO governance decision, so no individual caper spends a governance cycle arguing about whether to charge one.

Nothing is burned and nothing is bought back. Fee revenue accumulates in the treasury, and holders reach it two ways: a [proposal](/wiki/governance/proposals) that spends it, or [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights), which pays out a share of the treasury computed from the holder's canonical vote weight — a function of both their governance tokens and their vote tokens — and burns their vote tokens on the way out. That is a deliberately narrower design than the ones above: the accrual question is settled in code, and what remains for governance is the spending question.

## References

- [Uniswap Labs & Uniswap Foundation — UNIfication (proposal blog post)](https://blog.uniswap.org/unification)
- [Uniswap governance — Proposal 93: UNIfication (final tally and execution record)](https://vote.uniswapfoundation.org/proposals/93)
- [Uniswap Snapshot — [Temp Check] Activate v4 Protocol Fees (July 2026)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x3fda3c04fa106ad45173011ef4dfa5db2f14cd35c3c3a7a40f067a44cbadd5f4)
- [Uniswap Snapshot — [Temp Check] Protocol Fee Expansion: Robinhood Chain (July 2026, TokenJar and firepit burn path)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xc5fd6e916655b293c903b060906c994ff1ff1df348336b3b3e22ceecd2d13d7c)
- [Uniswap Snapshot space — full fee-switch voting record, 2021–2026](https://snapshot.box/#/s:uniswapgovernance.eth)
- [Aave governance — [ARFC] Aavenomics implementation: Part one](https://governance.aave.com/t/arfc-aavenomics-implementation-part-one/21248)
- [Aave governance — [ARFC] Buyback Program: Budget Adjustment (March 2026)](https://governance.aave.com/t/arfc-buyback-program-budget-adjustment/24229)
- [Aave governance — Restart AAVE buy backs (May 2026)](https://governance.aave.com/t/restart-aave-buy-backs/24936)
- [Jupiter Research — Increase the Litterbox buyback allocation from 50% to 70% (May 2026)](https://discuss.jup.ag/t/increase-the-litterbox-buyback-allocation-from-50-to-70/40136)

## Harberger taxes

URL: https://caper.network/wiki/economics/harberger-taxes
Updated: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | Property-rights and taxation mechanism |
| **Also known as** | Common ownership self-assessed tax (COST); self-assessed licenses |
| **Key trade-off** | Allocative efficiency vs. investment efficiency |
| **Related** | [Voting mechanisms](/wiki/governance/voting-mechanisms), [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management), [Transaction costs and property rights](/wiki/economics/transaction-costs) |

A **Harberger tax** is a property arrangement defined by two rules: owners publicly self-assess the value of what they hold and pay a recurring tax on that declared value, and anyone may buy the asset at any time by paying the declared price. Understating the value invites a forced sale; overstating it inflates the tax bill. The combination pushes owners toward honest valuations and keeps every taxed asset perpetually for sale.

The [mechanism](/wiki/economics/mechanism-design) was formalized by Eric Posner and E. Glen Weyl as the [common ownership self-assessed tax (COST)](https://academic.oup.com/jla/article/9/1/51/3572441), and it has since been studied as a design for public resource licensing and adopted by blockchain developers as a template for always-for-sale digital assets.

## Mechanism

Under conventional private property, an owner who does not wish to sell can hold out for a price far above their true valuation. A widely read 2018 explainer by Simon de la Rouviere argues that the Harberger forced-sale rule [eliminates this seller holdout](https://medium.com/@simondlr/what-is-harberger-tax-where-does-the-blockchain-fit-in-1329046922c6): because anyone can take the asset at its self-assessed price, owners can no longer demand inflated prices, removing a deadweight loss that otherwise blocks assets from flowing to more productive users — a central concern in the economics of [transaction costs and property rights](/wiki/economics/transaction-costs).

The gain is not free. As the same explainer summarizes:

> Harberger tax reduces investment efficiency at a gain in allocative efficiency of ownership.

An owner who may be bought out at any moment has weaker incentives to improve the asset. Posner and Weyl's analysis of COST quantifies the trade: with tax rates of roughly 2.5–7% per year, the scheme captures an estimated 70–90% of the maximum possible allocative welfare gains, while investment distortions consume only about 10–20% of those gains.

## Investment versus allocative efficiency

The formal treatment of this trade-off is given by E. Glen Weyl and Anthony Lee Zhang in [_Depreciating Licenses_](https://www.aeaweb.org/articles?id=10.1257/pol.20200426) (2022). They show that no existing license design achieves the first-best on both margins: perpetual tradable licenses give owners strong incentives to invest but let them hold out for high prices in secondary markets, distorting reallocation, while short-term licenses allocate efficiently but destroy the incentive to invest.

Their proposed instrument, the depreciating license, is a perpetual license that decays at a chosen rate τ. Each period the administrator issues a fraction τ of new equity in the license and sells it in a second-price auction; the incumbent, holding the remaining 1−τ, either buys out the administrator's share at τ times the second-highest bid or sells to a higher bidder. The design is an explicit partial property right interpolating between short-term rental (τ = 1: fully allocatively efficient, no investment incentive) and perpetual ownership (τ = 0: fully investment efficient, distorted allocation).

The paper's main theorem is that the optimal depreciation rate lies strictly between these extremes: adding a small amount of depreciation to a perpetual license yields a first-order allocative welfare gain, through reduced markups, at only a second-order investment cost — and symmetrically at the rental end. Absent investment and private values, τ leaves total government revenue unchanged; when they are present, depreciation reduces revenue relative to perpetual sale, but the loss is second-order near τ = 0, so an administrator weighing revenue against welfare still optimally sets τ above zero. Extensions covering transaction costs, private-valued investments, additional competing buyers, and multi-period investment payoffs lower the optimal rate but never push it to a corner. Weyl and Zhang target real-world resource licensing — radio spectrum, fishing rights, pollution permits, mineral extraction rights, and land — and note that pricing the reclaimed share by competitive auction rather than owner self-assessment addresses a key critique of pure Harberger-style self-assessed taxes.

## Blockchain experiments

De la Rouviere's explainer also argued that blockchains are natural infrastructure for Harberger property: property registries (cadastres) map well onto immutable ledgers, and smart contracts can enforce the tax and forced-sale rules automatically. It identified NFTs and virtual worlds such as Decentraland as closed-loop economies suited to low-stakes experimentation, sketched concrete designs — Harberger pixel maps, attention and advertising markets, and community access slots — and observed that tax revenue becomes programmable, flowing into community pools, [bonding curves](/wiki/economics/curation-markets), or basic-income schemes rather than a traditional state treasury.

### Art and patronage

In [Radical Markets in the Arts](https://medium.com/radicalxchange/radical-markets-in-the-arts-13c27d3b7283) (2018), published with the RadicalxChange movement, de la Rouviere proposed applying COST to artistic intellectual property: creators self-assess a work's value, pay tax on the declaration, and anyone can buy the work at the declared price. Always-for-sale intellectual property, he argued, circulates more efficiently than fixed copyright terms, whose expiration dates amount to arbitrary guesses about when a work should be exploited. The essay explored blockchain-based digital collectibles under COST — tradeable music rights and badges, concert-ticket and digital-art memorabilia, and CryptoKitties-style always-for-sale assets — and described Harberger-taxed patronage seats, in which holding a status position requires ongoing tax payments that flow to the artist. Tax revenue could recycle into the commons so that "the arts, more directly, would fund more of the arts," with quadratic funding (Liberal Radicalism) as a complementary mechanism amplifying many small contributions to niche work.

### Choosing a tax rate

A follow-up 2019 post framed the tax rate as [the key open design question](https://home.simondlr.com/posts/exploring-harberger-tax-in-patronage-markets) for virtual collectibles and patronage markets. The academic literature recommends low rates, near an asset's expected turnover, because it targets physical assets where turnover is expensive and investment in the asset is desirable — assumptions that do not hold for virtual items. De la Rouviere argued that rates should instead vary by asset type: lower for items with use value, higher for pure collectibles and status assets. Extreme rates produce a pricing paradox: at 0.01% per annum, a patron wishing to give $100 a year must self-assess a prohibitive $1 million price, while at 10,000% per annum the price collapses to around $1, destroying any incentive to trade. For patronage markets he proposed roughly 100% per annum, so the annual donation equals the purchase price — an intuitive figure for patrons. The aim of such a rate is to direct capital to beneficiaries while retaining enough speculative interest to keep the market alive, though the post acknowledged unresolved tensions between altruism, status incentives, and market mechanics, and suggested simulation tooling such as cadCAD to model outcomes.

## Relevance to Caper

Harberger-style mechanisms are candidate tools for DAOs that must allocate scarce rights — featured placements, named roles, or other exclusive positions — without running repeated manual auctions: self-assessed pricing keeps such rights permanently contestable and converts their occupancy into a continuous revenue stream for the community. For communities on Caper, adopting such a mechanism would be a question of [governance design](/wiki/governance/voting-mechanisms) and [treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management). Caper does not implement Harberger taxes; they are described here as part of the design space available to on-chain communities.

## References

1. Eric A. Posner and E. Glen Weyl (2017). [Property Is Only Another Name for Monopoly](https://academic.oup.com/jla/article/9/1/51/3572441). Journal of Legal Analysis 9(1): 51–123.
2. Simon de la Rouviere (2018). [What is Harberger Tax & Where Does The Blockchain Fit In?](https://medium.com/@simondlr/what-is-harberger-tax-where-does-the-blockchain-fit-in-1329046922c6). Medium.
3. E. Glen Weyl and Anthony Lee Zhang (2022). [Depreciating Licenses](https://www.aeaweb.org/articles?id=10.1257/pol.20200426). American Economic Journal: Economic Policy 14(3): 422–448.
4. Simon de la Rouviere (2018). [Radical Markets in the Arts](https://medium.com/radicalxchange/radical-markets-in-the-arts-13c27d3b7283). RadicalxChange (Medium).
5. Simon de la Rouviere (2019). [Exploring Harberger Tax Rates in Virtual Collectibles & Patronage Markets](https://home.simondlr.com/posts/exploring-harberger-tax-in-patronage-markets). simondlr.com.

## Liquidity bootstrapping pools (LBPs)

URL: https://caper.network/wiki/economics/liquidity-bootstrapping-pools
Updated: 2026-07-27

|  |  |
| --- | --- |
| **Type** | Fair-launch price-discovery mechanism (dynamic-weight AMM pool) |
| **Introduced by** | Balancer (2020) |
| **Popularized by** | Copper Launch, rebranded [Fjord Foundry](https://www.fjordfoundry.com/) |
| **Core mechanism** | Pool weights shift linearly over time, applying controlled downward price pressure — a continuous Dutch-auction-style discovery |
| **Primary use** | Permissionless token distribution and fair launch with little starting capital |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve) · [Curation markets](/wiki/economics/curation-markets) · [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) |

A **liquidity bootstrapping pool** (LBP) is a token-sale mechanism, first built on [Balancer](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/liquidity-bootstrapping-pool.html), that lets a project distribute a brand-new token and discover its price fairly while committing very little starting capital. Unlike a fixed-price sale — where whales and bots race to buy the entire allocation at launch — an LBP starts the token priced high and lets that price drift _down_ over the sale unless buyers step in, so participants who wait are rewarded and no single actor can corner the supply cheaply. Because it produces an open, permissionless primary market rather than a negotiated round, it sits alongside [bonding curves](/wiki/markets/bonding-curve) and [curation markets](/wiki/economics/curation-markets) in the family of [on-chain capital-formation](/wiki/economics/capital-markets) mechanisms that DAOs use to launch a governance token.

## How an LBP works

An LBP is a variant of a Balancer [weighted pool](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-pool.html) holding two assets: the **project token** being sold and a **reserve asset** (typically a stablecoin or ETH). What makes it special is that the pool owner sets a _weight schedule_: per the [Balancer documentation](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/liquidity-bootstrapping-pool.html), the owner specifies "the starting and ending weights for both tokens" and "these weights change linearly over time." A typical sale starts around 90/10 (project token / reserve) and ends near 20/80.

Because a weighted-pool's spot price is a function of the balances _and_ the weights, steadily lowering the project token's weight creates what Balancer calls "controlled downward price pressure." If nobody buys, the price keeps falling; if demand appears, buys push it back up. The net effect is a "continuous Dutch-auction-style mechanism" that stretches price discovery across hours or days instead of resolving it in a single opening block.

## Why the design resists whales and bots

Fixed-price and first-come sales reward whoever transacts first with the most gas — the classic gas-war and sniping dynamic. An LBP inverts that incentive. Since the schedule pushes price down over time, [buying early is buying at the top](https://medium.com/balancer-protocol/distribute-your-erc20-token-with-liquidity-bootstrapping-pools-b84159464c32): a bot that sweeps the pool at launch simply overpays and then watches the weight schedule mark its position down. Rational buyers instead wait for a price they consider fair, which spreads the distribution across many participants and dampens the launch-day volatility that plagues fixed-price listings. The mechanism does not _prevent_ large buys, but it makes buying everything at once economically self-defeating.

## Configuration and owner controls

The pool owner holds significant, and asymmetric, power over an LBP. Per Balancer's [specification](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/liquidity-bootstrapping-pool.html), the owner is "the only address that can add liquidity to the pool, which must be done prior to the start of the sale," and "the proceeds can only be removed after the end time." The owner configures the start and end times, the weight schedule, and swap fees, and can pause swaps outright. A dedicated `blockProjectTokenSwapsIn` setting can prevent the project token from being sold _into_ the pool during the launch, blocking a common manipulation. This concentration of control is the mechanism's central trust assumption: buyers must trust that the owner will not pause the sale, alter the schedule, or pull reserves adversarially.

## LBPs in practice

LBPs moved from a Balancer primitive to a mainstream launch tool largely through **Copper Launch**, a front-end that made configuring one a point-and-click exercise. Copper [rebranded to Fjord Foundry](https://tokeninsight.com/en/news/copper-rebrands-to-fjord-foundry-launches-nft-lbp-product-fjord-drops) in 2022 and later signed an [exclusive LBP partnership with Balancer](https://forum.balancer.fi/t/bip-98-fjord-formerly-copper-and-balancer-exclusive-partnership/3884) (BIP-98), extending the format to NFTs. Projects including GuildFi, Merit Circle, and Avocado DAO have distributed tokens this way, and Balancer has facilitated [nine-figure LBP raises](https://medium.com/balancer-protocol/balancer-facilitates-record-high-liquidity-bootstrapping-pool-for-hydradx-f08b6b0a3aee) such as HydraDX. For a DAO, an LBP is often the moment a governance token first reaches a broad holder base — the event that turns a core team's project into a token-holder community.

## Limitations and criticisms

- **Owner trust.** As above, the owner can pause the sale and controls the reserves and schedule. Participants are trusting an EOA or multisig, not just a formula.
- **Buyer education.** The downward-drifting price is counter-intuitive; inexperienced buyers who treat a falling price as a dump can panic-sell or over-pay early. A successful LBP depends on a market that understands the mechanism.
- **Not manipulation-proof.** Sophisticated actors can still accumulate patiently near the floor, and the project can seed wash volume to fake demand. The mechanism improves distribution; it does not guarantee a "fair" outcome.
- **One-shot.** An LBP is a bounded event with a start and an end — it discovers a launch price but does not provide the token a standing, always-open market afterward.

## How Caper approaches this

An LBP and a [bonding curve](/wiki/markets/bonding-curve) both aim at fair, permissionless price discovery, but they are different shapes. An LBP is a _time-boxed event_: an owner schedules falling weights, the sale runs, and it ends — after which liquidity has to be arranged separately. Caper takes the always-on route. Every caper's token trades against its own bonding curve where price is a function of how much supply has sold, so [raising funds](/wiki/markets/raising-funds) is not a one-off auction but a standing market that opens the moment a caper is created and never needs a counterparty or a close. There is no owner-set schedule to trust and no window that expires: the curve is the same rule for the first buyer and the ten-thousandth. The trade-off is the mirror image of the LBP's — a bonding curve gives up the LBP's deliberate anti-whale price decay in exchange for a market that is continuous, formulaic, and permanent.

## References

1. Balancer. [Liquidity Bootstrapping Pool](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool/liquidity-bootstrapping-pool.html) — protocol documentation (mechanism, weight schedule, owner controls).
2. Balancer. [Weighted Pools](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-pool.html) — the spot-price/weight relationship LBPs build on.
3. Orb / Balancer Protocol. [Distribute Your ERC20 Token with Liquidity Bootstrapping Pools](https://medium.com/balancer-protocol/distribute-your-erc20-token-with-liquidity-bootstrapping-pools-b84159464c32).
4. [Fjord Foundry](https://www.fjordfoundry.com/) — LBP launch platform (formerly Copper Launch); [rebrand announcement](https://tokeninsight.com/en/news/copper-rebrands-to-fjord-foundry-launches-nft-lbp-product-fjord-drops).
5. Balancer governance. [BIP-98: Fjord (formerly Copper) and Balancer exclusive partnership](https://forum.balancer.fi/t/bip-98-fjord-formerly-copper-and-balancer-exclusive-partnership/3884).
6. Balancer Protocol. [Balancer Facilitates Record-High Liquidity Bootstrapping Pool for HydraDX](https://medium.com/balancer-protocol/balancer-facilitates-record-high-liquidity-bootstrapping-pool-for-hydradx-f08b6b0a3aee).

## Liquidity mining and mercenary capital

URL: https://caper.network/wiki/economics/liquidity-mining
Updated: 2026-08-01

| Concept | Liquidity mining (yield farming) |
| --- | --- |
| Category | Token incentives / DAO tokenomics |
| Introduced | June 2020 — [Compound](https://docs.compound.finance/governance/) COMP distribution ("DeFi summer") |
| Mechanism | Protocol emits its governance token to liquidity providers on top of trading fees, to bootstrap TVL |
| Core failure mode | Mercenary capital — rented liquidity that exits when emissions fall |
| Common responses | [Vote-escrow (ve) tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow), [protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) |

**Liquidity mining** (also called _yield farming_) is a token-distribution strategy in which a protocol pays out its own governance token to the users who supply liquidity or otherwise use it. The rewards sit on top of ordinary trading fees or lending interest, so for a period the protocol effectively subsidises participation with newly minted tokens. It is the most widely copied DAO growth mechanism of the last five years, and also one of the most criticised: it reliably buys total value locked (TVL) in the short run, and reliably fails to keep it.

Liquidity mining is one of the two ways a DAO gives its token away, and it is useful to hold them side by side. It pays continuously, prospectively, and for a specific behaviour it wants more of; an [airdrop](/wiki/economics/airdrops-and-token-distribution) pays once, retroactively, for behaviour that has already happened. The two share a failure mode — a large share of the distributed token is sold on receipt in both cases — but they fail on different clocks. An emissions programme keeps buying the same capital every day until it stops paying; an airdrop finds out in a single week whether it bought anything at all.

## Origin: Compound and "DeFi summer"

Liquidity mining as a mass phenomenon dates to June 2020, when [Compound](https://docs.compound.finance/governance/) began distributing its governance token COMP daily to both suppliers and borrowers across its money markets, in proportion to the interest accruing in each market. Within a day COMP was among the largest DeFi tokens by market capitalisation, and the design was copied across the ecosystem in what became known as "DeFi summer." The insight was simple: instead of selling tokens to investors, a protocol could distribute them to the people actually using it, bootstrapping both liquidity and a holder base at once — a [user-centric distribution](https://multicoin.capital/2020/08/13/exploring-the-design-space-of-liquidity-mining/) in place of a sale.

## How it works

The mechanics are consistent across implementations:

- **Deposit.** A user supplies assets to a pool — a lending market, or a two-sided [AMM](/wiki/economics/capital-markets) pool.
- **Accrue.** The protocol streams a fixed or governance-set number of its tokens per block/day to that pool, split across depositors by share.
- **Claim and, usually, sell.** Farmers harvest the reward token. Because most farmers value the reward only in the numéraire they came with, a large share is sold on receipt, adding constant sell pressure.

The headline number is APY: the annualised value of emissions divided by capital deposited. When the reward token appreciates, that APY can spike — Compound's reached roughly 50% at points — which is exactly what pulls in capital that has no interest in the protocol beyond the yield. High [token velocity](/wiki/economics/token-velocity) (reward tokens earned and immediately dumped) is the direct on-chain signature of this dynamic.

## The mercenary-capital problem

_Mercenary capital_ is liquidity that chases the highest available yield with no loyalty to any one protocol. It arrives when a program launches and leaves the moment emissions taper or a richer farm appears elsewhere. The consequence is that TVL, during an incentive program, measures the size of the incentive far more than the health of the protocol: a chart of deposits often tracks the emissions schedule almost exactly, then collapses when rewards end. The extreme cases — pools that amassed a meaningful slice of all DeFi TVL over a single weekend and then emptied — made the pattern impossible to ignore.

The costs compound. Emissions dilute existing holders to pay for liquidity that does not stay; the sold reward tokens depress price; and the protocol is left with a temporary TVL number and no durable moat. Liquidity mining is best understood not as free growth but as **renting** liquidity — and rented liquidity leaves.

## Steering emissions: vote-escrow and gauges

The first major refinement was to make emissions _earned_ and _directed_ rather than sprayed. [Curve](/wiki/daos/dexs/curve-dao)'s design is the archetype: liquidity providers still receive CRV emissions, but the split across pools is decided by [gauge-weight votes](https://docs.curve.finance/protocol/gauge/overview) cast by holders who have locked CRV into [vote-escrowed veCRV](/wiki/dao-governance/concepts/voting/vote-escrow). Locking longer grants more weight, converting some mercenary capital into longer-committed capital and letting governance point rewards at the pools that matter. It also spawned a secondary market — "bribes" and vote markets where protocols pay veCRV holders to direct emissions their way — which is a story in its own right (the "Curve wars"). The lesson: emissions are a lever, and who holds the lever is a governance question.

## Owning liquidity instead of renting it

The second response was to stop renting altogether. Rather than pay emissions to third-party LPs forever, a DAO can acquire the liquidity for its own balance sheet — [protocol-owned liquidity](/wiki/dao-governance/concepts/treasury/protocol-owned-liquidity) (POL). [OlympusDAO](/wiki/daos/stablecoins/olympusdao) popularised the approach with bonding: the protocol sells its token at a discount in exchange for LP tokens, building a treasury of liquidity it controls and no longer has to keep bribing to retain. A [liquidity bootstrapping pool](/wiki/economics/liquidity-bootstrapping-pools) solves the adjacent problem of the initial fair launch. Each of these trades an ongoing emissions bill for a one-time treasury cost, and each treats liquidity as an asset to hold rather than a subsidy to pay.

The third response is to stop paying and start collecting: a [fee switch](/wiki/economics/fee-switches-and-value-accrual) reverses the direction of the flow, taking a slice of the fees liquidity providers earn and routing it to the protocol. Uniswap ran both experiments in sequence — years of emissions-led growth, then a protocol fee that pays for token burns out of LP revenue.

## Design tradeoffs

Multicoin Capital's [design-space analysis](https://multicoin.capital/2020/08/13/exploring-the-design-space-of-liquidity-mining/) frames the choices well: _who_ gets paid (makers, takers, or service providers like liquidators), _how much_ (total allocation and how it is measured), and _when_ (immediate, vested, or clawback-able). A program that pays a fixed emission with no lock-up should expect short-term arbitrageurs to crowd out organic users; lock-ups, vesting, and usefulness-weighted rewards push in the other direction. The recurring failures are the mirror image: overpaying for headline TVL, rewarding volume rather than usefulness, and emission rules loose enough to be gamed. Liquidity mining is not inherently bad — it is a distribution tool whose outcome is entirely determined by these parameters and by whether the protocol has a reason for the capital to stay once the subsidy stops.

## How Caper approaches this

A [Caper](/wiki/foundations/what-is-a-caper) runs no liquidity-mining program and emits no reward token. Instead of renting liquidity with emissions, each caper's token trades against an always-on [bonding curve](/wiki/markets/bonding-curve) whose reserve provides continuous liquidity at the curve price — there is no third-party LP to bribe and no emission schedule to taper. Governance weight is not farmed either: it is earned participation, and every holder keeps a credible [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) to redeem their share of the treasury at any time. The contrast is the point of this page — liquidity mining buys capital that leaves when the reward stops; Caper's design gives capital a standing reason to stay, or a clean way to go, without a subsidy running underneath it.

## References

- [Compound — Governance and COMP distribution (docs)](https://docs.compound.finance/governance/)
- [Tushar Jain & Spencer Applebaum, Exploring the Design Space of Liquidity Mining (Multicoin Capital, 2020)](https://multicoin.capital/2020/08/13/exploring-the-design-space-of-liquidity-mining/)
- [Curve — Gauges & incentives overview (docs)](https://docs.curve.finance/protocol/gauge/overview)

## Mechanism design

URL: https://caper.network/wiki/economics/mechanism-design
Updated: 2026-08-01

| Field | The branch of economics that designs the rules of a game so that self-interested play produces a chosen outcome – “inverse game theory” |
| --- | --- |
| Founded by | Leonid Hurwicz, Eric S. Maskin and Roger B. Myerson, awarded the 2007 [Sveriges Riksbank Prize in Economic Sciences](https://www.nobelprize.org/prizes/economic-sciences/2007/summary/) “for having laid the foundations of mechanism design theory” |
| Core criteria | _Incentive compatibility_ (honesty is a best response) · _individual rationality_ (participating beats walking away) · _budget balance_ · _efficiency_ |
| Key tool | The [revelation principle](https://www.nobelprize.org/uploads/2018/06/myerson_lecture.pdf) – any outcome achievable by any mechanism is achievable by one in which players simply report the truth |
| Key limits | Gibbard–Satterthwaite (no strategy-proof, non-dictatorial voting rule over three or more options) · Myerson–Satterthwaite (no efficient, budget-balanced, voluntary bilateral trade under private values) |
| In crypto | [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) fee markets · [quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) · [futarchy](/wiki/dao-governance/concepts/voting/futarchy) · [Harberger taxes](/wiki/economics/harberger-taxes) · auction design for [block space](/wiki/economics/mev-and-value-extraction) |
| Related | [Principal–agent problem](/wiki/economics/principal-agent) · [Schelling points](/wiki/economics/schelling-points) · [Vote markets](/wiki/dao-governance/concepts/voting/vote-markets) |

**Mechanism design** asks the reverse of the usual game-theory question. Game theory takes the rules as given and predicts how rational players will behave. Mechanism design fixes the outcome you want – the goods go to whoever values them most, the public good gets funded in proportion to how many people want it, the treasury spends on what the members actually prefer – and then asks what rules would make self-interested players produce it without being asked to be honest, public-spirited, or even well-informed about each other. It is sometimes called _inverse game theory_ for that reason.

The field was formalised by Leonid Hurwicz, who introduced the idea of a _mechanism_ as a message-and-outcome system that could be compared on informational as well as allocative grounds, and extended by Eric Maskin on implementation and Roger Myerson on optimal design under private information. The three shared the [2007 Nobel Memorial Prize](https://www.nobelprize.org/prizes/economic-sciences/2007/summary/), with the official motivation “for having laid the foundations of mechanism design theory”. Their Nobel lectures – [Hurwicz](https://www.nobelprize.org/uploads/2018/06/hurwicz_lecture.pdf), [Maskin](https://www.nobelprize.org/uploads/2018/06/maskin_lecture.pdf) and [Myerson](https://www.nobelprize.org/uploads/2018/06/myerson_lecture.pdf) – remain the most accessible primary statements of what the field is for.

This matters to a DAO because a DAO is nothing _but_ a mechanism. It has no manager who can override a bad outcome, no court that will read intent instead of text, and no way to punish a member for voting in their own interest. Whatever the rules reward is what the organisation will do. Most of the recurring failures catalogued under [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) are not failures of virtue; they are mechanisms behaving exactly as written.

## The vocabulary: what a mechanism has to satisfy

A mechanism is judged against a short list of properties, and almost every design argument in DAO governance is really an argument about which of them to give up.

- **Incentive compatibility (IC).** Reporting your true preference is at least as good for you as any lie. The strong form, _dominant-strategy_ incentive compatibility, holds no matter what anyone else does; the weaker Bayesian form holds only in expectation, given beliefs about others.
- **Individual rationality (IR).** Nobody is worse off for taking part than for staying out. A voting system that lets a majority expropriate a minority is not individually rational for the minority, which is why [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) keep reappearing as a design patch.
- **Budget balance.** The mechanism does not need an outside subsidy to run. [Quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding) is famously _not_ budget balanced – it requires a matching pool – which is a design choice, not an oversight.
- **Efficiency.** The allocation maximises total value. This is the property most often sacrificed, because the impossibility results below say you frequently cannot have it alongside the others.

The single most useful theorem in the field compresses the search space enormously. The **revelation principle**, set out in Myerson's [Nobel lecture](https://www.nobelprize.org/uploads/2018/06/myerson_lecture.pdf), says that any outcome achievable by _any_ mechanism – however baroque its messages, rounds, or side-payments – is also achievable by a direct mechanism in which every player simply reports their private information truthfully. So a designer never has to invent clever message formats: it is enough to ask what truthful-reporting rules are feasible, and if none produces the outcome you want, no elaborate procedure will either.

## What the impossibility results rule out

Mechanism design is as valuable for what it forecloses as for what it builds. Three results bound almost every governance argument.

**Gibbard–Satterthwaite** (Allan Gibbard 1973, Mark Satterthwaite 1975): for any voting rule over three or more outcomes that is deterministic, non-dictatorial, and can produce every outcome, there exist preferences under which some voter does better by misreporting. Strategic voting is not a defect of a particular ballot design – it is unavoidable. Any claim that a new voting scheme “eliminates strategic voting” is therefore false as stated; the honest version is that it changes _which_ misreports pay, and how hard they are to coordinate. This is the theorem that governs the comparison between [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting), [conviction voting](/wiki/dao-governance/concepts/voting/conviction-voting) and the rest – and, one level down, between the [ballot methods](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods) that count whatever weight those rules assign.

**Myerson–Satterthwaite** (1983): when a buyer and a seller each hold private valuations and either may refuse to trade, no mechanism is simultaneously efficient, budget-balanced and individually rational. Some gains from trade are always lost. This is the formal reason a treasury cannot simply “buy out” a dissenting member at a fair price by asking both sides what the stake is worth, and it is the theorem lurking behind every buyback, ragequit valuation and [Harberger tax](/wiki/economics/harberger-taxes) proposal.

**Arrow's impossibility theorem** (1951) sits underneath both: no rank-order rule for three or more options can satisfy unrestricted domain, unanimity, independence of irrelevant alternatives and non-dictatorship at once. Aggregating preferences is not a solved engineering problem waiting for better software.

The practical upshot for a DAO is modest but real. You cannot design your way to a mechanism with no strategic play and no losses. You _can_ choose which strategic play is cheap and which is expensive, and you can make the expensive kind visible.

## Auctions: the worked example the field was built on

Auctions are where mechanism design is most fully solved, and where the theory earned its second Nobel: Paul Milgrom and Robert Wilson took the [2020 prize](https://www.nobelprize.org/prizes/economic-sciences/2020/summary/) “for improvements to auction theory and inventions of new auction formats”.

The canonical result is William Vickrey's: in a sealed-bid auction where the winner pays the _second_-highest bid, bidding your true value is a dominant strategy. You cannot improve your outcome by shading, because your bid determines only whether you win, not what you pay. Generalised to many goods, this becomes the Vickrey–Clarke–Groves (VCG) mechanism: each winner pays the externality they impose on everyone else. VCG is efficient and dominant-strategy incentive-compatible, and it is also fragile in exactly the ways that matter on a blockchain – it can generate very low revenue, and it is vulnerable to a bidder splitting into several identities, which is the general form of the [Sybil problem](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos).

That fragility is the bridge to crypto. A permissionless system cannot assume one person equals one bidder, cannot assume bidders are not the same party, and cannot assume the auctioneer is honest – the auctioneer is a validator with its own position. Every clean auction-theoretic result has to be re-derived under those weaker assumptions, which is most of what blockchain mechanism-design research has been doing since 2019.

## Where blockchains actually do mechanism design

Three deployed examples show the field applied at scale, and all three are readable in primary sources.

**Transaction fee markets.** [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) (Buterin, Conner, Dudley, Slipper, Norden and Bakhta, created 13 April 2019, now Final) replaced a first-price gas auction with a protocol-set _base fee_ that is burned and adjusts with demand, plus a priority tip the block producer keeps. Tim Roughgarden's [economic analysis](https://arxiv.org/abs/2012.00854) (arXiv:2012.00854, December 2020) is the reference treatment: it formalises what a transaction fee mechanism must satisfy for both users and block producers, and shows the base-fee burn is what makes the producer side incentive-compatible – a producer who kept the base fee would have a reason to manufacture demand and inflate it. The EIP itself states the point plainly, that burning the base fee “removes miner incentive to manipulate the fee”.

**Block-space allocation.** Proposer–builder separation turns block construction into a repeated auction between specialised builders and the validator who holds the slot. It is a mechanism-design response to [MEV](/wiki/economics/mev-and-value-extraction): rather than pretend ordering has no value, PBS makes the value explicit and auctions it, on the theory that a competitive auction returns it to validators instead of to whoever runs the fastest bot. Whether that competition materialises is an empirical question, and the concentration numbers on the MEV page are the honest answer to it.

**Public-goods funding.** [Quadratic funding](/wiki/dao-governance/concepts/voting/quadratic-voting-and-funding), from Buterin, Hitzig and Weyl's [A Flexible Design for Funding Public Goods](https://arxiv.org/abs/1809.06421) (arXiv:1809.06421, September 2018), allocates a matching pool by the square of the sum of the square roots of contributions – a rule chosen precisely because, under its assumptions, it is the one that funds public goods at the socially optimal level. Its assumptions are also its weak point: it presumes distinct, non-colluding contributors, which is why every deployment pairs it with identity infrastructure. [Retroactive public goods funding](/wiki/dao-governance/concepts/treasury/retroactive-public-goods-funding) is the alternative bet – that judging results after the fact is an easier problem than eliciting preferences beforehand.

## Why DAO governance is the hard case

Classical mechanism design assumes players cannot make binding side deals. Break that assumption and most of the guarantees evaporate, because a mechanism that is incentive-compatible for an individual is rarely incentive-compatible for a coalition that can pay its members to deviate together. Vitalik Buterin's [On Collusion](https://vitalik.eth.limo/general/2019/04/03/collusion.html) (April 2019) is the standard statement of the problem in a blockchain setting, and its conclusion is uncomfortable: the properties that make on-chain governance attractive – transparent, verifiable, tradeable votes – are the same properties that make collusion cheap to arrange and easy to enforce.

Two DAO-specific pressures follow directly.

- **Votes are for sale because they are transferable.** If a governance token can be bought, borrowed or delegated, then influence can be rented for exactly one decision. That is the whole subject of [vote markets and governance bribery](/wiki/dao-governance/concepts/voting/vote-markets), and it is why vote-escrow lockups exist – not to reward loyalty, but to raise the cost of renting a position for a single vote.
- **Identity is not free.** Every mechanism that treats participants as distinct people rather than distinct balances – quadratic voting, quadratic funding, one-person-one-vote – imports an identity assumption that the base layer does not supply. In practice the mechanism is only as strong as the [Sybil resistance](/wiki/dao-governance/concepts/membership/sybil-resistance-in-daos) bolted on beside it.

Buterin's [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (August 2021) sets out the resulting design space, and [DAOs are not corporations](https://vitalik.eth.limo/general/2022/09/20/daos.html) (September 2022) makes the case that decentralisation is worth its cost in exactly the decisions where an adversary would otherwise capture a single point of control. Both are useful correctives to the assumption that a DAO should converge on corporate governance with extra steps.

## How Caper approaches this

Caper's answer is to keep the mechanism small enough to reason about, and to price the two things that usually go unpriced: liquidity and exit.

Every caper token trades against a [bonding curve](/wiki/markets/bonding-curve) rather than an order book, so the price of any trade is a closed-form function of circulation, computable before you sign. There is no discretionary market maker to model and no liquidity that can be withdrawn, which removes a whole class of strategic behaviour rather than trying to disincentivise it.

Voting weight is deliberately not a pure token count. Caper computes it as `(t × v) / (V × T)` – your holdings `t` against circulating supply `T`, multiplied by your accumulated vote tokens `v` against the total vote supply `V` – so influence is the product of stake and demonstrated participation. Buying a large position confers weight only in combination with a voting record that has to be built over time, which raises the cost of the rent-a-vote pattern described above without pretending to eliminate it.

The same expression is the [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) formula: a member redeeming their stake receives that identical fraction of the treasury. Voice and exit are priced by one number, which is a direct response to the individual-rationality problem – a member who loses a vote is never trapped, and a majority that wants to expropriate a minority has to buy them out at the same rate it grants them influence. For the mechanics themselves, see [what is a caper](/wiki/foundations/what-is-a-caper) and [voting mechanisms](/wiki/governance/voting-mechanisms).

## References and further reading

- [The Sveriges Riksbank Prize in Economic Sciences 2007](https://www.nobelprize.org/prizes/economic-sciences/2007/summary/) – Hurwicz, Maskin and Myerson, “for having laid the foundations of mechanism design theory”; see also the prize committee's [advanced information](https://www.nobelprize.org/prizes/economic-sciences/2007/advanced-information/) document
- [Perspectives on Mechanism Design in Economic Theory](https://www.nobelprize.org/uploads/2018/06/myerson_lecture.pdf) – Roger Myerson's Nobel lecture, the clearest primary account of the revelation principle and of what mechanism design is for
- [But Who Will Guard the Guardians?](https://www.nobelprize.org/uploads/2018/06/hurwicz_lecture.pdf) – Leonid Hurwicz's Nobel lecture on enforcement and the limits of self-implementing rules
- [Mechanism Design: How to Implement Social Goals](https://www.nobelprize.org/uploads/2018/06/maskin_lecture.pdf) – Eric Maskin's Nobel lecture on implementation theory
- [The Sveriges Riksbank Prize in Economic Sciences 2020](https://www.nobelprize.org/prizes/economic-sciences/2020/summary/) – Milgrom and Wilson, “for improvements to auction theory and inventions of new auction formats”
- [Transaction Fee Mechanism Design for the Ethereum Blockchain: An Economic Analysis of EIP-1559](https://arxiv.org/abs/2012.00854) – Tim Roughgarden, arXiv:2012.00854, 1 December 2020
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) – created 13 April 2019, status Final
- [A Flexible Design for Funding Public Goods](https://arxiv.org/abs/1809.06421) – Buterin, Hitzig and Weyl, arXiv:1809.06421, 17 September 2018, the quadratic-funding paper
- [On Collusion](https://vitalik.eth.limo/general/2019/04/03/collusion.html) – Vitalik Buterin, April 2019, on why coalition-proofness is the binding constraint on-chain
- [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) – August 2021; and [DAOs are not corporations](https://vitalik.eth.limo/general/2022/09/20/daos.html) – September 2022

## MEV and value extraction

URL: https://caper.network/wiki/economics/mev-and-value-extraction
Updated: 2026-08-01

| Concept | MEV – the value a party can extract purely from deciding what goes into a block and in what order |
| --- | --- |
| Originally | “Miner extractable value”, coined by Daian et al. in [Flash Boys 2.0](https://arxiv.org/abs/1904.05234) (10 April 2019); now usually read as _maximal_ extractable value |
| Main forms | DEX arbitrage · liquidations · sandwich attacks · just-in-time liquidity · CEX–DEX arbitrage against stale pool prices |
| Who pays | Liquidity providers (through [loss-versus-rebalancing](https://arxiv.org/abs/2208.06046)), traders who move price, and borrowers at liquidation |
| How it is sold | Searchers bid to builders, builders bid to validators through relays – [proposer-builder separation](https://docs.flashbots.net/flashbots-mev-boost/introduction) |
| Concentration | Two builders produced 74.6% of MEV-Boost blocks over the 7 days to 1 August 2026 ([relayscan.io](https://relayscan.io)) |
| Governance angle | An on-chain vote publishes a treasury trade before it executes; protocol revenue lost to extraction never reaches the fee switch |
| Related | [Fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual) · [Staking and slashing](/wiki/economics/staking-and-slashing) · [CoW DAO](/wiki/daos/dexs/cow-dao) · [Jito](/wiki/daos/staking/jito) |

**MEV** is the value someone can extract from a blockchain by controlling the contents and order of a block, over and above the ordinary fees and rewards for producing it. The acronym came from [Flash Boys 2.0](https://arxiv.org/abs/1904.05234) (Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach and Juels, April 2019), which documented arbitrage bots bidding transaction fees up against each other in what the authors called _priority gas auctions_, and argued that fees paid for ordering are large enough to be a consensus-layer security risk rather than a trading curiosity. It stood for “miner extractable value”; after Ethereum moved to proof of stake the expansion drifted to _maximal_ extractable value, which is how [CoW Protocol's documentation](https://docs.cow.fi/cow-protocol/concepts/benefits/mev-protection) and most of the industry now write it.

The reason the concept refuses to go away is that ordering is a real economic right and somebody always holds it. A blockchain does not execute transactions as they arrive; it executes them in the sequence a block producer chooses. Whoever chooses that sequence can put their own trade first, insert one on either side of yours, or sell that privilege to someone who will. Every general-purpose chain has this property. The only open questions are who captures the value, whether the people who generate it get any of it back, and what the fight over it does to the rest of the system.

## Where the value actually comes from

MEV is not a single trade. It is a family of strategies that share one input – a temporary, mechanical mispricing that only exists because state changes in a discrete order.

- **DEX arbitrage.** Two pools quote the same pair at different prices, or a pool's price drifts from the wider market. A bot buys on one side and sells on the other in a single atomic transaction. This is the benign end of the family: it is how AMM prices track reality at all.
- **Liquidations.** A lending position crosses its health threshold and the protocol pays a bonus to whoever closes it. The bonus is a fixed parameter; the race to claim it is a pure ordering contest.
- **Sandwich attacks.** A bot sees a pending swap large enough to move a pool, buys ahead of it, lets the victim execute at the worsened price, and sells behind it. [CoW Protocol's documentation](https://docs.cow.fi/cow-protocol/concepts/benefits/mev-protection) calls this “price exploitation” and notes it has cost ordinary traders more than a billion dollars. Unlike arbitrage, nothing about it improves the market – it is a transfer from the trader to the bot.
- **Just-in-time liquidity.** A bot adds concentrated liquidity in the same block as a large swap, collects the fees on that swap, and withdraws immediately, taking fee income from the passive providers who carried the inventory risk all week.
- **CEX–DEX arbitrage.** The largest and least visible category. Centralised venues reprice continuously; an AMM pool reprices only when someone trades against it. The gap is picked off every block by whoever is fastest.

That last category has a formal name. In [Automated Market Making and Loss-Versus-Rebalancing](https://arxiv.org/abs/2208.06046) (Milionis, Moallemi, Roughgarden and Zhang, 2022, revised 2024) it is called **loss-versus-rebalancing**, or LVR – presented as a “Black-Scholes formula for AMMs”. The paper identifies the adverse-selection cost an AMM liquidity provider bears because the pool quotes stale prices that better-informed arbitrageurs pick off, and derives closed-form expressions for it across all constant-function market makers. The important consequence for a DAO is that LVR is structural, not an attack: it is the standing cost of running an on-chain market maker against off-chain price discovery, and it shows up whether or not anyone behaves badly.

## The supply chain that sells ordering

On Ethereum the ordering right is no longer exercised by the validator who proposes the block. It is auctioned through a four-layer pipeline that [MEV-Boost](https://docs.flashbots.net/flashbots-mev-boost/introduction) formalised as _proposer-builder separation_:

1. **Searchers** find extractable opportunities and package them into transaction bundles with a bid attached.
2. **Builders** assemble whole blocks out of public mempool flow and searcher bundles, optimising for total extractable value, and quote a payment to the proposer.
3. **Relays** hold the built block, show the proposer only its bid, and release the contents once the proposer has signed – so neither side can steal from the other.
4. **Proposers** (validators) run MEV-Boost as a sidecar, take the highest bid, and sign a block they never saw.

The stated goal was decentralisation: separating who builds from who proposes was meant to let a home validator earn the same MEV income as a sophisticated one. On that narrow measure it worked. On concentration it did not. Over the seven days to 1 August 2026, [relayscan.io](https://relayscan.io) recorded Titan building 53.61% of MEV-Boost blocks and Quasar 20.98% – two firms producing roughly three-quarters of them – with BuilderNet at 13.06% and Eureka at 8.81% making up most of the remainder. The relay layer is similarly thin: ultrasound.money (27.00%), bloXroute max-profit (23.29%), Titan Relay (20.10%) and bloXroute regulated (19.37%) carried about 90% of payloads between them. Block construction is a competitive market with a handful of competitors, which is a different thing from a decentralised one.

The proposed fix is to bring the auction inside the protocol. [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732), “Enshrined Proposer-Builder Separation”, would make builders an in-protocol entity: the consensus proposer commits to a builder's signed bid, the value is deducted from the builder's own stake, and a payload timeliness committee attests to whether the builder actually revealed the block it promised. It was created in June 2024 and is still at **Review** status – a design under active discussion, not a shipped feature.

## Who actually pays

MEV is often described as a tax on traders. That undercounts it. The bill lands on three groups, and only one of them is aware of it in the moment.

- **Liquidity providers** pay the largest and quietest share, through LVR. The fees look fine in the interface; the arbitrage losses net against them silently. Any DAO running protocol-owned liquidity, a treasury LP position, or a [liquidity mining programme](/wiki/economics/liquidity-mining) is paying this whether or not it is measured, and a mining programme that ignores it can be paying emissions to attract capital that loses money on arrival.
- **Traders** pay through sandwiching and worse fills. This is the visible form, and the reason private RPC endpoints exist.
- **Borrowers** pay the liquidation bonus, which is set by governance and captured by whoever wins the ordering race.

Framed in the language of [transaction costs](/wiki/economics/transaction-costs), extraction is a friction that neither counterparty agreed to and neither can price in advance. Framed as [a principal-agent problem](/wiki/economics/principal-agent), the party choosing the order is not the party bearing the loss, and the loss is invisible in the accounts of the party bearing it.

## Why this is a governance problem, not just a trading problem

Three distinct things break for a DAO, and they break in different places.

**A vote is an advance announcement of a trade.** On-chain governance is a public, timestamped statement of intent with a built-in delay: the proposal names the asset, the size and often the venue, the voting period runs for days, and the timelock adds more. By the time a treasury diversification executes, every searcher on the network has had a week's notice of exactly what is coming. The transparency that makes on-chain governance auditable is the same property that makes its execution predictable, and predictable order flow is the single most valuable input a searcher can have. This is one of the strongest practical arguments for [ballot privacy and delayed disclosure](/wiki/dao-governance/concepts/voting/private-and-shielded-voting) – not to hide how members voted, but to stop the treasury telegraphing its own execution.

**Extracted value never reaches the fee switch.** A DAO's [fee switch](/wiki/economics/fee-switches-and-value-accrual) can only route revenue the protocol actually collected. Value that leaves through arbitrage against the protocol's own pools was never collected in the first place, so it does not appear in any revenue figure a [token valuation](/wiki/economics/token-valuation) is built from. A protocol can look structurally unprofitable while generating substantial value, simply because that value is captured one layer below its accounting. [Aerodrome](/wiki/daos/dexs/aerodrome-finance) makes this explicit in its own design language, describing value normally lost to arbitrage bots as something the protocol should keep.

**MEV is now a staking-yield line item, and someone has to decide the split.** On Solana, [Jito](/wiki/daos/staking/jito) routes MEV rewards to validators and their stakers rather than leaving them with the searcher, which makes the split a governance parameter of a DAO rather than a market outcome. Any DAO holding a liquid staking token therefore holds an exposure to another DAO's MEV policy alongside the [slashing exposure](/wiki/economics/staking-and-slashing) it already carries. [Osmosis](/wiki/daos/dexs/osmosis) takes the other route and handles ordering at the protocol layer instead of an out-of-protocol auction.

## Designs that suppress or redistribute it

No production system eliminates MEV. The designs that work either make ordering worthless, hide the information ordering depends on, or return the proceeds to whoever generated them.

- **Batch auctions with uniform clearing prices.** [CoW Protocol](/wiki/daos/dexs/cow-dao) collects signed intents off-chain and auctions them to bonded solvers. Because every order for the same directed pair in a batch settles at [the same clearing price](https://docs.cow.fi/cow-protocol/concepts/introduction/fair-combinatorial-auction), position within the batch stops mattering – the documentation's phrasing is that this “makes transaction order irrelevant”. The auction is [combinatorial](https://docs.cow.fi/cow-protocol/concepts/introduction/solvers): solvers bid on individual orders and on groups, and bids that deliver an order less than an available standalone bid are filtered out. This is the strongest structural answer available today, and it is a market-design answer rather than a cryptographic one.
- **Private order flow with a rebate.** [MEV Blocker](https://mevblocker.io) is an RPC endpoint that withholds transactions from the public mempool, shows them only to searchers who can backrun but not frontrun or sandwich, and pays the user a share of the backrun profit. Its own dashboard reports over $219bn of volume across more than 62m transactions and about 5,500 ETH rebated, at a median rebate of roughly $26 (1 August 2026). [MEV-Share](https://docs.flashbots.net/flashbots-mev-share/introduction) runs the same idea from the Flashbots side, selectively revealing transaction details according to the sender's privacy preference and accepting backruns only.
- **Enshrining the auction.** [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) moves the builder market into consensus, replacing trusted relays with staked, slashable builders.
- **Protocol-level ordering rules.** Encrypted or threshold-decrypted mempools, first-come-first-served sequencing, and app-chain-level ordering policy all attack the same input – the searcher's advance sight of your transaction.

Each buys protection with a different cost: batch auctions add latency, private RPCs concentrate order flow in whoever operates the endpoint, and enshrined designs are consensus changes that take years.

## What a DAO can actually do about it

Most of the useful moves are operational rather than constitutional, and none of them require a protocol change:

- **Never execute a treasury trade from a public mempool.** Route it through a solver auction or a private endpoint. For a treasury swap the difference is measured in basis points on a seven-figure order, which is not a rounding error.
- **Separate the decision from the execution.** Vote on a mandate – the asset, the ceiling, the window – and let the executor choose timing and venue inside it. A proposal that specifies the exact size, venue and block is a proposal that has priced itself in advance.
- **Measure LVR on protocol-owned liquidity.** Fee income on an LP position is a gross number. The net number is fees minus LVR, and a treasury holding an LP position without measuring the second term does not know whether the position makes money.
- **Treat the liquidation bonus as a real parameter.** It is set by governance, paid by users, and captured by bots; it deserves the same scrutiny as any other fee.
- **Read the MEV policy of any staking token the treasury holds.** Who receives the tips, and who can vote to change that, is a governance dependency the treasury has taken on.

## How Caper approaches this

Caper does not solve MEV, and no chain-level design here would. What it does is remove one specific surface: the moment a member converts a governance claim into value. In a [caper](/wiki/foundations/what-is-a-caper), a member's exit pays out a share of the treasury computed from their own vote weight rather than from an order sold into a pool, and the token leg prices off a [deterministic bonding curve](/wiki/markets/bonding-curve) rather than a quote that depends on pool depth at the instant of execution. There is no slippage tolerance to widen and no pending order whose size and direction a searcher can read and trade against.

The honest caveat is that ordering still matters wherever a price moves with cumulative volume – being earlier on a rising curve is worth something, and that is true of any curve-priced asset. The claim is narrower and worth stating precisely: the payout a member receives on exit is fixed by a formula over their own holdings and votes, so it is not a trade anyone else can position around.

## References and further reading

- [Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges](https://arxiv.org/abs/1904.05234) – Daian et al., arXiv:1904.05234, 10 April 2019, the paper that named MEV and formalised priority gas auctions
- [Automated Market Making and Loss-Versus-Rebalancing](https://arxiv.org/abs/2208.06046) – Milionis, Moallemi, Roughgarden and Zhang, arXiv:2208.06046 (v1 August 2022, v5 May 2024), the closed-form treatment of LP adverse selection
- [Flashbots — MEV-Boost](https://docs.flashbots.net/flashbots-mev-boost/introduction) and [MEV-Share](https://docs.flashbots.net/flashbots-mev-share/introduction), the reference implementations of out-of-protocol PBS and of backrun refunds
- [relayscan.io](https://relayscan.io) – live MEV-Boost relay and builder market share, the source of the concentration figures above
- [EIP-7732: Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732) – created 28 June 2024, status Review
- [CoW Protocol — MEV protection](https://docs.cow.fi/cow-protocol/concepts/benefits/mev-protection), [Fair Combinatorial Batch Auction](https://docs.cow.fi/cow-protocol/concepts/introduction/fair-combinatorial-auction) and [Solvers](https://docs.cow.fi/cow-protocol/concepts/introduction/solvers)
- [MEV Blocker](https://mevblocker.io) – endpoint behaviour and the published rebate metrics

## Microfinance and micropayments

URL: https://caper.network/wiki/economics/microfinance
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Topic** | Economics of very small loans and payments |
| **Core problem** | Fixed transaction costs that fall disproportionately on small transactions |
| **Key approaches** | Group lending with cross-reporting; probabilistic micropayment lotteries |
| **Evidence base** | Six randomized evaluations across four continents: effects “modestly positive, but not transformative” |
| **Related** | [Transaction costs and property rights](/wiki/economics/transaction-costs) · [Raising funds](/wiki/markets/raising-funds) · [Getting started](/wiki/foundations/getting-started) |

Microfinance and micropayments are, respectively, small-scale financial services — chiefly credit — for people underserved by conventional banks, and digital payment schemes for amounts so small that ordinary processing fees would swallow them. Though the two grew up in different disciplines, development economics and computer science, they confront the same underlying obstacle: the costs of executing a transaction are largely fixed, so they fall disproportionately on small transactions. A payment network's fee schedule and a bank's need to verify a borrower's circumstances both set a floor below which transacting stops being worthwhile.

Both fields treat the remedy as a design problem rather than a subsidy problem. Microcredit research redesigns the loan contract so that borrowers' own local knowledge substitutes for costly bank monitoring; micropayment research redesigns the settlement protocol so that many tiny payments are amortized into a few larger ones. This article outlines one influential line of work in each.

## The fixed-cost problem

Every exchange carries overheads that attach to the transaction rather than to the amount transacted — the classic subject matter of [transaction-cost economics](/wiki/economics/transaction-costs). In retail payments these overheads are measurable: processing an average United States debit card transaction has a base cost of roughly 21–24 cents (23–42 cents for credit cards), and fees on the Bitcoin network can exceed one dollar, so for genuinely tiny payments [the fee often exceeds the payment itself](https://arxiv.org/abs/1911.08520). Processing each micropayment individually is therefore uneconomic, which motivates aggregating many small payments into fewer larger ones.

Small-scale credit faces an informational analogue. The facts a lender needs — whether a borrower's project succeeded, whether a missed payment reflects genuine hardship — are held locally, among the borrower's peers, and cannot be observed directly by the bank. For loans measured in tens or hundreds of dollars, the sums at stake cannot support intensive verification by the lender, so the design question becomes how to elicit that local information cheaply and honestly.

| Domain | Binding fixed cost | Design response |
| --- | --- | --- |
| Micro-credit | Verifying borrower outcomes the bank cannot observe | Group lending mechanisms that harvest borrowers' local information |
| Micropayments | Per-transaction processing and settlement fees | Probabilistic aggregation of many payments into one settlement |

## Mechanism design for micro-credit

In [Redesigning Microcredit](https://academic.oup.com/book/26714/chapter/195542893), Ashok Rai and Tomas Sjöström treat the microloan contract as a mechanism design problem: how should a bank structure lending to poor borrowers who hold local information about one another that the bank itself cannot observe? In their companion model, borrowers observe each other's project outcomes but have only a limited ability to side-contract, so they [cannot write complete informal insurance contracts among themselves](https://academic.oup.com/restud/article-abstract/71/1/217/1590688). A well-designed bank mechanism can close that gap: the authors derive a lending scheme that efficiently induces mutual insurance, formalizing the Grameen Bank practice of encouraging borrowers to help one another through hard times.

Two results are central. First, joint liability — holding group members answerable for one another's loans — is by itself insufficient to induce efficient mutual assistance. Second, efficiency requires _cross-reporting_: each borrower submits reports to the bank about the others' outcomes. Cross-reports induce truthful revelation of project states, increase the bargaining power of unsuccessful borrowers, minimize deadweight punishment relative to contracts that lack them, and remain robust to borrower collusion against the bank. The chapter's broader prescription, taken up in later work on microfinance product design, is that efficient loan and savings contracts should blend discipline with flexibility — promoting timely repayment while permitting rescheduling in exceptional circumstances.

## What the randomized evidence found

The mechanism-design literature above asks how a microloan contract _should_ be built. A separate, later body of work asked whether expanding access to the resulting product changed borrowers' lives, and it is the reason the field's tone shifted between the 2000s and the 2010s.

The best-known study is the Hyderabad experiment of Abhijit Banerjee, Esther Duflo, Rachel Glennerster and Cynthia Kinnan, in which a lender opened branches in 52 randomly selected neighbourhoods. Access raised microcredit takeup by [8.4 percentage points](https://www.aeaweb.org/articles?id=10.1257/app.20130533). Investment and profits in businesses that already existed rose; overall consumption did not rise significantly; spending on durable goods rose while spending on what the authors call “temptation goods” fell. The study found no significant change in health, education or women's empowerment, and when the control neighbourhoods later gained access too, very few differences between the groups persisted.

Hyderabad was one of six randomized evaluations published together, run across six countries on four continents in urban and rural settings, with different lenders, loan terms and borrower populations. The volume's editors summarise the pattern as [“modestly positive, but not transformative”](https://www.aeaweb.org/articles?id=10.1257/app.20140287) effects.

That result does not undo the design work; it relocates it. If lowering the fixed cost of lending mostly enlarges the market rather than transforming the borrower, then the value of a cheaper transaction is the transaction itself — more people able to borrow, invest and repay at all — and not a downstream miracle. It is a useful discipline to carry into any argument that reducing on-chain fees will, by itself, produce a different kind of participant.

## Protocol design for micropayments

The payments literature attacks its fixed cost by amortization. In a probabilistic micropayment scheme, the payer locks the total payment value in an escrow and issues each micropayment as a lottery ticket that wins with probability _p_ and pays β currency units; on average only one on-chain transaction is settled per 1/_p_ tickets, cutting both fees and the data written to the blockchain. As surveyed in the MicroCash paper, early schemes by Wheeler (1996) and Rivest (1997) relied on a trusted central bank to audit the lottery, while decentralized successors such as MICROPAY and DAM replaced the bank with miners but forced tickets to be issued sequentially from each escrow — sustaining a high payment rate then requires creating over a thousand escrows per second, bloating the chain — and depended on heavy cryptography such as public-key operations and non-interactive zero-knowledge proofs across multiple communication rounds.

[MicroCash](https://arxiv.org/abs/1911.08520) (Almashaqbeh, Bishop and Cappos, 2020) is the first decentralized probabilistic framework to support concurrent micropayments. A novel escrow setup lets a customer declare the total number of tickets and post a balance covering all possible winning tickets, after which tickets can be issued in parallel, at high rates, from a single escrow. The lottery is non-interactive, requires only secure hashing and one communication round, and selects an exact number of winning tickets per round using a draw value derived from a future blockchain block — eliminating the variance risk that all tickets win or lose, and lowering the collateral the customer must post. Security against escrow overdraft, duplicate ticket issuance, lottery manipulation and invalid payments combines cryptographic checks with financial deterrents: customers post an additional penalty escrow that miners revoke upon detected cheating, with the minimum penalty derived from a game-theoretic model of rational participants.

In evaluation, a modest merchant machine processed 2,240–10,500 tickets per second — roughly 1.7–4.2 times the MICROPAY baseline — with aggregated payments about 60% smaller, while a customer could concurrently issue more than 33,000 tickets per second from one escrow; in simulated video-delivery and online-gaming workloads, MicroCash reduced blockchain transaction fees and stored data by about half. The paper also contrasts probabilistic lotteries with payment channels: channels require an escrow between each pair of parties along a payment path, and routing hubs charge relay fees that can exceed the micropayment being carried, a pressure that indirectly pushes channel networks toward centralization — whereas a single lottery escrow can pay many merchants directly with no per-ticket exchange fees.

## Relevance to Caper

The same arithmetic governs who can afford to participate in on-chain fundraising and governance, and Caper is a good test case precisely because it does not answer the question the same way on both sides.

**Trading is proportional.** A [caper](/wiki/foundations/what-is-a-caper) raises through a bonding-curve market, and the protocol's trade fee is charged as a fraction of the trade — 0.5% at instantiation. A fractional fee scales with the ticket, so a small buy pays a small fee and the fixed-cost floor this article describes does not appear. Small-ticket participation in [raising funds](/wiki/markets/raising-funds) is genuinely viable, and [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) can make granular payouts to many recipients rather than batching into a few large transfers.

**Governance is not.** Creating a [proposal](/wiki/governance/proposals) costs a flat fee in XRD — 500 at instantiation — and casting a [vote](/wiki/governance/voting) costs a flat fee of its own, 100 at instantiation, paid in XRD by the voter and checked for the exact amount. Neither scales with the size of the holding behind it, and a voter must additionally hold at least one governance token. That is the fixed cost of this article, reproduced on-chain: the fee is the same whether the ballot carries a large stake or a trivial one, so it falls hardest on the smallest participant, and below some holding size voting stops being worth doing.

Two points of accuracy are worth stating rather than glossing. The fee schedule is _platform-wide_, not per-caper: every caper trades and votes through one shared logic component that holds all four parameters, so no individual caper's governance can set or waive its own fees. And the numbers above are the values the component is instantiated with, not constants — one method rewrites all four, under the protocol admin badge. The design choice being made is deliberate: a flat fee is what prices spam, and pricing spam is what a fractional fee cannot do. The cost of that choice is the one microfinance has documented for fifty years, and it is paid by the smallest participant.

## References

1. Ashok Rai and Tomas Sjöström (2013). [Redesigning Microcredit](https://academic.oup.com/book/26714/chapter/195542893). In Nir Vulkan, Alvin E. Roth and Zvika Neeman (eds.), _The Handbook of Market Design_, Oxford University Press, ch. 9, pp. 249–265.
2. Ashok Rai and Tomas Sjöström (2004). [Is Grameen Lending Efficient? Repayment Incentives and Insurance in Village Economies](https://academic.oup.com/restud/article-abstract/71/1/217/1590688). _The Review of Economic Studies_ 71(1): 217–234.
3. Ghada Almashaqbeh, Allison Bishop and Justin Cappos (2020). [MicroCash: Practical Concurrent Processing of Micropayments](https://arxiv.org/abs/1911.08520). _Financial Cryptography and Data Security_ (FC 2020), Springer LNCS.
4. Abhijit V. Banerjee, Esther Duflo, Rachel Glennerster and Cynthia Kinnan (2015). [The Miracle of Microfinance? Evidence from a Randomized Evaluation](https://www.aeaweb.org/articles?id=10.1257/app.20130533). _American Economic Journal: Applied Economics_ 7(1): 22–53.
5. Abhijit Banerjee, Dean Karlan and Jonathan Zinman (2015). [Six Randomized Evaluations of Microcredit: Introduction and Further Steps](https://www.aeaweb.org/articles?id=10.1257/app.20140287). _American Economic Journal: Applied Economics_ 7(1): 1–21.

## Numerical pricing in AMMs and bonding curves

URL: https://caper.network/wiki/economics/numerical-pricing
Updated: 2026-08-09

|  |  |
| --- | --- |
| **Problem** | Turning a pool's invariant into a quotable price when the invariant cannot be solved symbolically for the unknown quantity |
| **Three answers in production** | Iterate to a tolerance (Curve) · approximate with logarithms (Balancer) · restrict the price domain and precompute (Uniswap v3) |
| **Curve StableSwap** | Newton–Raphson, loop bounded at 255 passes, exits when the iterate moves by 1 unit or less |
| **Balancer weighted math** | xy computed as exp(y · ln x); relative error bounded at 10−14 and deliberately widened against the trader |
| **Uniswap v2 / v3** | Constant product is closed form; v3 confines prices to ticks of 1.0001t and reads them from hard-coded constants |
| **Governance surface** | Amplification, pool weights and fees are voted parameters that decide which numerical method prices a trade |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve) · [Trading](/wiki/markets/trading) · [MEV and value extraction](/wiki/economics/mev-and-value-extraction) · [Liquidity bootstrapping pools](/wiki/economics/liquidity-bootstrapping-pools) |

An automated market maker publishes a rule that ties the balances in a pool together. Quoting a trade means solving that rule for the quantity the trader does not yet know. For some rules the solution is a formula the contract can evaluate once and be done. For others no such formula exists, and the contract has to reach the number some other way – by guessing and correcting, by approximating a function it cannot compute directly, or by refusing to price anything outside a set of values it worked out in advance.

Which of those a protocol picks is usually treated as an implementation detail, hidden below the tokenomics. It is not. The choice decides who absorbs the rounding, what the contract does when it cannot find an answer, and which parameters a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) is really voting on when it adjusts a pool. This page reads the three production answers out of the deployed source, and then looks at what a [bonding curve](/wiki/markets/bonding-curve) inherits from the same problem.

## When a price has a formula, and when it does not

Uniswap v2 is the easy case. The invariant is a product of two balances, and solving it for the output amount gives a formula with one multiplication and one division. [UniswapV2Library.getAmountOut](https://github.com/Uniswap/v2-periphery/blob/master/contracts/libraries/UniswapV2Library.sol) is four lines long: the input is scaled by 997/1000 to take the fee, then `numerator / denominator` ends it. There is no search and nothing to converge on. The only inexactness is the integer division at the end, which truncates.

Curve's StableSwap is not that case. Its invariant blends a constant-sum term, which holds a peg, with a constant-product term, which guarantees liquidity at the extremes, and the blend is controlled by an amplification coefficient. [Egorov's paper](https://curve.finance/files/stableswap-paper.pdf) sets the invariant out; the deployed contract does not attempt to invert it symbolically. Both quantities a trade needs – the invariant `D` for the current balances, and the post-trade balance `y` of the outgoing asset – are found by iteration.

Balancer's weighted pools fail in a third way. Their output formula raises a balance ratio to the power of a ratio of pool weights, and the EVM has no exponentiation for non-integer exponents. An 80/20 pool needs to compute something raised to the power 4, which is easy; a 60/40 pool needs the power 1.5, which is not. The rule is perfectly well defined and simply cannot be evaluated with the arithmetic the machine offers.

## Three answers to the same problem

**Iterate.** Curve's [get_D](https://github.com/curvefi/curve-contract/blob/master/contracts/pools/3pool/StableSwap3Pool.vy#L205) and [get_y](https://github.com/curvefi/curve-contract/blob/master/contracts/pools/3pool/StableSwap3Pool.vy#L387) each run a Newton–Raphson loop written as `for _i in range(255)`. Each pass computes a better estimate and compares it to the previous one; the loop breaks the moment the two differ by 1 or less, under a source comment that reads “Equality with the precision of 1”. That unit is the smallest representable amount, so the loop is asking for agreement to the last decimal place the token has. At ordinary balances it gets there in a handful of passes. The 255 is a ceiling, not an expectation.

**Approximate.** Balancer does not iterate. [LogExpMath.pow](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/solidity-utils/contracts/math/LogExpMath.sol) rewrites xy as exp(y · ln x) and builds both halves out of fixed-point series, carrying intermediate values at 20 decimals and switching to a separate 36-decimal path when the base sits within 0.1 of one, where precision matters most. The domain is bounded by the word size rather than by economics: the source derives the largest usable exponent as ln((2255 − 1) / 1020) = 130.70, then pins the constant at 130 “to have some safety margin”, with the negative bound at −41. A trade whose exponent lands outside that window reverts.

**Precompute.** Uniswap v3 avoids the question by shrinking the set of legal prices. Prices live on ticks of 1.0001t, and [TickMath.getSqrtRatioAtTick](https://github.com/Uniswap/v3-core/blob/main/contracts/libraries/TickMath.sol) converts a tick to a price with no loop at all: it decomposes the tick index into bits and multiplies a hard-coded constant for each set bit, nineteen constants covering the whole range from tick −887272 to 887272. Every one was computed off-chain and burned into the bytecode. The result is exact and costs a fixed amount of gas, and the price grid is discrete by construction – [the v3 paper](https://app.uniswap.org/whitepaper-v3.pdf) treats that granularity as the design, not a compromise.

The three sit on one trade-off. You can search for the answer and pay in iterations, approximate it and pay in error, or restrict the question and pay in expressiveness. None of them gets exactness for free.

## The error has to have a direction

An approximation that is sometimes high and sometimes low is not neutral in a market, because a trader can choose when to trade and the pool cannot. Balancer's answer is to make the error one-sided on purpose. [FixedPoint](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/solidity-utils/contracts/math/FixedPoint.sol) declares `MAX_POW_RELATIVE_ERROR = 10000`, a relative bound of 10−14, and then exposes two wrappers rather than one: `powDown` computes the raw power and subtracts the maximum possible error before returning, and `powUp` adds it. Whichever side of a trade the number lands on, the returned value is deliberately worse for the trader than the true power. Both wrappers also short-circuit when the exponent is exactly 1, 2 or 4, a case the source notes “occur often in 50/50 and 80/20 Weighted Pools” – those exponents are integers, so the exact path is available and the error correction is not applied at all.

Curve is blunter. In [get_dy](https://github.com/curvefi/curve-contract/blob/master/contracts/pools/3pool/StableSwap3Pool.vy) the amount paid out is computed as `(xp[j] - y - 1)`, with a bare subtraction of one unit before the fee is even taken. There is no comment. The unit goes to the pool.

Neither of these is an accident of floating-point arithmetic, and neither is disclosed in a front end. Rounding is a policy choice about who absorbs the residue of an inexact calculation, and in both protocols the answer is the liquidity providers rather than the trader – which is the same direction, and a much smaller magnitude, as the extraction covered under [MEV and value extraction](/wiki/economics/mev-and-value-extraction).

## An iteration budget is a safety property, not a gas optimisation

The obvious reading of `for _i in range(255)` is that it caps gas. The more useful reading is that it decides what happens when the maths does not cooperate. Curve's loop has no failure branch: if 255 passes go by without the iterate settling, the loop simply ends and the function returns the last value it held. Nothing reverts. The trade proceeds at whatever number the solver was holding when it ran out of attempts.

That is the general hazard in every iterative pricing routine. A bounded solver converts “I could not find the answer” into “here is an answer”, and the answer is a price somebody trades at. The interesting question about an iterative AMM is therefore not whether its mathematics is correct – it usually is – but what the contract does in the corner where the solver has not converged, and in which direction the unconverged estimate is wrong. An estimate that is still approaching the root from the generous side mints or pays out too much; one approaching from the other side merely short-changes the trader. Those two failures are not equally bad, and the difference is invisible unless a protocol writes the convergence direction down.

Caper's own curve carries a documented instance of exactly this. Its solver originally damped each Newton step toward a floor, which capped how fast the estimate could descend at one halving per pass. For a small payment against a mature curve the initial guess starts far above the root, and the damping meant the solver could exhaust its whole iteration budget while still above it – returning a number that would have minted too many tokens rather than reverting. The fix, recorded in the comment above the loop in `contracts/logic/src/lib.rs`, was to drop the damping for a hard domain floor, justified by the curve being convex on the interval so that a Newton step from any point lands at or above the root. The regression test is named for the exact cell that broke: `tokens_bought_converges_for_small_payments_on_mature_curve`.

## Governance sets the numerical regime, not just the economics

The parameters a DAO votes on are the same ones that decide how the solve behaves, which makes a routine parameter vote a change of method as well as a change of price.

Curve's amplification coefficient is the clearest case. It cannot be set outright; [ramp_A](https://github.com/curvefi/curve-contract/blob/master/contracts/pools/3pool/StableSwap3Pool.vy#L700) moves it over a window, requiring at least `MIN_RAMP_TIME` of 86,400 seconds since the last ramp began and at least that much again before the target time, and it rejects any move larger than a factor of ten in either direction, with an absolute ceiling of 106. During the window, `_A()` interpolates linearly on `block.timestamp`, so the invariant a trade is priced against is different in consecutive blocks even though nobody has traded. The rate limits exist because a discontinuous jump in the amplification would move the invariant, and therefore the pool's implied prices, in one step.

Balancer's weights work the other way round. Because the fast paths in `powUp` and `powDown` only trigger for exponents of 1, 2 and 4, a 50/50 or 80/20 pool is priced by exact integer arithmetic, and a pool with any other weighting is priced through the logarithm-and-exponential path with its bounded error and its explicit adjustment against the trader. [Balancer's weighted-math documentation](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-math.html) presents the weights as an economic knob. In the deployed code they also select which of two implementations runs. A governance vote that moves a pool from 80/20 to 75/25 has changed the pricing code path, not only the curve.

Neither protocol hides any of this – it is all in verified source. But it is not in the proposal text either. A treasury deciding pool parameters is making a numerical-methods decision whether or not anyone at the forum describes it that way.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) prices on a bonding curve rather than against a pool of counterparties, but it inherits the same asymmetry, and it resolves it the same way Curve does – by iterating in the direction that has no formula.

Selling is closed form. The cumulative amount of XRD the curve has taken at a given point is an explicit expression, so a sale evaluates it before and after and returns the difference. Nothing is searched for. Buying is the inverse of that expression, which has no closed form, so the contract solves it numerically: sixteen Newton passes against a tolerance of 10−7 XRD, seeded from a power approximation and clamped into the curve's valid interval. The convergence break is deliberately one-sided – it fires only when the residual is at or just below zero, never above – so an early exit cannot leave the solver on the over-minting side of the root. The mechanics of what that means for a trader, including the buy-versus-sell asymmetry it produces in practice, are covered under [Trading](/wiki/markets/trading).

The parameters that decide the shape of the curve are fixed in the deployed logic rather than voted, so there is no equivalent of a ramp changing the invariant under a pending trade. That is a narrower design than Curve's on purpose: less to govern, and correspondingly less that a governance decision can move without anyone noticing it moved.

## References

1. Curve. [StableSwap3Pool.vy](https://github.com/curvefi/curve-contract/blob/master/contracts/pools/3pool/StableSwap3Pool.vy) – deployed 3pool source; `get_D` and `get_y` Newton loops, the `get_dy` payout, and `ramp_A` / `_A()`.
2. Michael Egorov. [StableSwap – efficient mechanism for Stablecoin liquidity](https://curve.finance/files/stableswap-paper.pdf) – the invariant and the amplification coefficient.
3. Balancer. [LogExpMath.sol](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/solidity-utils/contracts/math/LogExpMath.sol) – `pow` as exp(y · ln x), the 20- and 36-decimal paths, and the derivation of the exponent bounds.
4. Balancer. [FixedPoint.sol](https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/solidity-utils/contracts/math/FixedPoint.sol) – `MAX_POW_RELATIVE_ERROR`, `powUp`, `powDown`, and the integer fast paths.
5. Balancer. [Weighted math](https://docs.balancer.fi/concepts/explore-available-balancer-pools/weighted-pool/weighted-math.html) – protocol documentation for the weighted-pool formula.
6. Uniswap. [UniswapV2Library.sol](https://github.com/Uniswap/v2-periphery/blob/master/contracts/libraries/UniswapV2Library.sol) – `getAmountOut`, the closed-form constant-product quote.
7. Uniswap. [TickMath.sol](https://github.com/Uniswap/v3-core/blob/main/contracts/libraries/TickMath.sol) – `getSqrtRatioAtTick`, the precomputed tick constants and the tick bounds.
8. Hayden Adams et al. [Uniswap v3 Core](https://app.uniswap.org/whitepaper-v3.pdf) – ticks, the 1.0001 spacing, and concentrated-liquidity pricing.
9. Caper. `contracts/logic/src/lib.rs` – `cumulative_xrd`, `compute_xrd_received` and `compute_tokens_bought_inner`, read directly for the Caper claims on this page.

## Personal Tokens

URL: https://caper.network/wiki/economics/personal-tokens
Updated: 2026-08-10

| Also called | Self-tokenization, creator tokens, social tokens (overlapping) |
| --- | --- |
| What it is | An individual issues a tradeable token that represents a claim on, or access to, their future work, attention, or success |
| Antecedents | Mike Merrill (2008, sold shares in himself); Bowie Bonds (1997, securitized future royalties) |
| Peak | 2020 "personal / social token" wave (Roll, Zap, and others) |
| Where it ended | Roll, the largest custodial issuer, served a frozen homepage through 2025 and its domain no longer resolves at all |
| Common failure mode | Holders own a claim on nothing they control – no shared treasury, no enforceable exit, custodial key risk |

A **personal token** is a tradeable token issued by an individual against themselves – a claim on, or access to, their future output, attention, or success. The practice is often called _self-tokenization_, and it overlaps with the broader categories of _creator tokens_ and _social tokens_. The recurring promise is the same: let a person be capitalized the way a company is, so that people who believe in someone can back them early and share in what follows.

## Antecedents

The idea predates blockchains. In 2008 the artist [Mike Merrill](https://www.kmikeym.com/) incorporated himself and sold shares in his own person, letting shareholders vote on decisions in his life – an early, deliberately literal experiment in treating an individual as a joint-stock enterprise. A decade earlier, in 1997, the banker David Pullman securitized David Bowie's back-catalogue royalties into [Bowie Bonds](https://en.wikipedia.org/wiki/Celebrity_bond), a bond that let investors buy a stream of one person's future income. Neither was a token, but both established the underlying move: an individual issuing a claim on their own future and selling it to backers.

## The 2020 wave

Cheap on-chain issuance turned a rare, bank-intermediated act into something anyone could do in an afternoon, and in 2020 a wave of personal and social tokens followed. [Contemporary coverage](https://www.forbes.com/sites/colinharper/2020/05/06/people-are-tokenizing-themselves-on-ethereum-why-personal-tokens-raise-red-flags/) was already flagging the risks. That June, the entrepreneur Alex Masmej sold [$ALEX](https://www.coindesk.com/markets/2020/06/30/the-man-who-tokenized-himself-gives-holders-power-over-his-life), raising roughly $20,000 and letting holders vote on his personal choices. Many such tokens were issued and traded through custodial platforms, the largest of which was Roll.

A parallel strand used [bonding curves](/wiki/markets/bonding-curve) rather than a custodial order book. [Zap](https://medium.com/the-zap-project/the-bonding-curve-revolution-4b5aa0e5f2cd), a protocol built around bonding curves, let anyone mint a personal token whose price rose and fell along a curve: backers _bonded_ the ZAP token to mint the personal token and could _un-bond_ to sell it back to the curve for ZAP. In 2020 [Ben Gravis](https://etherscan.io/token/0x45d36456967e3881c5bba8aa84b4f7d888afea13) became one of the first people to tokenize himself this way; the contract has been silent since April 2021. The curve gave holders something the custodial tokens lacked – a standing counterparty to sell back into – but it attached no shared treasury and no governance to the token, and the curve remained the issuer's own arrangement.

## Why most failed

The 2020 tokens are usually written off as a speculative bubble, but the more durable lesson is structural. Three things were typically missing:

- **No treasury the holders owned.** Buying a personal token generally funded a price, not a pooled balance sheet the backers had a claim on. The token was a bet on the issuer's trajectory, backed by nothing the holders controlled.
- **No enforceable exit.** Leaving meant selling into whatever bid existed. On custodial platforms that could evaporate; even the bonding-curve versions redeemed only against the issuer's own curve, which the issuer could stop maintaining.
- **Custodial and key risk.** Where a platform held the keys, its failure was the holders' failure. In early 2021 an attacker drained roughly $5.7 million from [Roll's hot wallet](https://protos.com/social-token-ethereum-crypto-roll-hack-million-tokens-uniswap/), and personal tokens minted on it fell sharply in a single week.

The through-line is that holders held upside and a sell button, and nothing in between. When trust in the creator or the custodian wavered, there was no owned collateral to fall back on and no defined way to redeem a share, because there was no share.

## What the record shows in 2026

The 2020 wave is usually described in the past tense but rarely checked. Three of its landmarks were re-verified first-hand for this page on 10 August 2026, and the results sharpen the argument above rather than soften it.

- **Roll, the largest custodial issuer, is gone.** The domain `tryroll.com` has no `A` record on the apex, `www`, or `app` at either Google's (`8.8.8.8`) or Cloudflare's (`1.1.1.1`) resolver. The Internet Archive's CDX index records its [last successful capture on 9 November 2025](https://web.archive.org/web/20251109081830/https://tryroll.com/) and its last capture attempt of any kind on 17 November 2025; every capture from 22 July 2025 onward returned a byte-identical homepage (the same CDX digest), so the site was frozen for months before the domain lapsed. The custody problem the hack exposed did not end with the hack – it ended with the platform, and with it any token page a holder might still have wanted to read.
- **The bonding-curve personal token has twelve events in its entire history.** The [Ben Gravis contract](https://eth.blockscout.com/token/0x45D36456967e3881c5bBA8AA84B4f7D888aFea13) has recorded exactly twelve token transfers since deployment, the first on 3 May 2020 and the last on 8 April 2021 at block 12,197,817 – read from Blockscout's keyless decoded-transfer API. Every one of the twelve is either a mint from the zero address or a burn back to it. Not one is a transfer between two holders. A handful of backers bonded, the same handful un-bonded, and the token has been silent for over five years: the curve worked exactly as designed and there was never a secondary life for it to protect.
- **The pre-blockchain experiment outlived the tokens.** [kmikeym.com](https://www.kmikeym.com/) still resolves and still serves Mike Merrill's shareholder record, eighteen years after he incorporated himself. The oldest version of the idea – a person, a share register, and a standing obligation to the holders – is the one still running.

Taken together these are not three separate failures. Custodial issuance died with its custodian, curve-only issuance died of having nothing to hold, and the arrangement that survived is the one where the claim was defined and the issuer stayed answerable for it.

## How a caper differs

A [caper](/wiki/foundations/what-is-a-caper) applies the same "individual as an institution" idea but supplies the two things the 2020 wave omitted. Buys along the [bonding curve](/wiki/markets/bonding-curve) fill a shared [treasury](/wiki/governance/execution) that every holder has an enforceable claim on, rather than vanishing into a price. And every holder has an [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): they can burn their vote and redeem a proportional share of that treasury – the same proportion that sets their weight in a [vote](/wiki/governance/voting). A backer is therefore never in the 2020 position of holding a claim on nothing; at any moment they can name their portion of the collateral and leave with it. This is what separates a personal token that is a bet on someone's mood from one that behaves like a small institution.

## Further reading

- [The Personal Caper](/blog/the-personal-caper) – from Bowie Bonds to self-incorporation, and what a personal token needs to be credible.
- [The Exit Right](/blog/the-exit-right) – why a redeemable, vote-weighted claim on a treasury is the load-bearing primitive.
- [How DAOs Fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) and [Curation Markets](/wiki/economics/curation-markets) – adjacent failure modes and the bonding-curve lineage.

## The personal caper

The 2020 wave gave a person issuance and a market price but nothing they owned behind it, so when trust broke the claim broke with it. A personal caper closes that gap with the two primitives that wave lacked: a treasury the token actually holds, and a binding exit that redeems a real share of it — the same weight, **(t·v) / (V·T)**, that decides a vote.

CAPER PROTOCOLThe personal caperSELF-INCORPORATIONIssuing a token for yourself is not new. The 2020 wave gave you a price and a sell button, and nothing behindthem. A personal caper adds the two things that were missing — a treasury you own and an exit right that paysout — so self-incorporation becomes a real claim, not a mood.THE 2020 PERSONAL TOKENTHE PERSONAL CAPERWhat you issueA token priced on whatevermarket will trade it.A token on a bonding curve —always priced, alwaysredeemable.Treasury behind itNone. A claim on sentiment, noton any assets.An owned treasury — XRDcollateral held in the caper’svault.Exit rightSell into whatever bid happensto exist that day.Redeem a real share of thetreasury:pct = ( t · v ) / ( V · T )When trust breaksDisowned; the price falls towhatever sentiment is left.You can still withdraw yourtreasury share and leave.GovernanceInformal, or none — no bindingsay for holders.Ranked (Borda) votes. Votes aresoulbound and earned; the weightthey carry scales with holdings.1997 · BOWIE BONDSThe first time a person incorporated their future income — and it took a bank and $55M of song royalties pledged ascollateral. A personal caper supplies the treasury and the exit natively; no bank required.Exit share equals vote weight — the same w that decides votes sets your treasury payout.caper.networkThe 2020 personal token vs a personal caper · an owned treasury and a binding exit right (pct = (t·v)/(V·T)) are what turn issuance into self-incorporation.

## How the vote weight and the exit actually work

The two claims above – that a holder's exit is enforceable and that it redeems the same proportion as their vote – are worth stating precisely, because the precision is what distinguishes them from the 2020 promises. Both come from one function in the protocol's logic package, and both were re-verified against the contract source at commit `76d7bf5`.

A member's weight is

`w = (t · v) / (V · T)`

where `t` is the governance tokens they hold, `v` the vote tokens they have accumulated, `V` the caper's total vote supply, and `T` its circulating token supply. Three properties follow, and each one answers something the 2020 wave left open.

### Votes are soulbound; the weight is not

Vote tokens are minted directly to the voter's account each time they vote and cannot be transferred – they are earned by participating and there is no market in them. But holdings enter the formula as a multiplicative factor, so a larger position is strictly more weight at the same participation. It is worth being blunt about this, because it is the usual place these designs are oversold: a caper is not a one-person-one-vote system with a soulbound badge. Participation and stake both count, and neither substitutes for the other – a holder who never votes has `v = 0` and therefore no weight at all, and a voter who holds nothing has `t = 0` and likewise none.

### Selling before settlement cuts your own vote

A ballot records the holdings behind it, but settlement does not trust that record. It reads each voter's live balance and clamps the weight to `min(held at vote, balance now)`. So a holder who votes and then sells into the rise has their own ballot reduced to whatever they still hold when the proposal settles. The 2020 personal token's holder could extract on sentiment and leave the same afternoon with their say intact, because there was no settlement to be present for. Here the vote and the position have to survive together.

### An exit is one transaction with two legs

Exiting requires both buckets – vote tokens and governance tokens, both non-zero – and pays out twice. That first condition is a gate rather than a formality: a holder who has never voted holds no vote tokens and so cannot exit at all. They can still sell their position back along the curve like any other holder, but the claim on pooled collateral belongs to the members who took part in deciding what the collateral was for. The treasury share is computed with the same `w` above, before the vote tokens are burned, so the proportion that decided a member's votes is the proportion of collateral they leave with. In the same transaction the governance tokens are sold back along the [bonding curve](/wiki/markets/bonding-curve) at its current price, less the trade fee. A leaver therefore takes their share of the treasury _and_ the curve's standing bid, and the caper's own [vote supply](/wiki/governance/voting) shrinks by exactly the weight that left. Nothing about that requires the issuer's cooperation, which is the whole of the difference from 2020.

## Principal–agent problem

URL: https://caper.network/wiki/economics/principal-agent
Updated: 2026-08-06

| Concept | Principal–agent problem — the welfare loss that arises when one party (the _agent_) acts on behalf of another (the _principal_) under conflicting interests and asymmetric information |
| --- | --- |
| Also called | Agency problem, agency dilemma, agency theory |
| Formalised by | [Stephen Ross (1973)](https://www.jstor.org/stable/1817064) and Barry Mitnick (1973); agency costs by [Jensen & Meckling (1976)](https://doi.org/10.1016/0304-405X(76)90026-X); hidden action by [Holmström (1979)](https://doi.org/10.2307/3003320) |
| Two frictions | [Moral hazard](https://en.wikipedia.org/wiki/Moral_hazard) (hidden action) and [adverse selection](https://en.wikipedia.org/wiki/Adverse_selection) (hidden information) |
| Agency costs | Monitoring + bonding + residual loss (Jensen–Meckling) |
| In a DAO | Token holders are principals; delegates, core teams, multisig signers and treasury managers are agents |
| Standard remedies | Transparency and monitoring, incentive alignment, bonding (skin in the game), reputation, competition, and [exit](https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty) |

The **principal–agent problem** is the economic friction that appears whenever one party — the _principal_ — hires or empowers another — the _agent_ — to act on its behalf, but the two have divergent interests and the principal cannot fully observe what the agent does. Because effort is hidden and incentives diverge, a self-interested agent will sometimes act against the principal's interest, and the resulting loss (plus everything spent trying to prevent it) is the cost of the relationship. It is one of the load-bearing ideas of modern economics, running from [corporate governance](https://en.wikipedia.org/wiki/Corporate_governance) to insurance to the design of every [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao).

The problem was formalised independently in 1973 by the economist [Stephen Ross](https://www.jstor.org/stable/1817064) and the political scientist Barry Mitnick, and it sits at the centre of the [theory of agency](https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem). Any organisation that separates ownership from control — shareholders from managers, citizens from officials, or token holders from the people who actually move a treasury — is a principal–agent relationship, and inherits its problems.

## Two information frictions: moral hazard and adverse selection

Agency problems come in two flavours, distinguished by _when_ the information gap bites.

- **[Moral hazard](https://en.wikipedia.org/wiki/Moral_hazard) (hidden action).** After the relationship begins, the principal cannot observe the agent's effort or choices — only a noisy outcome. A fund manager who takes excessive risk with someone else's capital, or a core team that under-delivers because no one can tell diligence from luck, is the canonical case. [Holmström's (1979)](https://doi.org/10.2307/3003320) _informativeness principle_ is the classic result here: an optimal incentive contract should condition pay on _every_ signal that carries information about the agent's action, and only on those signals.
- **[Adverse selection](https://en.wikipedia.org/wiki/Adverse_selection) (hidden information).** Before the relationship begins, the agent knows something the principal does not — their true competence, or the real quality of what they are offering. [Akerlof's (1970)](https://doi.org/10.2307/1879431) “market for lemons” showed how this can unravel a market entirely, as the parties who know they are low-quality are the keenest to transact.

Both frictions are symptoms of the same root: [asymmetric information](/wiki/economics/reputation-and-information). Where a principal could perfectly observe and verify an agent's behaviour, the problem would vanish; the interesting economics is entirely about what to do when they cannot.

## Agency costs: monitoring, bonding, and residual loss

[Michael Jensen and William Meckling (1976)](https://doi.org/10.1016/0304-405X(76)90026-X) gave the problem its most durable accounting. The total _agency cost_ of a relationship, they argued, is the sum of three parts:

- **Monitoring costs** borne by the principal — audits, dashboards, reporting requirements, oversight committees — to observe and constrain the agent.
- **Bonding costs** borne by the agent — posting collateral, accepting vesting or clawbacks, submitting to rules — to credibly signal they will behave.
- **Residual loss** — the welfare gap that survives even the optimal amount of monitoring and bonding, because eliminating the last increment of misalignment costs more than it is worth.

The framing matters because it kills the naive hope of a perfect fix: some residual loss is _efficient_. The design question is never “how do we make the agent perfectly faithful?” but “what mix of monitoring, bonding, and tolerated slack minimises the total?” [Eisenhardt's (1989)](https://doi.org/10.2307/258191) review remains the standard map of how those trade-offs shift with risk, observability, and outcome uncertainty.

## Standard remedies — and why none is complete

Every institution that manages other people's money or power leans on some combination of the same levers:

- **Transparency and monitoring** — make the agent's actions observable, which shrinks the hidden-action gap but never closes it and is itself costly.
- **Incentive alignment** — tie the agent's payoff to the principal's outcome (equity, performance pay, [treasury](/wiki/dao-governance/concepts/treasury/dao-treasury-management) exposure) so their interests converge.
- **Bonding and skin in the game** — require the agent to have something at stake that they lose by defecting.
- **[Reputation](/wiki/economics/reputation-and-information)** — repeated interaction lets a principal punish defection in future rounds, which disciplines an agent who values the relationship.
- **Competition** — a contestable market for the agent's role (managers, delegates, service providers) makes replacement a credible threat.
- **[Exit](https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty)** — Albert Hirschman's (1970) third lever: rather than voice a complaint, the principal simply leaves, taking their capital with them. A credible exit disciplines an agent more sharply than any complaint, because it is not up for negotiation.

None is a silver bullet. Contracts are [incomplete](https://en.wikipedia.org/wiki/Incomplete_contracts) — no clause anticipates every future state — and every remedy has a price, which is exactly why [transaction costs](/wiki/economics/transaction-costs) and residual loss never fall to zero.

## The principal–agent problem in DAOs

A DAO does not escape agency by being on-chain; it relocates it. Token holders are the principals, but they rarely execute decisions themselves. The agents are everywhere:

- **Delegates** who vote on behalf of thousands of dormant holders in [token-weighted](/wiki/dao-governance/concepts/voting/token-weighted-voting) systems;
- **Core teams and foundations** that set the roadmap and control the multisig;
- **Multisig signers** who hold the keys to the treasury between votes;
- **Service providers and treasury managers** paid to allocate the DAO's capital.

The on-chain twist is that monitoring is unusually cheap — every transaction and vote is public — while the other remedies are unusually weak. Delegates typically post no bond, competition for their seats is thin, and _exit_ for a dissenting holder usually means dumping the token into whatever market exists while the contested treasury stays behind. Accountability tooling such as [Karma](/wiki/dao-governance/tooling/analytics/karma) and [DeepDAO](/wiki/dao-governance/tooling/analytics/deepdao) exists precisely to restore the monitoring and reputation levers that off-chain institutions take for granted. Nearly every entry in the [catalogue of DAO failures](/wiki/dao-governance/concepts/analysis/how-daos-fail) — captured multisigs, rubber-stamp delegates, treasuries drained by insiders — is an agency problem wearing a governance costume.

## Why token holders delegate anyway: rational apathy

The deepest reason agency persists in DAOs is that monitoring is rational to _skip_. A holder with a small stake bears the full cost of researching a proposal but captures only a sliver of the benefit of voting well — the same [collective-action](/wiki/economics/commons-governance) logic that produces rational voter apathy in any large electorate. So most holders delegate or abstain, control concentrates among the few who show up, and the gap between the principals' interests and the agents' actions widens. Vitalik Buterin's critique of [coin-voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) is largely a catalogue of the agency failures this apathy invites. The design response is to make participation cheaper or more rewarding than passivity — or to give the disengaged principal a lever that does not require them to monitor at all.

## How Caper approaches this

Every [caper](/wiki/foundations/what-is-a-caper) inherits the principal–agent problem the moment holders stop executing decisions themselves. Caper narrows the agency slack along two axes, both outcome-level rather than novel machinery:

- **A standing exit, not just a vote.** The remedy Hirschman calls _exit_ is usually unavailable to a DAO member. In a caper it is a first-class action: a member can call `exit` at any time to redeem a share of the treasury equal to their canonical vote weight `w = (t·v) / (V·T)` — governance holdings _t_ times recorded votes _v_, over total vote supply _V_ and circulating supply _T_ (verified against `compute_vote_weight` and `exit` in `contracts/logic/src/lib.rs`). Because that formula pays on demand and the door is always open — no proposal to pass, no majority to win — an agent cannot strand a dissenting principal: they can walk with their share of the treasury the moment they lose trust. That is a credible outside option, the sharpest of the classic agency remedies, made [structural](/blog/the-exit-right).
- **Weight that decays without participation.** The same formula multiplies holdings by _recorded votes_: a holder who never votes has _v = 0_, and therefore zero weight and zero exit share, however large the bag. A large holding on its own cannot capture control; influence and the treasury claim both accrue to participation, which pushes back on the rational-apathy drift that hands DAOs to whoever bothers to show up.

Neither eliminates the residual loss Jensen and Meckling described — nothing does — but both are aimed at the levers on-chain governance usually leaves weakest. See [how proposals work](/wiki/governance/proposals) for the settle-then-execute path an agent's decision must clear.

## Reputation and information asymmetry

URL: https://caper.network/wiki/economics/reputation-and-information
Updated: 2026-07-26

|  |  |
| --- | --- |
| **Topic** | Information asymmetry, adverse selection, and the remedies of disclosure, reputation, and information design |
| **Field** | Information economics and market design |
| **Key concepts** | Lemons problem, voluntary disclosure, feedback mechanisms, Bayes correlated equilibrium, selection contests |
| **Related** | [Raising funds](/wiki/markets/raising-funds) · [Proposals](/wiki/governance/proposals) · [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) |

Information asymmetry arises when one side of a transaction knows materially more than the other: the seller of a used car knows its true condition, and the founder of a venture knows its real prospects, while the buyer or backer sees only what is shown. When the informed party cannot credibly communicate its private information, the predicted result is **adverse selection** — uninformed parties rationally discount every offer toward the average, high-quality sellers exit because the discounted price no longer compensates them, and the market fills with low-quality goods, or _lemons_.

Three broad remedies have been studied empirically and theoretically: voluntary disclosure, in which sellers publish their private information; reputation mechanisms, which record past behavior and expose it to future trading partners; and information design, in which a designer deliberately chooses what information participants observe. Evidence from online marketplaces, laboratory experiments, and contest theory shows that each can mitigate the problem, though none eliminates it entirely.

## Voluntary disclosure and the lemons problem

Used cars are the canonical lemons market: since Akerlof's 1970 analysis, information asymmetry between seller and buyer has been expected to cause adverse selection, which made the rapid growth of online used-car auctions — where buyers cannot inspect the vehicle at all — something of a puzzle. Studying transaction data from [eBay Motors](https://www.aeaweb.org/articles?id=10.1257/aer.101.4.1535), Lewis (2011) resolves part of that puzzle through voluntary disclosure: sellers post their private information directly on the auction page in the form of detailed descriptions and photographs. Disclosure works because the auction page defines a precise implicit contract — deliver the car as shown for the closing price — which protects buyers from adverse selection. Empirically, these online disclosures are important determinants of sale prices, and disclosure costs matter: they affect both how much sellers disclose and the prices realized, so lowering the cost of credible disclosure improves market outcomes.

A natural objection is that only high-quality sellers should want to disclose. [Shapiro and Huh (2021)](https://onlinelibrary.wiley.com/doi/10.1111/jems.12401) examine the opposite case: when do low-quality sellers voluntarily reveal negative information about their own products, in a setting where the only communication channel is cheap talk — no repeated purchases, no reputation, no warranties, and no inference of quality from prices? Cheap talk limits high-quality sellers' ability to separate, since any message they send can be costlessly imitated. Two forces nevertheless push low-quality sellers toward honesty: buyers' risk and loss aversion, because disclosure removes quality uncertainty and raises willingness to pay; and competition, because disclosure differentiates the product from rivals and softens price competition. Sellers thus trade off the _quality advantage_ of pooling with better products against the _information advantage_ of revealing their true type. Equilibria in which low-quality sellers honestly separate exist under both monopoly and duopoly, and the paper's motivating examples — voluntary flaw disclosure on eBay and on Craigslist, which has no reputation mechanism at all — suggest such honesty occurs in practice. This inverts the usual focus of the disclosure literature, in which high-quality sellers reveal and low-quality sellers conceal.

## Reputation mechanisms

Where disclosure addresses hidden information, reputation systems address hidden action — the moral hazard side of the [principal–agent problem](/wiki/economics/principal-agent) of a trading partner who could take payment and underdeliver. [Bolton, Katok, and Ockenfels (2004)](https://pubsonline.informs.org/doi/10.1287/mnsc.1030.0199) tested electronic feedback mechanisms of the kind used on eBay-like platforms in a laboratory experiment comparing three market institutions: a market with a feedback mechanism, a _strangers_ market with no feedback, and a _partners_ market in which the same pairs interact repeatedly. The feedback mechanism induced a substantial improvement in transaction efficiency — more trust and more trustworthy behavior — relative to the no-feedback strangers market. Reputation markets nonetheless fell short of partners markets. The reason is that reputational information has a public-goods character: the benefits of trust and trustworthiness accrue to the whole community rather than being captured by the individual who builds the reputation, so incentives are weaker than under bilateral repeated interaction. Electronic reputation mechanisms therefore only partially substitute for long-run relationships, a finding from which the authors draw design implications for improving online feedback systems.

## The information-design perspective

A complementary literature treats information itself as a design variable: rather than asking how participants can credibly reveal what they know, it asks what a market or contest designer should let participants observe. [Makris and Renou (2023)](https://econtheory.org/ojs/index.php/te/article/viewArticle/20231475) extend the core tool of this literature — Bayes correlated equilibrium, due to Bergemann and Morris (2016) — from static settings to multi-stage games, in which at each stage players receive private signals about past and current states, past actions, and past signals before choosing actions. They fully characterize the distributions over actions, states, and signals attainable in any (sequential) communication equilibrium of any expansion of the game — that is, under any additional information players might be given. This revelation-principle-style result bounds what any designer-chosen information structure can achieve in a dynamic strategic setting, without enumerating candidate structures one by one.

Design choices also shape how informative equilibrium behavior is about hidden types. In selection contests — grades, promotions, retention, job assignments — observed performance is a strategically manipulable signal of ability, because contestants can choose how risky their performance distribution is. [Fang and Noe (2022)](https://doi.org/10.1086/716920) show that when many contestants compete for few slots, strategic contestants adopt high-risk _gambling_ strategies, weakening the correlation between performance and true ability: competition can undermine meritocracy. Paradoxically, uncompetitive contest designs — lax standards (“lowering the bar”) and restricted candidate pools (“limiting the field”) — can make selection more meritocratic by damping risk-taking incentives, and policies that permit promoting candidates unlikely to be the very best strengthen the link between selection outcomes and genuine merit.

## Relevance to Caper

A launchpad is a lemons market: founders know more about a project's quality and intentions than prospective backers, and adverse selection predicts that backers will discount every raise toward the expected average unless credible information intervenes. The remedies surveyed above map directly onto Caper's structure. Transparent on-chain [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) lower the cost of credible disclosure by making a caper's finances observable rather than merely claimed — the condition Lewis identifies for disclosure to improve market outcomes. Founders [raising funds](/wiki/markets/raising-funds) can disclose voluntarily, and the experimental evidence on feedback systems suggests that the public record of a team's [proposals](/wiki/governance/proposals) and their execution can act as a reputation mechanism — substantially improving trust among strangers, while remaining an imperfect substitute for direct long-run relationships.

## References

1. Gregory Lewis (2011). [Asymmetric Information, Adverse Selection and Online Disclosure: The Case of eBay Motors](https://www.aeaweb.org/articles?id=10.1257/aer.101.4.1535). American Economic Review, 101(4), 1535–1546.
2. Dmitry Shapiro and David Seung Huh (2021). [Incentives of Low-Quality Sellers to Disclose Negative Information](https://onlinelibrary.wiley.com/doi/10.1111/jems.12401). Journal of Economics & Management Strategy, 30(1), 81–99.
3. Gary E. Bolton, Elena Katok, and Axel Ockenfels (2004). [How Effective Are Electronic Reputation Mechanisms? An Experimental Investigation](https://pubsonline.informs.org/doi/10.1287/mnsc.1030.0199). Management Science, 50(11), 1587–1602.
4. Miltiadis Makris and Ludovic Renou (2023). [Information design in multi-stage games](https://econtheory.org/ojs/index.php/te/article/viewArticle/20231475). Theoretical Economics, 18(4), 1475–1509.
5. Dawei Fang and Thomas Noe (2022). [Less Competition, More Meritocracy?](https://doi.org/10.1086/716920) Journal of Labor Economics, 40(3), 669–701.

## Schelling points and coordination

URL: https://caper.network/wiki/economics/schelling-points
Updated: 2026-07-24

|  |  |
| --- | --- |
| **Topic** | Game theory; coordination; decentralized oracles |
| **Named after** | Thomas Schelling |
| **Key mechanism** | Convergence on a salient option through mutual expectation, without communication |
| **Related** | [Voting mechanisms](/wiki/governance/voting-mechanisms) · [Proposals](/wiki/governance/proposals) · [Reputation and information asymmetry](/wiki/economics/reputation-and-information) · [Commons governance and collective action](/wiki/economics/commons-governance) |

A **Schelling point** (or _focal point_) is the option that people tend to choose in a coordination problem when they cannot communicate, because it stands out as the answer each participant expects the others to expect. The idea is named after the game theorist Thomas Schelling, who observed that strangers asked to meet in a city without agreeing on a time or place often succeed anyway by converging on a salient landmark at a salient hour. Nothing enforces the choice; it works purely through mutual expectation.

Focal points matter to decentralized systems because permissionless networks routinely ask dispersed, non-communicating actors to converge on a single answer — a vote outcome, a protocol decision, or a reported data value. This article reviews the experimental evidence on when focal points work, how that logic was turned into an oracle design, and why its incentive assumptions have known limits.

## Focal points in the laboratory

Experimental work shows that focal points are powerful but conditional. Crawford, Gneezy and Rottenstreich replicated Schelling's classic result under symmetric payoffs: in a "Chicago skyscrapers" matching game where both players stood to receive a hypothetical $100 for coordinating, [90 percent of subjects chose the salient landmark](https://doi.org/10.1257/aer.98.4.1443) (the Sears Tower), for an expected coordination rate of 82 percent. Introducing a minute payoff asymmetry — $100 for one player versus $101 for the other — largely collapsed the focal point: only about 60 percent still chose the landmark, and expected coordination fell to 52 percent, barely above the roughly 50 percent achievable by a payoff-blind mixed strategy. A moderate asymmetry ($100 versus $110) eroded it further, to 48 percent choosing the landmark and roughly 50 percent coordination.

Paid experiments with abstract X and Y labels confirmed the pattern: symmetric labeled games reached 64 percent expected coordination, while a slightly asymmetric version ($5 versus $5.10) fell to 38 percent, performing essentially like games with no labels at all. Subjects did not "freely dispose" of the negligible difference in order to exploit the salient label; they attended to their own payoffs, destroying the shared focal point even though ignoring the one-dollar gap would have raised everyone's expected earnings. The authors account for the observed pattern of miscoordination with a nonequilibrium level-k model whose anchoring type is biased toward payoff-salient choices.

The picture is not uniformly bleak. Isoni, Poulsen, Sugden and Tsutsui studied tacit bargaining problems — coordination games with genuine conflict of interest and no communication — in which each player's strategies were framed as proposals over which valuable objects she would take. There, [payoff-irrelevant spatial and relational cues acted as powerful focal points](https://doi.org/10.1016/j.euroecorev.2012.12.005), reducing coordination failures even in games with no efficient and equal division, and systematically producing unequal payoff distributions that players accepted rather than miscoordinate. In bargaining-framed settings with strong cues, focal points can survive payoff conflict rather than collapsing under it — a partial counterweight to the Crawford, Gneezy and Rottenstreich findings.

## SchellingCoin: coordination as an oracle

In 2014, Vitalik Buterin proposed [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed), a mechanism for bringing external data such as the ETH/USD price onto a blockchain without any trusted authority, by paying participants to converge on the same answer. The design rests on a game-theoretic wager: absent communication, "the truth is arguably the most powerful Schelling point out there," so honest reporting is the answer everyone expects everyone else to give. Participants first submit hashed values, then reveal them; the revealed values are sorted, submissions falling between the 25th and 75th percentile are rewarded, and the median becomes the consensus output. Buterin described the resulting equilibrium as an "infinitely recursive chain of logic" backed by nothing but mutual expectation — which is both its power and its fragility.

A companion post supplied a [concrete smart-contract implementation](https://blog.ethereum.org/2014/06/30/advanced-contract-programming-example-schellingcoin): 100-block epochs split into a commit phase (blocks 0–49, submitting a hash of sender and value) and a reveal phase (blocks 50–99). The commit-reveal structure is what enforces the focal-point game — during commitment no participant can see anyone else's vote, so the rational uninformed strategy is to submit the true value everyone else is expected to submit. Buterin suggested the pattern generalizes beyond price feeds to any publicly verifiable data feed, with decentralization and participant diversity as the main safeguards.

SchellingCoin remained a design sketch, but its commit-reveal focal-point game is now in production for _subjective_ disputes rather than price feeds: [Kleros](/wiki/daos/infrastructure/kleros) pays randomly-drawn, stake-weighted jurors to converge on the answer they expect other honest jurors to give, rewarding the coherent majority with tokens taken from the incoherent minority — a standing court built on exactly the "truth is the strongest Schelling point" wager.

## Attack vectors and the limits of rationality

Buterin acknowledged several attack vectors from the outset. Any entity controlling more than roughly half of the submissions can unilaterally set the median, so the mechanism inherits a majority-collusion assumption. Participants with a financial stake in the reported value can engage in "micro-cheating," subtly skewing their answers, and even small coalitions offering side payments can create competing focal points. The implementation post added structural concerns: if a single exchange dominates trading, all votes cluster around its price, so the focal point silently becomes a single point of failure when that exchange is disrupted; gas costs at epoch boundaries make direct participation expensive for small players, pushing toward pooling and thus re-centralization; and downstream uses such as stable-value assets built on the feed remain exposed to strategic large trades that move the focal value itself.

Ford and Böhme generalized the critique. Permissionless systems, they argue, cannot bound the incentives participants face: out-of-band payments, bribery, and side bets — such as shorting a token while attacking it — can make protocol-deviant behavior the profit-maximizing choice while remaining invisible to in-protocol incentive analysis. They describe bribery and discouragement attacks in which an adversary makes honest participation economically unattractive, so that rational players exit or defect and incentive-based security arguments break down. Their conclusion is metacircular: [assuming all participants are rational profit-maximizers creates exploitable blind spots](https://arxiv.org/abs/1910.08820), so that in open systems "it is rational to be irrational" — attackers who look irrational inside the model may be perfectly rational outside it. They recommend designing for resilience rather than incentive-compatibility alone: Byzantine fault tolerance against arbitrary behavior, behavioral realism, and social and institutional safeguards alongside technical ones. The point bears directly on Schelling-point mechanisms: an equilibrium sustained only by mutual expectation fails once a coalition can be paid to converge on a false focal point.

## Relevance to Caper

Caper governance depends on the same coordination logic. Token holders decide [proposals](/wiki/governance/proposals) through [on-chain voting](/wiki/governance/voting), and any execution path that consumes externally reported data inherits focal-point dynamics. The experimental record cautions that convergence on the "obvious" outcome is reliable mainly when participants' payoffs are close to symmetric; holders who acquired their tokens at different prices, or who differ in stakes and information (see [reputation and information asymmetry](/wiki/economics/reputation-and-information)), face exactly the kind of payoff asymmetry that eroded coordination in the laboratory. Designing [voting mechanisms](/wiki/governance/voting-mechanisms) that anticipate asymmetric incentives and out-of-band pressure is therefore a [security consideration](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), not only a fairness one.

## References

1. Vincent P. Crawford, Uri Gneezy, and Yuval Rottenstreich (2008). [The Power of Focal Points Is Limited: Even Minute Payoff Asymmetry May Yield Large Coordination Failures](https://doi.org/10.1257/aer.98.4.1443). American Economic Review, 98(4): 1443–1458.
2. Andrea Isoni, Anders Poulsen, Robert Sugden, and Kei Tsutsui (2013). [Focal points in tacit bargaining problems: Experimental evidence](https://doi.org/10.1016/j.euroecorev.2012.12.005). European Economic Review, 59: 167–188.
3. Vitalik Buterin (2014). [SchellingCoin: A Minimal-Trust Universal Data Feed](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed). Ethereum Foundation Blog.
4. Vitalik Buterin (2014). [Advanced Contract Programming Example: SchellingCoin](https://blog.ethereum.org/2014/06/30/advanced-contract-programming-example-schellingcoin). Ethereum Foundation Blog.
5. Bryan Ford and Rainer Böhme (2019). [Rationality is Self-Defeating in Permissionless Systems](https://arxiv.org/abs/1910.08820). arXiv preprint arXiv:1910.08820.

## Staking and slashing

URL: https://caper.network/wiki/economics/staking-and-slashing
Updated: 2026-07-30

| Concept | Slashing – destroying part of a validator's bonded stake as the penalty for provable misbehaviour |
| --- | --- |
| What it buys | Economic security: an attack costs the attacker capital rather than only opportunity |
| Two offence classes | Liveness (being offline) · safety (signing two conflicting messages, i.e. equivocation) |
| Ethereum penalty | Effective balance ÷ 4,096 up front, plus a correlation penalty that reaches the full balance if a third of the network is slashed together ([Electra spec](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md)) |
| Cosmos Hub penalty | 5% of the whole delegation for a double-sign, 0.01% for downtime, read live from [cosmoshub-4](https://cosmos-rest.publicnode.com/cosmos/slashing/v1beta1/params) on 30 July 2026 |
| Who actually pays | Delegators and pool depositors, not only the operator who erred |
| Governance angle | On most chains the slashing fractions are parameters set by the same stake they penalise |
| Related | [Cosmos Hub](/wiki/daos/networks/cosmos-hub) · [Lido DAO](/wiki/daos/staking/lido-dao) · [EigenLayer](/wiki/daos/staking/eigenlayer) · [Principal–agent problem](/wiki/economics/principal-agent) |

**Slashing** is the mechanism that turns a proof-of-stake validator's deposit into collateral. A validator posts stake, the protocol defines a short list of provable offences, and if the validator commits one the protocol destroys some of that stake. Rewards make honest operation profitable; slashing makes dishonest operation expensive. Without it, staking is a subscription fee with no downside, and a validator that signs two conflicting histories risks nothing but its future income.

For a DAO the interesting part is not the cryptography. It is that slashing is the one place in crypto where a protocol takes money from people who did nothing wrong, on terms that are usually set by a token vote. The delegator who picked a badly-run validator loses funds; the depositor in a staking pool can absorb a loss through a rebase; and the numbers that decide how much they lose are, on most chains, governance parameters. Slashing therefore sits directly on top of the [principal–agent problem](/wiki/economics/principal-agent): the person bearing the loss is rarely the person who caused it, and rarely the person who voted on its size.

## What bonded stake actually secures

The two offence classes are not symmetrical, and confusing them is the most common error in DAO discussion of validator risk.

- **Liveness faults** – the validator is offline and misses its duties. Nobody is harmed beyond the throughput lost, so the penalty is small and usually recoverable: on Ethereum a missed attestation forfeits the reward it would have earned; on Cosmos-SDK chains persistent absence gets the validator jailed and lightly slashed.
- **Safety faults** – the validator signs two conflicting blocks or attestations for the same slot. That is the raw material of a chain reorganisation, it can only really happen through a misconfigured setup running the same key twice or through deliberate attack, and it is punished severely.

The design goal is not to punish incompetence proportionally. It is to make the cost of an _attack_ exceed its profit, which is why the harshest penalties are reserved for correlated safety faults – many validators equivocating at once, the only pattern that can actually finalise two conflicting states.

## Ethereum: a schedule that punishes correlation, not error

Ethereum's penalties live in the [consensus specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) rather than in any governance system, and they come in two parts.

The first is immediate. A slashed validator loses its effective balance divided by `MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA`, which the [Electra specification](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) sets to 4,096: about 0.0078 ETH on a 32 ETH validator, and 0.5 ETH on the 2,048 ETH maximum introduced by [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251). Before the Pectra upgrade the divisor was [32](https://github.com/ethereum/consensus-specs/blob/master/specs/bellatrix/beacon-chain.md), so the up-front penalty on a 32 ETH validator was a full 1 ETH. Ethereum deliberately cut its own headline slashing penalty by a factor of 128, because a one-off operational mistake by a solo staker was never the thing the schedule needed to deter. The validator is also exited, and its withdrawal is pushed 8,192 epochs (about 36 days) into the future.

The second part is where the deterrence actually lives. Halfway through that waiting period, 4,096 epochs (about 18 days) after the event, the protocol applies a **correlation penalty** proportional to how much stake was slashed alongside you in the trailing window. The spec multiplies the total slashed balance by `PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX` = 3, caps it at the total active balance, and charges each slashed validator that fraction of its own balance. One validator slashed alone pays a rounding error. A third of the network slashed together saturates the multiplier and each participant loses essentially everything. The same event costs 128 times less or thousands of times more depending only on how many others did it with you.

Reporting is also priced. The whistleblower reward is the offender's effective balance divided by 4,096, of which the block proposer takes an eighth – and because the spec falls back to the proposer when no separate whistleblower is identified, in practice the proposer is credited the whole amount.

## Delegated proof of stake: the delegator pays too

On a Cosmos-SDK chain the penalty is a flat fraction of the validator's entire bonded stake, which includes every delegation pointed at it. Read live from [cosmoshub-4](https://cosmos-rest.publicnode.com/cosmos/slashing/v1beta1/params) (gaia v27.5.0, 30 July 2026), the [Cosmos Hub](/wiki/daos/networks/cosmos-hub) parameters are:

| Double-sign slash | 5% of bonded stake, plus permanent tombstoning of the validator |
| --- | --- |
| Downtime slash | 0.01%, plus a 600-second jail |
| Liveness window | 10,000 blocks, of which at least 5% must be signed |
| Unbonding period | 1,814,400 seconds, i.e. 21 days ([staking params](https://cosmos-rest.publicnode.com/cosmos/staking/v1beta1/params)) |

Two things follow. First, the liveness bar is extremely forgiving: a validator only has to sign 500 of any 10,000 blocks, so it can miss 9,500 in a row before the chain jails it. The chain is not really trying to police uptime by slashing, and treating downtime slashing as a meaningful risk misreads the parameters.

Second, the 5% equivocation slash lands on the delegators. They did not run the duplicate signer, they cannot exit inside the 21-day unbonding queue, and their only real control was the choice of validator. Delegated proof of stake converts an operational question into a credit question: picking a validator is underwriting it. This is the same structural pattern as [delegating a vote](/wiki/dao-governance/concepts/voting/voting-and-delegation), with the difference that a bad delegate costs you influence while a bad validator costs you principal.

## Pooled staking: whose bond, whose loss

Liquid staking protocols sit between the two and have to answer the question explicitly: when a validator in the pool is slashed, does the operator eat it or do the depositors?

Lido's Community Staking Module answers with a bond. Its [penalties documentation](https://docs.lido.fi/run-on-lido/csm/penalties) states that the bond "acts as collateral for all validators under your Node Operator," and that slashing losses are assessed and deducted from that bond after the validator withdraws. The same schedule prices adjacent failures that are not protocol slashing at all – 0.258 ETH for ejection after repeated poor performance, 0.1 ETH for missing a requested exit deadline, 0.02 ETH for pulling an uploaded key. Most of the operator's real downside is this private penalty schedule rather than the consensus layer's.

When losses exceed what the bond can cover, they surface at the token layer. Lido's [Burner](https://docs.lido.fi/contracts/burner) contract burns stETH shares and keeps two separate counters, cover and non-cover, precisely because a "cover" burn exists to absorb a staking loss by reducing total pooled ETH. That is socialisation with an audit trail: every stETH holder pays a slice through the rebase, and the counters record how much was ever paid that way. For a DAO treasury holding a liquid staking token, that is the exposure to model – not the headline slashing fraction, but the size of the operator bonds standing in front of it.

## Programmable slashing: restaking and AVS-defined offences

[EigenLayer](/wiki/daos/staking/eigenlayer) generalised the mechanism. Instead of a fixed protocol-defined offence list, an actively validated service defines its own conditions and its own penalty, and operators allocate a portion of their stake to be slashable under them. The [AllocationManager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/AllocationManager.md) contract documents the shape: the service creates operator sets, names a single authorised slasher address, and calls `slashOperator` with `wadsToSlash` in parts of 1e18 – so anywhere from a rounding error to 100% of the allocated magnitude. The documentation is blunt that "slashing is instant and irreversible," and that the only conditions the core protocol enforces are the registration and allocation ones. What counts as an offence is entirely the service's business. Operators also stay slashable for a deallocation delay after deregistering, so committing a fault and walking out does not work.

The consequential design choice is where the money goes. A normal operator set sends slashed funds to a burn address. A _redistributing_ operator set sends them to a named recipient chosen at creation ([ELIP-006](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-006.md), merged April 2025). Burning is wasteful but incentive-neutral; redistribution funds a real insurance claim, and also means the party that profits from a slash can be the party that defines the offence and holds the slasher key. Any DAO considering staking its treasury into a restaking service is underwriting that service's private legal system, and should read who receives the proceeds before reading the yield.

## The governance problem: the same stake votes on its own penalties

Three overlapping conflicts make this a governance topic rather than an infrastructure one.

1. **The penalised set writes the penalty.** On Cosmos-SDK chains the slashing fractions are chain parameters amended by an on-chain proposal, and voting power is bonded stake. The people whose capital is at risk decide how much of it is at risk, which biases every such parameter in one direction over time. Ethereum reaches the opposite answer by putting the schedule in the consensus spec, where changing it requires a network upgrade rather than a vote, and by making the penalty depend on correlation rather than on anyone's judgement.
2. **The same tokens do two jobs.** Stake bonded for economic security is usually the same stake that carries governance weight, so the security budget and the electorate are one pool. That coupling is why validator sets shade into political blocs: on Cosmos Hub a delegator who does not vote has their validator's vote cast on their behalf, so choosing an operator for uptime quietly assigns a proxy. See [Cosmos Hub](/wiki/daos/networks/cosmos-hub) for how that default plays out in real turnout figures.
3. **Nobody prices the tail.** Slashing schedules are built for correlated attacks, but the losses DAOs actually book come from mundane single-operator errors, and the fee those errors generate flows through bonds and rebases rather than through anything a governance forum discusses. A treasury that holds liquid staking tokens has an unvoted credit exposure to a handful of node operators.

The general lesson generalises past validators: a penalty is only a deterrent if it lands on the decision-maker. Where it lands on someone else, it is an insurance premium being collected without a policy. Compare [fee switches](/wiki/economics/fee-switches-and-value-accrual), where governance argues for years about redistributing revenue it can see, while loss-sharing rules of this kind are usually inherited rather than chosen.

## How Caper approaches this

Caper has no validators, no bonded stake and no slashing. It is a DAO protocol rather than a consensus protocol, so it inherits [Radix](https://www.radixdlt.com/)'s validator economics and never penalises its own members.

What it has instead is the opposite lever. A member who thinks the organisation has gone wrong does not need a penalty to be levied on anyone: they can leave and take a proportional share of the treasury with them, which makes the cost of bad governance fall on whoever stays rather than on whoever can be blamed. The share is the member's canonical vote weight, and it is a product of both what they hold and how much they have voted, so a large position alone neither captures control nor commands the treasury. See [What is a caper](/wiki/foundations/what-is-a-caper) and [rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights).

## References

- [Ethereum consensus specifications — phase0 beacon chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) (slashing constants, `EPOCHS_PER_SLASHINGS_VECTOR`, `process_slashings`)
- [Ethereum consensus specifications — Electra](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) (`MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA` = 4,096, `WHISTLEBLOWER_REWARD_QUOTIENT_ELECTRA`)
- [Ethereum consensus specifications — Bellatrix](https://github.com/ethereum/consensus-specs/blob/master/specs/bellatrix/beacon-chain.md) (the previous divisor of 32 and `PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX` = 3)
- [Cosmos Hub slashing parameters](https://cosmos-rest.publicnode.com/cosmos/slashing/v1beta1/params) and [staking parameters](https://cosmos-rest.publicnode.com/cosmos/staking/v1beta1/params), read live from cosmoshub-4
- [Lido CSM — Penalties](https://docs.lido.fi/run-on-lido/csm/penalties) and [Lido — Burner contract](https://docs.lido.fi/contracts/burner)
- [EigenLayer — AllocationManager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/AllocationManager.md) and [ELIP-002: Slashing via Unique Stake and Operator Sets](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md), with [ELIP-006: Redistributable Slashing](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-006.md)

## Token unlocks and vesting schedules

URL: https://caper.network/wiki/economics/token-unlocks-and-vesting
Updated: 2026-08-06

| Mechanism | A pre-committed schedule that releases already-minted tokens to insiders over time, rather than at the moment they are granted |
| --- | --- |
| Standard shape | A one-year **cliff** (nothing releases), then three years of linear or monthly vesting – the shape [UNI](https://blog.uniswap.org/uni) and [ARB](https://docs.arbitrum.foundation/token-supply) both use |
| Enforced by | A vesting contract ([OpenZeppelin `VestingWallet`](https://docs.openzeppelin.com/contracts/5.x/api/finance), [Sablier Lockup](https://docs.sablier.com/concepts/lockup/stream-shapes)) or, off-chain, by a contract nobody can audit |
| Governance catch | Locked tokens usually still vote. A vesting vault exists so holders “can vote and delegate votes with their locked tokens” ([Element Council](https://docs-delv.gitbook.io/element-developer-docs/governance-council/council-protocol-smart-contracts/voting-vaults/vesting-vault)) |
| Scale | $97.43B of tokens unlocked across 2025, of which $18.77B was insider allocation ([Tokenomist, 2025 review](https://insights.unlocks.app/2025-token-unlocks-review-a-complete-breakdown-of-emissions-insider-vesting-and-market-impact/)) |
| Related | [Airdrops and token distribution](/wiki/economics/airdrops-and-token-distribution) · [DAO tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) · [Vote-escrow tokenomics](/wiki/dao-governance/concepts/voting/vote-escrow) · [Token valuation](/wiki/economics/token-valuation) |

A **vesting schedule** is a promise about when tokens that already exist become usable by the person they were granted to. A **token unlock** is that promise coming due. Almost every DAO token in circulation was launched with one: a genesis allocation is carved up between the community, the treasury, the team and the investors, and the last two categories are put behind a clock so that the people closest to the project cannot sell into the first week of trading.

The schedule is usually treated as a market fact – a date on a calendar that traders watch and everyone else ignores. For a DAO it is a governance fact first. An unlock does not create tokens; it changes who can move them, and in most designs the votes attached to those tokens were never locked in the first place. That gap between _voting_ and _vesting_ is where the interesting failures live, and it is the reason this page sits alongside [airdrops](/wiki/economics/airdrops-and-token-distribution) and [tokenomics](/wiki/dao-governance/concepts/treasury/dao-tokenomics) rather than in a trading section.

## The anatomy of a schedule

Four parameters describe nearly every schedule in use:

- **Start.** Usually the token generation event (TGE), sometimes a contributor’s start date, occasionally a date before the token existed.
- **Cliff.** A period during which nothing releases at all. OpenZeppelin’s [`VestingWalletCliff`](https://docs.openzeppelin.com/contracts/5.x/api/finance) is explicit that the cliff “not only makes the schedule return 0, but it also ignores every possible side effect from calling the inherited implementation” – the cliff is a hard gate, not a delayed start.
- **Duration and cadence.** After the cliff, tokens release continuously (per second, per block), in steps (monthly), or in a shaped curve. The base `VestingWallet` implements a straight linear curve and takes only `beneficiary`, `startTimestamp` and `durationSeconds`.
- **Revocability.** Whether the granter can claw back the unvested remainder if the recipient leaves. [Sablier](/wiki/dao-governance/tooling/treasury/sablier) streams are cancelable by design: “If at any point during April Alice wishes to get back her tokens, she can cancel the stream and recover what has not vested yet.”

Those four knobs generate a surprisingly large family of shapes. Sablier’s [Lockup shapes](https://docs.sablier.com/concepts/lockup/stream-shapes) enumerate ten in production use, including an _unlock cliff_ for “companies who want to distribute tokens to their investors using a cliff followed by linear vesting but also want to unlock some liquidity at the beginning,” and a _backweighted_ shape in which “little vests early on, and large chunks vest towards the end.” The choice between them is a real design decision with real distributional consequences, but the industry default remains the venture-capital shape imported wholesale from equity: one-year cliff, four-year total.

The knob that matters most is the one that does not appear in any of those parameters: whether the schedule is enforced by a contract at all. A vesting contract is a public, checkable object. An off-chain lockup agreement between a foundation and an investor is a promise, and the only evidence a DAO ever gets that it was honoured is the absence of selling. Where a project publishes vesting contract addresses, the schedule is auditable; where it publishes only a pie chart, it is not.

## An unlock is not an emission

The two get conflated constantly, and they are different events with different victims. An **emission** mints new tokens and dilutes everyone proportionally. An **unlock** mints nothing – the tokens were counted in total supply from day one – and dilutes nobody. What it changes is the _float_: the quantity that can actually be sold.

Arbitrum runs both, which makes it a clean illustration. The 10 billion ARB minted at genesis is fixed except for governance-authorised inflation: new ARB “can be minted at a rate of 2% of its supply per year _at most_, with the first of these mints becoming eligible on March 15, 2024” ([Arbitrum Foundation](https://docs.arbitrum.foundation/concepts/arb-token)). That is the emission. Separately, the 26.94% held by team and contributors and the 17.53% held by investors were locked from the start and release on a schedule. That is the unlock, and it moves roughly 4.4 billion tokens from the “exists but cannot move” column to the “can move” column without minting a single one.

This is why fully diluted valuation and market capitalisation diverge so violently in the first years of a token’s life, and why a low float at listing is not the bullish signal it is often read as – it is a statement about how much supply has yet to arrive. See [token valuation](/wiki/economics/token-valuation) for what that does to price discovery, and [token velocity](/wiki/economics/token-velocity) for what it does to the demand side.

## What real schedules look like

Two canonical examples, both fully documented by their issuers.

**Uniswap (September 2020).** Of 1 billion UNI, [the launch post](https://blog.uniswap.org/uni) allocated “21.266% to team members and future employees with 4-year vesting,” “18.044% to investors with 4-year vesting,” and “0.69% to advisors with 4-year vesting,” against 60% to community members. The community share was itself released on a schedule – the governance treasury received 43% of total supply across four years, front-loaded 40/30/20/10. After year four, “a perpetual inflation rate of 2% per year will start.” Note what that combination does: for four years the dominant supply event is unlocking, and only afterwards does dilution take over.

**Arbitrum (March 2023).** The [published supply table](https://docs.arbitrum.foundation/token-supply) gives 35.28% to the DAO treasury, 26.94% to team and contributors, 17.53% to investors, 11.62% to the airdrop, 7.50% to the Foundation and 1.13% to DAOs building on Arbitrum. “The team, contributor, and investor tokens unlock over a 4 year period, starting from 16 March 2023,” with the first unlock on 16 March 2024 and monthly thereafter. The Foundation’s own tranche is on a different shape entirely: four years from 17 April 2023, unlocking _every second_. One organisation, two schedules, and only one of them produces a headline date.

The contrast is the practical lesson. A per-second stream and a monthly step release identical quantities over identical horizons, but the monthly one manufactures twelve scheduled events a year at which a large quantity becomes sellable simultaneously. The cadence, not the total, is what creates the event.

## Locked stock still votes

Here is the part that a supply-side reading misses entirely. Vesting locks _transfer_. It does not, by default, lock _voting power_, and several major governance frameworks deliberately preserve the vote precisely so that locked holders can participate.

Element’s Council protocol makes the intent explicit in its [Vesting Vault](https://docs-delv.gitbook.io/element-developer-docs/governance-council/council-protocol-smart-contracts/voting-vaults/vesting-vault) specification: “Grant holders should be able to vote and delegate votes with their locked tokens,” and the vault exists so that “community members can vote with vested but unclaimed tokens and unvested tokens.” The reasoning is defensible – a contributor with a four-year grant arguably has _more_ long-term exposure than someone who bought yesterday, and disenfranchising them for four years would hand governance to the float. But it has a consequence worth stating plainly:

**In a DAO with a standard four-year insider vest, insiders hold their full voting weight from day one and acquire their liquidity later.** Control is not vested. Only the exit is. That inverts the alignment story usually told about vesting, which claims the lock keeps insiders committed. What the lock actually does is separate the moment they can decide things from the moment they can leave – and it puts the deciding first.

The same asymmetry can be bought outright. When Lido placed 2% of LDO supply with strategic funds in 2022, the terms stated that the tokens would be "unlocked" with "full voting power … granted immediately upon closing of the sale" — buyers paying a 50% premium above a 7-day average for a governed position with nothing vested, while contributors on the same cap table waited out their cliffs. See [OTC placements and market-maker loans](/wiki/dao-governance/concepts/treasury/otc-placements-and-market-maker-loans).

Two failure modes follow. The first is quiet: a governance token whose voting distribution is far more concentrated than its circulating-supply distribution suggests, because the locked tranches vote and the float is scattered across thousands of small holders who mostly do not. Any turnout analysis run against circulating supply rather than against total voting power will overstate how decentralised the electorate is. The second is sharper: as a cliff approaches, the interests of a large voting bloc and the interests of the protocol can diverge for entirely mechanical reasons – a holder about to become liquid has a different view of a proposal that affects near-term price than one who does not. This is the same coupling problem [vote-escrow designs](/wiki/dao-governance/concepts/voting/vote-escrow) attack from the other direction, by making the lock a _condition_ of the vote rather than an accident alongside it.

The measurable version of the question, for anyone auditing a DAO: does the governance contract read balances, or does it read a vesting vault as well? If the latter, circulating supply tells you nothing about the electorate. See [token-weighted voting](/wiki/dao-governance/concepts/voting/token-weighted-voting) for how that weight is counted, and [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) for what happens when it concentrates.

## The cliff as a scheduled event

Because a schedule is public and pre-committed, an unlock is one of the few genuinely predictable events in a crypto market – which means it is priced, positioned around, and hedged well in advance. The size is not marginal. Tokenomist’s [2025 review](https://insights.unlocks.app/2025-token-unlocks-review-a-complete-breakdown-of-emissions-insider-vesting-and-market-impact/) puts “$97.43B released throughout the year” across tracked tokens, split $18.77B to insider allocations and $78.66B to community, ecosystem, treasury and liquidity sources. Insider vesting is therefore a minority of the flow by value – roughly a fifth – but it is the concentrated fifth, and the fifth that arrives on named dates. The review notes cliff unlocks were “heavily concentrated in the first half of 2025,” while linear unlocks were “dominated by high-circulation ecosystem tokens.”

Care is warranted with the causal claim that usually accompanies these numbers. The event is known months ahead, so any price effect that survives is a statement about market depth and about who is willing to take the other side, not evidence that unlocking is destructive per se. A schedule that releases the same quantity continuously produces no event to trade against at all. The design question is not whether to release insider tokens – they were granted – but whether to release them in a shape that creates a coordination point.

For a DAO treasury, the operational consequence is concrete: an unlock calendar is a liquidity calendar. Any treasury holding its own token, running a buyback, or planning a large denominated payment should know where its own insider unlock dates sit relative to those actions. See [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## Design responses

The industry has converged on a handful of answers, none of them complete.

- **Stream instead of step.** Replace the monthly tranche with a per-second release. Arbitrum’s Foundation tranche does this, and [Superfluid](/wiki/dao-governance/tooling/treasury/superfluid) and [Sablier](/wiki/dao-governance/tooling/treasury/sablier) both productise it. It removes the coordination point without changing the total, and it is close to free to adopt.
- **Backweight the curve.** Sablier’s backweighted shape vests “little early on, and large chunks vest towards the end,” which extends real commitment beyond the nominal duration. The cost is that it makes contributor grants worth less in present-value terms, so it has to be paid for in size.
- **Make grants cancelable.** A cancelable stream converts a grant into something closer to salary: leave early and the remainder returns to the treasury. This is standard for [contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) and rare for investor allocations, which is itself informative about where the bargaining power sits.
- **Separate the vote from the vest deliberately.** Either disable voting for unvested balances, or require locking as a condition of voting (the [ve](/wiki/dao-governance/concepts/voting/vote-escrow) route). What is hard to defend is the accidental middle, where transfers are locked and votes are not because nobody chose either way.
- **Publish the contracts, not the pie chart.** A schedule is only a commitment if it is checkable. Vesting contract addresses, the cliff date, and the cadence belong in the same document as the allocation table.

All of these are refinements of the same underlying model: a fixed allocation set at launch, released against a clock. The alternative is not to have an allocation table at all, which is where the next section goes. See also [progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization), which is the governance-side version of the same staged-handover idea.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no vesting schedule, because it has nothing to vest. There is no genesis allocation, no cliff, and no calendar-gated release anywhere in the contracts. Tokens are minted on demand by a [bonding curve](/wiki/markets/bonding-curve) when someone buys, so there is no pre-mined block held back from the market and released against a clock.

The founder is still paid, but the schedule that governs it is the curve rather than the calendar. A slice is taken from each buy at a rate that starts at the collateralization peak when the caper is empty and tapers linearly to zero by the time 30% of the curve cap has been sold. The slice is split in the curve’s own composition – two-thirds as XRD off the payment, one third as a share of the newly minted tokens – and the token leg is tithed 30:1, so thirty parts go to the founder and one part to the Commons, which is $CAPER’s own treasury. Because the peak rate is bounded in the contract, the founder’s token leg has a structural ceiling of 5% of supply rather than a number chosen in a spreadsheet. The founder can withdraw whatever has accrued at any time; there is no lock to wait out.

Two properties of that arrangement are worth naming against the rest of this page. First, the rate is front-loaded but the take is not: the highest _share_ is charged when the caper is smallest, so the largest _amounts_ arrive somewhere in the middle rather than at the start. Second, and more to the governance point, there is no date on which a large locked block becomes sellable, because nothing was ever locked. The supply that exists is the supply that has been bought.

Members get their liquidity from the same place: [exit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is available continuously, and the share it pays is the member’s canonical voting weight – the combination of tokens held and votes cast, not tokens alone. That closes the gap this page opens. Where a conventional schedule vests the exit and leaves control unvested from day one, a caper attaches the two to the same number and lets both run continuously. The exact formulas live on the [bonding curve](/wiki/markets/bonding-curve) and [voting](/wiki/governance/voting) pages.

## References

- Uniswap, [Introducing UNI](https://blog.uniswap.org/uni) (16 September 2020) – the genesis allocation and the four-year vest.
- Arbitrum Foundation, [What is the token circulating supply?](https://docs.arbitrum.foundation/token-supply) and [The $ARB token: a conceptual overview](https://docs.arbitrum.foundation/concepts/arb-token) – allocation table, unlock dates, and the 2% maximum annual mint.
- OpenZeppelin Contracts, [Finance: `VestingWallet` and `VestingWalletCliff`](https://docs.openzeppelin.com/contracts/5.x/api/finance) – the reference implementation of a linear vest with a cliff.
- Sablier, [Lockup stream shapes](https://docs.sablier.com/concepts/lockup/stream-shapes) and [Lockup overview](https://docs.sablier.com/concepts/lockup/overview) – the ten production shapes and stream cancelation.
- Element Council protocol, [Vesting Vault](https://docs-delv.gitbook.io/element-developer-docs/governance-council/council-protocol-smart-contracts/voting-vaults/vesting-vault) – voting and delegation with unvested tokens.
- Tokenomist, [2025 Token Unlocks Review](https://insights.unlocks.app/2025-token-unlocks-review-a-complete-breakdown-of-emissions-insider-vesting-and-market-impact/) – annual released value and the insider / non-insider split.

## Token valuation

URL: https://caper.network/wiki/economics/token-valuation
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Topic** | Economic models of how blockchain tokens acquire and sustain market value |
| **Key approaches** | Transactional-demand asset pricing, ICO theory, equity-like cash-flow analogs, automated market maker microstructure |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve), [Trading](/wiki/markets/trading), [Sky (formerly MakerDAO)](/wiki/daos/stablecoins/sky-dao) |

Token valuation is the study of how blockchain tokens acquire and sustain market value. Because most tokens confer no legal claim on a firm's earnings, the discounted-cash-flow tools of equity analysis apply only imperfectly; economic research has instead modelled tokens as claims on the future usage of the platforms they power, with prices determined by transactional demand, expectations about adoption, and the mechanics of the markets in which they trade.

The literature spans formal asset-pricing theory, empirical work on Bitcoin and initial coin offerings (ICOs), practitioner valuations of governance tokens with equity-like value accrual, and analysis of the automated market makers that quote token prices algorithmically.

_See also: [token velocity](/wiki/economics/token-velocity) — why a token that is only spent, never held, accrues little value regardless of how much the network is used._

_See also: [virtual economies](/wiki/economics/virtual-economies) — the measurement tradition that network-level valuation descends from, and the record of what issuers did with the policy power it left them._

## Tokens as claims on platform adoption

The most direct theoretical treatment prices a token from the demand of the people who use it. In the [dynamic asset-pricing model of Cong, Li, and Wang](https://academic.oup.com/rfs/article-abstract/34/3/1105/5891182), tokens enable peer-to-peer transactions on a digital platform, and the equilibrium token price is determined by aggregating heterogeneous users' transactional demand rather than by discounting cash flows. Introducing a token lowers users' transaction costs, and platform adoption follows an S-curve — slow initial growth, volatile expansion, then stabilization — driven by network effects. The model also identifies an intertemporal feedback between user adoption and token price that accelerates adoption and dampens user-base volatility relative to a tokenless platform.

[Catalini and Gans](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3137213) analyse why ventures sell tokens to [raise funds](/wiki/markets/raising-funds) at all. In their model of ICOs, an entrepreneur issues tokens and commits to accept only those tokens as payment for future platform use, so competition among buyers reveals consumer value without the entrepreneur needing to know willingness to pay in advance — a demand-revelation property that, in the paper's analysis, may raise entrepreneurial returns beyond what traditional equity financing achieves. Initial funds raised are maximized when token supply growth is set to zero, which encourages early participants to save their tokens; conversely, a lack of commitment in the token's "monetary policy" undermines saving, and the cost of token financing is potential inflexibility in future capital raising. The paper also documents the scale of the phenomenon as of 2018: over $7 billion raised through ICOs since 2017, against roughly $1 billion of venture capital into the sector, with Tezos ($232M) and Filecoin ($205M) among the largest offerings.

A companion model by the same authors extends the analysis to [token supply policy](https://www.sciencedirect.com/science/article/abs/pii/S0304405X21004414). When tokens both serve as a means of payment and finance investment in platform productivity, the optimal policy issues tokens when productivity-normalized supply is low and burns them when it is high. The platform's financial constraint creates an endogenous cost of issuing tokens, which leads to underinvestment through a conflict of interest between platform insiders and token-holding outsiders; blockchain-based commitment to token policy mitigates this time-inconsistency problem and thereby supports the token's value.

## Empirical evidence from Bitcoin

[Athey, Parashkevov, Sarukkai, and Xia](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2826674) built one of the earliest models linking a cryptocurrency's exchange rate to fundamentals: bitcoin's value is determined by transactional usage and beliefs about future adoption, with expectations about adoption feeding into present valuation through a speculative channel. Transaction volume correlates with, but does not solely determine, value — investor and speculator behaviour adds pricing pressure beyond transaction-based fundamentals. Their analysis of blockchain data through mid-2015 found that active transactional usage was not growing quickly and that investors and infrequent users held the majority of bitcoins; the study is frequently cited as early evidence that speculative holding, rather than payments usage, dominated bitcoin demand.

Speculation can do more than add noise. In a [Bank of England model by Zimmerman](https://www.bankofengland.co.uk/working-paper/2020/blockchain-structure-and-cryptocurrency-prices), a cryptocurrency's price is determined by the extent of its usage as money, but the blockchain's limited settlement capacity forces users to compete for settlement space. Speculative activity can crowd out monetary usage, undermining the currency's function as a medium of payment and lowering its value — so, contrary to standard economic models in which more demand raises price, higher speculative demand can reduce prices. The mechanism also raises the riskiness of investing in cryptocurrency, offering one explanation for the high observed volatility of crypto assets.

## Governance tokens and cash-flow analogs

_See also: [fee switches and value accrual](/wiki/economics/fee-switches-and-value-accrual) — how the cash flow a governance token is valued on gets switched on in the first place, and what the DAO then does with it._

Tokens whose protocols route value to holders invite more conventional analysis. An influential practitioner example is [Kang's 2019 valuation of MKR](https://medium.com/@Rewkang/maker-mkr-valuation-fundamentals-the-case-for-trillion-dollar-maker-9b6e3f0150f1), the governance token of MakerDAO (now [Sky](/wiki/daos/stablecoins/sky-dao)), written when the project traded near a $1 billion market capitalization. Kang argued that MakerDAO had achieved genuine product-market fit, distinguishing it from most crypto projects, yet observed widespread confusion about MKR's long-term worth despite the token being integral to the system's functioning. His method proceeds by "searching for an analog" in traditional finance: tokens with burn models are compared to equity structures in which value flows directly to holders through buyback-like accrual, tying MKR's value to the growth of the DAI stablecoin system. As a blog post by an author who disclosed holding MKR, it illustrates the genre of fundamental token analysis rather than peer-reviewed findings.

## How automated market makers set marginal prices

Whatever a token is worth in theory, its quoted on-chain price is usually set by an algorithm. The foundational design is the constant-product market maker described by [Buterin in 2018](https://ethresear.ch/t/improving-front-running-resistance-of-x-y-k-market-makers/1281) and later implemented by Uniswap: a contract holds reserves of two tokens and prices every trade so that the product of the reserves stays constant. Pricing is path-based along this invariant curve, so larger orders move the reserve point further and face progressively worse marginal prices — natural slippage — while a small trading fee (such as 0.3%) makes providing liquidity profitable and the invariant prevents the mechanism from being drained. The same post identified the front-running vulnerability in which miners trade ahead of and behind a user's order to extract profit from its price impact, an early statement of what became known as [MEV](/wiki/economics/mev-and-value-extraction). The consequence for valuation is that such curves translate net demand into price deterministically: the market's position on the curve, not any market maker's judgement, fixes the marginal price at every moment.

## Relevance to Caper

Caper tokens are priced continuously by a [bonding curve](/wiki/markets/bonding-curve), a deterministic pricing function in the same family as the automated market makers above: every purchase or sale moves the marginal price along the curve, so a token's price at any moment reflects the cumulative balance of buying and selling since launch. The research surveyed here therefore applies directly. If demand for a caper's token derives from expected usage of, and participation in, the venture behind it, then models in which token price aggregates transactional demand and expectations of future adoption describe the forces that move the token along its curve when [trading](/wiki/markets/trading) occurs — while the empirical literature cautions that speculative demand can push prices in ways usage-based fundamentals alone do not predict.

## References

1. Lin William Cong, Ye Li, and Neng Wang (2021). [Tokenomics: Dynamic Adoption and Valuation](https://academic.oup.com/rfs/article-abstract/34/3/1105/5891182). The Review of Financial Studies 34(3): 1105–1155.
2. Christian Catalini and Joshua S. Gans (2018). [Initial Coin Offerings and the Value of Crypto Tokens](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3137213). MIT Sloan School Working Paper 5347-18 / NBER Working Paper 24418.
3. Lin William Cong, Ye Li, and Neng Wang (2022). [Token-Based Platform Finance](https://www.sciencedirect.com/science/article/abs/pii/S0304405X21004414). Journal of Financial Economics 144(3): 972–991.
4. Susan Athey, Ivo Parashkevov, Vishnu Sarukkai, and Jing Xia (2016). [Bitcoin Pricing, Adoption, and Usage: Theory and Evidence](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2826674). Stanford University Graduate School of Business Research Paper No. 16-42.
5. Peter Zimmerman (2020). [Blockchain structure and cryptocurrency prices](https://www.bankofengland.co.uk/working-paper/2020/blockchain-structure-and-cryptocurrency-prices). Bank of England Staff Working Paper No. 855.
6. Andrew Kang (2019). [Maker (MKR) Valuation Fundamentals — The Case for Trillion Dollar Maker](https://medium.com/@Rewkang/maker-mkr-valuation-fundamentals-the-case-for-trillion-dollar-maker-9b6e3f0150f1). Medium.
7. Vitalik Buterin (2018). [Improving front running resistance of x*y=k market makers](https://ethresear.ch/t/improving-front-running-resistance-of-x-y-k-market-makers/1281). Ethereum Research forum (ethresear.ch).

## Token velocity

URL: https://caper.network/wiki/economics/token-velocity
Updated: 2026-07-22

| Concept | Token velocity — how often a token changes hands per period, and its effect on token value |
| --- | --- |
| Identity | The equation of exchange, [MV = PQ](https://en.wikipedia.org/wiki/Equation_of_exchange) — money supply × velocity = price level × real transaction volume |
| Applied to tokens by | [Kyle Samani (Multicoin, 2017)](https://multicoin.capital/2017/12/08/understanding-token-velocity/), [Vitalik Buterin (2017)](https://vitalik.eth.limo/general/2017/10/17/moe.html), [Chris Burniske (2017)](https://medium.com/@cburniske/cryptoasset-valuations-ac83479ffca7) |
| Core claim | All else equal, higher velocity implies lower per-token value; a token that is only spent, never held, accrues little value |
| The fix | "Velocity sinks" — reasons to hold rather than immediately sell (staking, governance, fee capture, redemption rights) |
| Related | [Token valuation](/wiki/economics/token-valuation) · [Curation markets](/wiki/economics/curation-markets) · [Personal tokens](/wiki/economics/personal-tokens) |

**Token velocity** is the rate at which a token turns over — the number of times an average unit is transacted within a period. It is one of the most load-bearing and most misunderstood variables in token design, because under the classical [equation of exchange](https://en.wikipedia.org/wiki/Equation_of_exchange) velocity sits in the denominator of a token's implied value: for a fixed volume of economic activity, the faster a token circulates, the fewer tokens the network needs to hold at any instant, and the lower the value each token must carry.

The concept was imported into crypto-economics in 2017 by [Kyle Samani](https://multicoin.capital/2017/12/08/understanding-token-velocity/), [Vitalik Buterin](https://vitalik.eth.limo/general/2017/10/17/moe.html), and [Chris Burniske](https://medium.com/@cburniske/cryptoasset-valuations-ac83479ffca7), and it reframed a common failure mode: many "utility tokens" designed purely as a medium of exchange were structurally unable to hold value, no matter how much the underlying network was used.

## The equation of exchange

The starting point is Irving Fisher's [equation of exchange](https://en.wikipedia.org/wiki/Equation_of_exchange), _MV = PQ_: the money supply _M_ times its velocity _V_ equals the price level _P_ times the real quantity of transactions _Q_. Rearranged, the aggregate value a monetary asset must support is _M = PQ / V_.

Treat a token as the money of its own micro-economy and the same identity applies. _PQ_ is the annual value of economic activity the token settles; _V_ is how many times each token is used to do so; and _M_ — the market value the network can sustain — is that activity divided by velocity. Two networks settling the same volume of real activity can be worth wildly different amounts purely because tokens in one sit still and tokens in the other are dumped the instant they are received.

## The velocity problem

The problem, as [Samani](https://multicoin.capital/2017/12/08/understanding-token-velocity/) framed it, is that a token used only as a medium of exchange has no reason to be held. A user acquires it to pay for a service and the recipient sells it immediately for a currency they would rather keep. Velocity spikes toward infinity, and by _M = PQ / V_ the sustainable market value collapses toward zero — even if the network itself is thriving. Usage and token value decouple.

[Buterin](https://vitalik.eth.limo/general/2017/10/17/moe.html) made the same point sharply: a token whose only role is to be spent, with no friction against instant re-sale, converges on a value determined by the brief window it must be held to transact — often seconds. This is why "the network is used a lot, therefore the token will be worth a lot" is a non-sequitur. High turnover is not a sign of health for a token's price; it is the opposite.

## Velocity sinks: giving people a reason to hold

The design response is to build **velocity sinks** — mechanisms that give holders a reason to hold the token rather than pass it straight on, lowering effective velocity and letting value accrue. The recurring families of sink are:

- **Staking and security bonds** — locking tokens to earn yield or to be eligible to provide a service removes supply from circulation.
- **Governance rights** — where influence accrues to, or is weighted by, tokens held over time, holding is itself the way to use the token (see [curation markets](/wiki/economics/curation-markets), where staked tokens signal and curate).
- **Cash-flow or fee capture** — a claim on protocol revenue turns the token into a productive asset worth holding rather than flipping ([token valuation](/wiki/economics/token-valuation) treats this cash-flow analog directly).
- **Redemption / burn-and-mint** — a right to redeem the token for something of value at a floor gives holders a reason not to sell below it.

Each sink is a deliberate source of holding demand. Good token design is, in large part, the art of building credible sinks without simply taxing users.

## Criticisms and nuance

Velocity is a useful lens, not a law. Several caveats matter. First, velocity is endogenous: it is an _outcome_ of a token's design and its holders' expectations, not an independent input you can set — a strong sink and a credible growth story both depress it. Second, the naive _M = PQ / V_ model treats a token purely as a spending medium and ignores its role as a speculative store of value, which is where much crypto demand actually sits; [Burniske's](https://medium.com/@cburniske/cryptoasset-valuations-ac83479ffca7) discounted-utility models try to bridge that by discounting future utility value into the present. Third, measured on-chain velocity is noisy — exchange wallets, wrapping, and internal transfers inflate turnover that is not real economic circulation.

The durable takeaway is narrower than "low velocity is always good": a token needs at least one credible reason to be held that scales with the network's success. Without it, adoption and value stay decoupled.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) does not ask its token to be a medium of exchange. Its tokens carry two reasons to hold that both work as velocity sinks. Accumulated **governance weight** is a function of tokens held over time, so influence is something you build by holding, not by transacting (see [voting mechanisms](/wiki/governance/voting-mechanisms)). And the **exit right** gives every holder a redeemable claim on the treasury proportional to that same accumulated weight — a floor of real value that rewards holding rather than flipping.

The [bonding curve](/wiki/markets/bonding-curve) reinforces this: buying and selling settle against a reserve rather than a thin order book, so the token's design centres on a stake you hold and can later redeem, not a chip you pass along. The point is not that Caper "solves" velocity — it is that a caper's value proposition is a held position (governance plus an exit claim), which is structurally the kind of sink the velocity literature says a token needs. This is the same logic that makes [personal tokens](/wiki/economics/personal-tokens) coherent rather than a pure medium of exchange.

## References

- [Kyle Samani, “Understanding Token Velocity,” Multicoin Capital (2017)](https://multicoin.capital/2017/12/08/understanding-token-velocity/)
- [Vitalik Buterin, “On Medium-of-Exchange Token Valuations” (2017)](https://vitalik.eth.limo/general/2017/10/17/moe.html)
- [Chris Burniske, “Cryptoasset Valuations” (2017)](https://medium.com/@cburniske/cryptoasset-valuations-ac83479ffca7)
- [Equation of exchange (MV = PQ) — the classical Fisher identity](https://en.wikipedia.org/wiki/Equation_of_exchange)

## Transaction costs and property rights

URL: https://caper.network/wiki/economics/transaction-costs
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Topic** | Institutional economics — transaction costs, property rights, and governance |
| **Key figures** | Coase, Dahlman, North, Williamson, Alchian, Demsetz |
| **Core claim** | With positive transaction costs, institutions and the assignment of property rights determine economic performance |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) · [Execution](/wiki/governance/execution) · [Harberger taxes](/wiki/economics/harberger-taxes) |

Transaction costs are the resources consumed in making an exchange happen: finding a counterparty, agreeing on terms, and ensuring that the agreement is kept. Property rights are the socially recognized entitlements to use resources and to exclude others from using them.

The two concepts anchor the new institutional economics. If transacting were costless, bargaining would resolve every conflict over resource use and the organization of economic activity would not matter. Because transacting is never costless, the rules that define, measure, and enforce rights become a central determinant of economic performance — an insight that recent arguments extend to blockchains.

## The economics of transaction costs

### Dahlman's taxonomy

Building on Ronald Coase's treatment of social cost, Carl Dahlman argued that externalities persist only because transacting is costly: if exchange were costless, potential Pareto improvements would be realized by bargaining among self-interested agents — in the theory of externalities, ["transaction costs are the root of all evil."](https://cafehayek.com/wp-content/uploads/2011/11/Carl-Dahlman.pdf) His article supplies the canonical trichotomy, organized by phase of exchange:

| Phase of exchange | Cost class |
| --- | --- |
| Locating a trading opportunity | Search and information costs |
| Reaching agreement | Bargaining and decision costs |
| Ensuring performance | Policing and enforcement costs |

Dahlman then argued that the three classes reduce to one — resource losses due to imperfect information — since each exists only because agents lack knowledge of trading opportunities, of counterparties' willingness to trade, or of whether performance will occur. On this view transaction costs are analytically like transport costs: if bargaining an externality away costs more than it gains, the observed outcome is already a constrained optimum, and market failure cannot be demonstrated by conceptual analysis alone.

### North: institutions and economic performance

Douglass North defined institutions as ["the rules of the game"](https://khosachonline.ucoz.com/_ld/1/144_chi_ph_gd-th_ch.pdf) — humanly devised constraints that structure incentives in political, social, and economic exchange; together with the technology employed, they determine the costs of transacting and producing, and hence economic performance. North cited measurements putting the transaction sector of the American economy at 45 percent of GNP in 1970. Four variables govern the cost of transacting: the cost of measuring the valuable attributes of goods and of agent performance; the size of the market, meaning personal versus impersonal exchange; enforcement, where the difficulty of creating a relatively impartial judicial system has been a critical stumbling block in economic development; and ideology, which matters precisely because measurement and enforcement are costly. North also distinguished institutions (rules) from organizations (players), which invest in whatever skills the institutional incentive matrix rewards — if the highest payoffs are to piracy, organizations become better pirates.

### Williamson: governance of contractual relations

Oliver Williamson described the new institutional economics as ["preoccupied with the origins, incidence, and ramifications of transaction costs"](https://chicagounbound.uchicago.edu/jle/vol22/iss2/3/): were those costs negligible, the organization of economic activity would be irrelevant, since any advantage of one mode would be eliminated by costless contracting. He characterized transactions along three dimensions — uncertainty, frequency, and the degree of durable transaction-specific investment — with opportunism, "self-interest seeking with guile," central to the problem. A governance structure is the institutional framework within which the integrity of a transaction is decided, and structures should be matched to transactions in a discriminating way: market governance for non-specific transactions, trilateral governance with third-party arbitration for occasional idiosyncratic ones, and bilateral relational contracting or unified governance (vertical integration) for recurring idiosyncratic ones.

## The property-rights paradigm

Armen Alchian and Harold Demsetz recast ownership itself: what is owned are not resources but [socially recognized rights to use resources](https://www.cambridge.org/core/journals/journal-of-economic-history/article/abs/property-right-paradigm/40FCB24EADBCF3C38FC3429E6C6F96B2) — a partitionable, always circumscribed bundle, with the strength of ownership given by the probability that the owner's decision about a use actually determines that use. Communal rights that lack the power to exclude invite free riding and overuse — depleted game stocks, polluted waterways, congested freeways — because users ignore the full costs of their actions. When transacting is costless, the identity of private owners does not alter how resources are used; with positive transaction costs, reassigning ownership has allocative effects, and the most important consequence of institutional rearrangements such as the enclosure movement may have been their impact on the cost of transacting itself. Rights structures also evolve endogenously: when technology or demand makes a communally held resource more valuable, societies tend to convert it toward exclusive, transferable private rights. The view of ownership as an adjustable bundle underpins later allocation mechanisms such as [Harberger taxes](/wiki/economics/harberger-taxes).

### Refinements: bargaining power and information gathering

The formal property-rights (incomplete-contracting) approach of Grossman, Hart, and Moore has been refined in ways that reconnect it to transaction costs. Patrick Schmitz showed that replacing the standard 50:50 division of surplus with [generalized Nash bargaining](https://doi.org/10.1016/j.econlet.2013.01.011) leaves the suboptimality of joint ownership intact for any distribution of ex-post bargaining power, but overturns another staple result: it can be optimal to assign ownership to the party whose investment is less productive when that party's bargaining power is relatively small, so a strong bargaining position can compensate for weak bargaining power. Schmitz also allowed a party to invest in gathering private information about its default options before deciding whether to collaborate; negotiations under the resulting information asymmetry produce [inefficient rent seeking](https://www.aeaweb.org/articles?id=10.1257/000282806776157722) — a genuine transaction cost arising inside the property-rights framework — which can make it optimal for the non-investing party to own the asset.

## Blockchains and the crypto-Coase argument

Prateek Goorha analyses blockchains through mechanism design: an effectively instantiated blockchain defines, largely inviolably, an allowable action space for participants and a mapping from actions to outcomes — [a class of implementable mechanisms](https://jbba.scholasticahq.com/article/4838-blockchains-as-implementable-mechanisms-crypto-ricardian-rent-and-a-crypto-coase-theorem). He cautions against the "super-ledger" reading: blockchains do not inherently make truth more likely, they are not universally public, and they are not synonymous with immutability, which depends on the verification protocol. Instead, they constitute an incipient third form of economic organization between markets and planning — a "cryptographic stigmergy" in which self-organization replaces some of the need for top-down planning and for discovering market prices. His crypto-Coase theorem states that in an environment of high frictional costs imposed by market orderings on one side and by planning on the other, economic activity moves toward this third form, where contextual information and identity are most closely matched in a verifiable manner. Identity, comprising a right to use and a right to exclude, is "possibly the quintessential property right," and the right to exclude is a key strength of the blockchain. He adds a practical caveat: with pervasive transaction costs, the initial distribution of assets will almost always matter.

_See also: [microfinance and micropayments](/wiki/economics/microfinance), where the transaction-cost floor is the binding constraint — a payment too small to justify its own settlement and verification cost simply does not happen, whatever the parties would prefer._

## Relevance to Caper

Transaction-cost economics explains where [DAOs](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) fit: a DAO is, in Williamson's sense, a governance structure, viable wherever on-chain coordination beats firm hierarchies and spot markets on the costs of transacting. On Caper, fundraising through perpetual bonding-curve markets substitutes posted algorithmic prices for bilaterally negotiated terms, compressing search and bargaining costs, while token-holder governance with automatic on-chain [execution](/wiki/governance/execution) shifts enforcement from a judicial problem to a computational one — an approved proposal acts on the treasury directly rather than relying on a counterparty's future performance. The underlying Radix platform pushes in the same direction by [treating tokens and permissions as platform-native primitives and making transactions human-readable before signing](https://www.radixdlt.com/), reducing the measurement and verification costs that North placed at the heart of exchange.

## References

1. Carl J. Dahlman (1979). [The Problem of Externality](https://cafehayek.com/wp-content/uploads/2011/11/Carl-Dahlman.pdf). Journal of Law and Economics, Vol. 22, No. 1, pp. 141–162.
2. Douglass C. North (1992). [Transaction Costs, Institutions, and Economic Performance](https://khosachonline.ucoz.com/_ld/1/144_chi_ph_gd-th_ch.pdf). ICEG Occasional Papers No. 30, ICS Press.
3. Oliver E. Williamson (1979). [Transaction-Cost Economics: The Governance of Contractual Relations](https://chicagounbound.uchicago.edu/jle/vol22/iss2/3/). Journal of Law and Economics, Vol. 22, No. 2, pp. 233–261.
4. Armen A. Alchian and Harold Demsetz (1973). [The Property Right Paradigm](https://www.cambridge.org/core/journals/journal-of-economic-history/article/abs/property-right-paradigm/40FCB24EADBCF3C38FC3429E6C6F96B2). The Journal of Economic History, Vol. 33, No. 1, pp. 16–27.
5. Patrick W. Schmitz (2013). [Bargaining position, bargaining power, and the property rights approach](https://doi.org/10.1016/j.econlet.2013.01.011). Economics Letters, Vol. 119, No. 1, pp. 28–31.
6. Patrick W. Schmitz (2006). [Information Gathering, Transaction Costs, and the Property Rights Approach](https://www.aeaweb.org/articles?id=10.1257/000282806776157722). American Economic Review, Vol. 96, No. 1, pp. 422–434.
7. Prateek Goorha (2018). [Blockchains as Implementable Mechanisms: Crypto-Ricardian Rent and a Crypto-Coase Theorem](https://jbba.scholasticahq.com/article/4838-blockchains-as-implementable-mechanisms-crypto-ricardian-rent-and-a-crypto-coase-theorem). The Journal of the British Blockchain Association, Vol. 1, Issue 2.

## Virtual economies

URL: https://caper.network/wiki/economics/virtual-economies
Updated: 2026-08-08

|  |  |
| --- | --- |
| **Topic** | Economic measurement and governance of online game worlds and their currencies |
| **Key figures** | Edward Castronova, Hiroshi Yamaguchi, Vili Lehdonvirta, Eyjólfur Guðmundsson |
| **Core finding** | Digitally scarce assets command real market value, and the operator that issues them sets their monetary policy alone |
| **Related** | [Token valuation](/wiki/economics/token-valuation) · [Token velocity](/wiki/economics/token-velocity) · [Bonding curve](/wiki/markets/bonding-curve) · [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) |

A **virtual economy** is the system of production, trade, and asset ownership that emerges inside a persistent online world, such as a massively multiplayer game. Although its goods exist only as entries in an operator's database, a virtual economy exhibits prices, wages, inflation, wealth inequality, and cross-border trade with real-world economies. Beginning in the early 2000s, economists demonstrated that these economies could be measured and analysed with the standard tools of the discipline — and, in doing so, established that digitally scarce assets command genuine, dollar-denominated value.

This research programme, which came to be called _virtual economics_, is a direct intellectual ancestor of token economies. The practice of pricing a world's internal currency against the dollar and estimating its aggregate output prefigures the way blockchain communities are valued today through network-level measures such as gross network value.

The founding studies were written between 2001 and 2005, when the field's open question was whether virtual economies could be measured at all. That question was settled. What the two decades since have supplied is a record of the other half of the problem the same researchers identified: who sets a virtual economy's policy, and what recourse its participants have when that policy changes.

## Measuring Norrath

The founding empirical study of the field is Edward Castronova's 2001 analysis of Norrath, the world of the game _EverQuest_. Drawing on 616 currency auctions, 651 avatar auctions, and a survey of 3,619 players, it was the [first systematic economic measurement of a virtual world](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=294828) — one with roughly 12,000 self-described "permanent residents" and about 60,000 people present at any given moment.

The results were striking. Castronova estimated Norrath's gross national product at about $135 million, or $2,266 per capita — enough to rank it the 77th richest "country" of 171 in World Bank tables, roughly on par with Russia and richer than China or India. The in-game currency, the platinum piece, traded on eBay-style markets at about $0.01072, nominally above the Japanese yen and the Italian lira; the average avatar produced 319 platinum pieces per hour, an hourly wage of roughly $3.42. Avatar accounts sold for $500 to $1,000, and hedonic pricing put a shadow price of about $13 on each character level, allowing real value creation per hour of play to be expressed in dollars.

The study also documented recognisably macroeconomic dynamics. Castronova framed real-money trade as foreign trade akin to tourism exports — earthlings spending dollars on goods that never leave Norrath — with a single trading site implying gross exports above $5 million a year, an economy that operated entirely underground because the game's publisher claimed all in-world items as its intellectual property. A 29-item price index fell 29 percent over three quarters, deflation that players experienced as the world's challenge, and entertainment value, declining. Wealth was highly unequal, yet residents judged the system fair by a norm of equality of opportunity rather than of outcomes.

## Virtual currencies as real currencies

Building on this work, Hiroshi Yamaguchi's 2004 analysis argued that game currencies with observable real-money exchange rates — "meaningful" currencies such as _EverQuest_'s platinum piece, as opposed to closed play-money like the Monopoly dollar — [fulfil all three textbook functions of money](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=544422): medium of exchange, measure of value, and store of value. Limited geographic validity and lack of intrinsic value do not disqualify them, since the same is true of national fiat currencies; in Yamaguchi's formulation, virtual currencies _are_ currencies.

Yamaguchi showed that the incentive for real-money trading is built into game design itself: because in-game skill accumulates with time rather than talent, time-poor but cash-rich players rationally buy items from time-rich but cash-poor players, each side exploiting a comparative advantage. The virtual/real exchange rate is set by players' opportunity costs, and because players themselves continually issue new currency, virtual money is "destined to depreciate" as total avatar wealth grows. With no central bank controlling the money supply and no interest rates to reward saving, virtual currency values are far more volatile than those of major earth currencies. Yamaguchi classified them as Local Exchange Trading Systems (LETS) freed from geographic boundaries — an early sign, he argued, of a "global LETS" that could become a numeraire for value on the internet — and noted that online worlds offer economists a quasi-controlled laboratory.

## The economics of designed scarcity

In a companion theoretical paper, Castronova identified what he called the "puzzle of puzzles": players [pay to be constrained](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=338500), because achievement requires scarcity and challenge — inverting the usual economic logic that constraints are bads. Under the subjective theory of value, virtual assets are as economically real as tangible goods: farmed items command genuine prices, so their value is legitimate subject matter for economics. The paper modelled how people allocate time between worlds, documenting "immigrants" who spent more hours per week in the virtual world than in paid employment, and warned that large-scale migration into virtual economies challenges GDP measurement and erodes real-world tax bases. It also observed that game operators are profit-constrained "dictators" who can unilaterally change economic policy and destroy asset values, creating legitimacy tensions as players self-identify as citizens rather than customers — a governance problem that structures such as [decentralized autonomous organizations](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) would later attempt to address.

Vili Lehdonvirta's 2005 synthesis [named the emerging field "virtual economics"](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1630302) and argued that virtual worlds should be studied as economies in their own right, not merely as simulations of the real one. Because the marginal cost of producing most virtual assets is zero, scarcity is a design choice, and demand curves take unusual shapes: virtual goods largely behave as Veblen goods, valued for exclusivity and status. This explains "mudflation" — in Norrath, items were produced faster than they were destroyed, so what would count as growth in a real economy destroyed value instead. Lehdonvirta found that microeconomic concepts such as markets, comparative advantage, and subjective value transfer well to game worlds, while macroeconomic models such as the national income identity break down and need world-native replacements. By 2005, digital scarcity had already become a business model: the Finnish operator Sulake derived most of its roughly EUR 15 million in revenues from selling virtual furniture in Habbo Hotel.

## Two decades of operator policy

Castronova treated the operator's position as the field's unresolved governance problem rather than an incidental detail. The published record since supplies four documented instances of that power being exercised, in four different directions, by four different operators. What they share is not the direction but the procedure: each was an announcement.

### Publish: CCP Games and EVE Online

On 27 June 2007 CCP Games [appointed Dr Eyjólfur Guðmundsson as EVE Online's in-world lead economist](https://community.eveonline.com/news/news-channels/press-releases/eve-online-appoints-in-world-economist-1/), recruiting him from the deanship of the Faculty of Business and Science at the University of Akureyri. CCP described the role as the first time an MMOG "has commissioned a dedicated real world economist to operate at this level of economic monitoring and research for a virtual world", and the stated rationale was disclosure rather than intervention: "by ensuring everyone has access to the same data, we will enhance the player experience and facilitate economic stability in EVE". The promise was quarterly reporting on inflation, growth and price trends. Nineteen years on, the series is still running and has moved to a monthly cadence: the [report covering July 2026](https://www.eveonline.com/news/view/monthly-economic-report-july-2026) was published on 7 August 2026 and covers mining, production, destruction, regional activity, price indices and money supply, with the underlying figures released as a downloadable data archive rather than only as charts. It is the longest continuous public statistical series any virtual economy has produced, and it exists because one operator decided that it should.

### Regulate: Linden Lab and Second Life

Second Life developed a lending sector paying interest on Linden dollar deposits, and it failed. Linden Lab's standing [policy on in-world "banks"](https://wiki.secondlife.com/wiki/Linden_Lab_Official:Policy_regarding_inworld_banks) records the reasoning in its own words: "Before this policy was enacted, several of these 'banks' defaulted on their obligations", and "unsustainably high interest rates offered by many of these banks make it likely that others will default as well, which will have a negative effect on Second Life's virtual economy". The remedy was to prohibit "offering interest or any direct return on investment (whether in L$ or other currency) from any object, such as an ATM, located in Second Life, without proof of an applicable government registration statement or financial institution charter". The mechanism is the interesting part. Rather than construct a virtual banking regulator, the operator made access to the activity conditional on a real-world one, importing an external authority it did not have to build or defend.

### Abolish: Blizzard and Diablo III

Blizzard shipped Diablo III in 2012 with both a gold auction house and a real-money auction house built into the game, then removed both on [18 March 2014](https://news.blizzard.com/en-us/article/10974978/diablo-iii-auction-house-update). The announcement is unusually explicit about the reason, and the reason is not that the market malfunctioned. The houses had been designed to "provide a convenient and secure system for trades", but the conclusion reached was that the system "ultimately undermines Diablo's core game play: kill monsters to get cool loot". This is the clearest instance of the profit constraint binding against the economy rather than through it: a functioning market with real willing buyers and sellers was closed because it competed with the product it was embedded in.

### Re-denominate: Sky Mavis and Axie Infinity

The fourth case tests whether a public ledger changes the answer. Smooth Love Potion (SLP), the reward token of the [play-to-earn](/wiki/daos/social/yield-guild-games) game Axie Infinity, is an ERC-20: holders custody it themselves and can trade it without the operator's participation. Its supply was nonetheless uncapped, which is Lehdonvirta's mudflation with an on-chain balance sheet. On 11 January 2024 Sky Mavis [capped it at 44 billion](https://blog.axieinfinity.com/p/slpcap) and paired the cap with a buyback fund targeting 2 per cent annual deflation, noting that "in 2023 SLP overshot the 2% target and was actually 2.8% deflationary". Two details matter more than the number. The cap is not a contract constraint: "this cap will be enforced via social contract and via our in-game emission mechanisms". And the change was "authored by multiple team members at Sky Mavis", who also "oversee decisions around the buyback fund", with no token-holder vote at any stage. Self-custody moved the asset out of the operator's database. It did not move the monetary policy.

## Functioning as money, without owning it

Yamaguchi's conclusion that meaningful virtual currencies satisfy all three textbook functions of money is a claim about what they do. The issuer's contract makes the opposite claim about what they are, and both hold at once. Linden Lab's [Terms and Conditions](https://www.lindenlab.com/legal/second-life-terms-and-conditions), effective 2 May 2024, state that "Linden Dollars are not currency or any type of currency substitute or financial instrument, and are not redeemable for any sum of money from Linden Lab at any time". What a holder acquires is instead "a limited license granted to you by Linden Lab to access and use Content, applications, services, and various user-created features in Second Life", one that "may not be sublicensed, encumbered, conveyed or made subject to any right of survivorship or other disposition by operation of law or otherwise". Section 3.1 reserves the policy power in terms that need no interpretation: "Linden Lab has the right to manage, regulate, control, and/or modify the license rights underlying such Linden Dollars as it sees fit", and the licence may be revoked "at any time without notice, refund or compensation".

The gap between the economic description and the legal one has two halves, and they close separately. A bearer asset on a public ledger closes the custody half: a holder's balance stops being an entry the issuer can revise, and the exchange rate Yamaguchi measured stops depending on the issuer's forbearance. The SLP case shows that it closes nothing else. Setting the issuance schedule, the fee, the sink and the cap is a distinct power, and moving the asset on-chain leaves that power exactly where it was unless something is built to move it. That something is governance, which is why the problem the virtual-economy literature raised in 2002 resolves into a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) question rather than a cryptographic one.

## Relevance to Caper

Every caper is, in effect, a small open economy: a community that raises capital, produces work, and trades with the wider Radix economy, with its token serving as both internal currency and claim on the venture's future. Just as Castronova priced Norrath's platinum piece and computed its per-capita GNP, a caper's economy is measured through its token — the market price on its perpetual [bonding curve](/wiki/markets/bonding-curve) reflects the community's output and expectations, and aggregate metrics such as gross network value descend directly from the virtual-economy tradition of measuring digitally native economies (see [Token valuation](/wiki/economics/token-valuation)).

The two halves are worth separating in Caper's own terms. On custody, a caper's token is a Radix-native resource held in the holder's own account, and the redemption path is not a facility the issuer extends: `sell_token` is declared `PUBLIC` in the protocol's method-authorisation table, so selling back into the curve is a method any holder may call. The one exception is stated in the source rather than in a policy that could later be revised, the root $XRD caper being refused by name because its governance tokens are non-salable by construction.

On policy, the honest comparison is narrower than "no operator". A fee-setting method exists and is restricted to an admin role. What differs is where the limit sits: the collateralization peak that role may set is bounded inside the method itself to a maximum of 0.15, and the source states the reason, which is that the founder's ceiling of at most five per cent is derived from that peak, so leaving it unbounded "would be a setting an admin badge could raise, not a property of the curve". Set beside a supply cap "enforced via social contract", that is the substance of the difference. It is not the absence of an administrator but a bound the administrator's own transaction has to satisfy, with everything discretionary left to proposals and their on-chain [execution](/wiki/governance/execution).

## References

1. Edward Castronova (2001). [Virtual Worlds: A First-Hand Account of Market and Society on the Cyberian Frontier](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=294828). CESifo Working Paper No. 618; Gruter Institute Working Papers on Law, Economics, and Evolutionary Biology 2(1).
2. Edward Castronova (2002). [On Virtual Economies](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=338500). CESifo Working Paper No. 752; published in Game Studies 3(2), 2003.
3. Hiroshi Yamaguchi (2004). [An Analysis of Virtual Currencies in Online Games](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=544422). The Journal of Social Science (International Christian University), No. 53, pp. 57–76.
4. Vili Lehdonvirta (2005). [Virtual Economics: Applying Economics to the Study of Game Worlds](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1630302). Proceedings of the 2005 Conference on Future Play, Lansing, MI.
5. CCP Games (27 June 2007). [EVE Online Appoints In-World Economist](https://community.eveonline.com/news/news-channels/press-releases/eve-online-appoints-in-world-economist-1/). Press release.
6. CCP Games (7 August 2026). [Monthly Economic Report — July 2026](https://www.eveonline.com/news/view/monthly-economic-report-july-2026). EVE Online news.
7. Linden Lab. [Policy regarding inworld banks](https://wiki.secondlife.com/wiki/Linden_Lab_Official:Policy_regarding_inworld_banks). Second Life official policy.
8. Linden Lab (effective 2 May 2024). [Second Life Terms and Conditions](https://www.lindenlab.com/legal/second-life-terms-and-conditions), §3.1.
9. Blizzard Entertainment (2013). [Diablo III Auction House Update](https://news.blizzard.com/en-us/article/10974978/diablo-iii-auction-house-update). Blizzard News.
10. Sky Mavis (11 January 2024). [Updates To SLP's Monetary Policy!](https://blog.axieinfinity.com/p/slpcap). The Lunacian.

## Getting started

URL: https://caper.network/wiki/foundations/getting-started
Updated: 2026-08-10
Verified: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | Onboarding |
| **Requires** | Radix Wallet + Connector extension |
| **Auth** | ROLA — free, no transaction |
| **Cost to launch** | 10 XRD for a 6-character cashtag, ×10 for each character shorter |
| **Related** | [What is a caper](/wiki/foundations/what-is-a-caper), [Raising funds](/wiki/markets/raising-funds), [Trading](/wiki/markets/trading) |

Starting an organization on caper takes one transaction and one payment. You connect a Radix wallet, pick a name and a cashtag, and submit; the transaction mints the token, opens the treasury, starts the bonding curve, and hands you a founder badge. The only money that leaves your wallet is the registration fee, which is **10 XRD** for a six-character cashtag and rises tenfold for each character shorter. There is no allocation to configure, no treasury to pre-fund, and no application to be approved.

## How do I start a DAO on Caper?

Five steps, all of them in the browser:

1. **Install the Radix Wallet** and link it to your browser with the Radix Connector extension. Both are free; details below.
2. **Connect.** Tap Connect in the top navbar and sign the challenge. Signing in is off-ledger and costs nothing.
3. **Choose a cashtag.** One to six characters, uppercase letters or digits. This is the ticker your token trades under, and it fixes your registration fee.
4. **Fill in the name and description** on [Create a caper](/create-caper), then submit the transaction. You need the registration fee in XRD on the connected account before this step.
5. **You are live.** The token, treasury, and market exist from that block onward, and anyone can buy in against the curve straight away.

Nothing about the organization has to be decided up front. Members arrive by buying the token, spending is decided by proposal afterwards, and the rules that govern the treasury are the same contract rules for every caper.

## How much does it cost to start a caper?

One payment: a registration fee in XRD, priced by how short your cashtag is. Shorter tickers are scarcer, so they cost more.

|  |  |
| --- | --- |
| **Cashtag length** | **Registration fee** |
| 6 characters | 10 XRD |
| 5 characters | 100 XRD |
| 4 characters | 1,000 XRD |
| 3 characters | 10,000 XRD |
| 2 characters | 100,000 XRD |
| 1 character | 1,000,000 XRD |

The contract charges ten to the power of seven minus the length, and rejects the transaction if the payment is even slightly off. Cashtags must be uppercase letters A to Z or digits 0 to 9, and two are reserved by the protocol.

Beyond that fee you pay only the Radix network fee for the transaction itself. There is no listing charge, no monthly cost, no minimum treasury, and no revenue share on the way in.

**Where the fee goes.** Not to a company. Registration fees are banked in the treasury of the $CAPER caper — the first caper the protocol registered, and one whose own members hold tokens, vote, and can exit on the same terms as any other. The protocol funds itself through a caper rather than around one.

What it costs to _run_ a caper is separate and set per caper: raising a proposal and casting a vote both carry fees that go to your own treasury, and trades carry a flat 0.5% split between your treasury and the protocol's base caper. Those figures are configurable rather than constants; [Raising funds](/wiki/markets/raising-funds) carries the current schedule.

## What do I need before I can take part?

A Radix wallet, and nothing else. Tap **Connect** in the top navbar, choose an account, and sign the connection challenge — caper uses ROLA (Radix Off-Ledger Auth), so signing is free and produces a session, not a transaction.

Some surfaces are gated by an XRD balance check. Holding any XRD on the connected account unlocks them; you never send XRD to caper to authenticate.

The Radix Wallet is a free, self-custodial app. Install it on your phone, then — on desktop — link it to your browser with the Radix Connector extension so dApps like caper can talk to it. The official portal at [wallet.radixdlt.com](https://wallet.radixdlt.com/) links every download. Once installed and linked, come back and tap **Connect**.

## How do I join a caper without launching one?

Buy its token. Browse the live capers and buy in directly against the [bonding curve](/wiki/markets/bonding-curve) — no order book, no counterparty, instant settlement, and the price follows supply rather than a quoted spread. Holding the token is what membership is; there is no separate application or allowlist. How pricing and the fee legs work is in [Trading](/wiki/markets/trading).

## How does governance work once I hold a token?

Holding a caper's token makes you a voting member. You can raise a [proposal](/wiki/governance/proposals) or rank every option on someone else's. Proposals are settled by a [Borda count over complete rankings](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods), so partial or duplicated ballots are rejected outright.

A proposal that passes executes on-chain. The executive actions a caper can take are **Payout** (send treasury funds to a recipient), **Invest** (buy into another caper's curve), **Divest** (sell a held position back into that caper's curve), **Vote** (cast this caper's weight in another caper's governance) and **Upgrade** (swap the platform's shared logic, reserved to the $CAPER caper).

Each vote you cast mints a soulbound vote token, and your [voting weight](/wiki/governance/voting) is the product of your stake and that accumulated record — so a large balance that has never voted counts for very little, and a long record with no stake counts for nothing either.

## How do I leave and get my money back?

Two routes, both open at any time and neither needing anyone's permission. You can sell back to the curve at the price the curve quotes, or exit outright by handing back your tokens and your vote record together — the contract requires both — and take your share of the treasury. That share is your voting weight, the same product of stake and participation that decides your vote, so influence and exit rights can never drift apart.

The [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) is built into the contract rather than granted by a vote. No majority has to approve it and no grace-period window has to be open.

## The life of a caper

Every caper moves through the same four stages — launch, trade, govern, grow — and a holder can exit at any point along the way.

CAPER PROTOCOLThe life of a caper4 STAGESFROM ONE CLICK TO A LIVING ORGANIZATION1LAUNCHOne transaction mintsthe token, treasury,and bonding curve —and hands you afounder badge.2TRADEAnyone buys or sellson the curve. Pricefollows supply; thereserve backs everytoken.3GOVERNHolders proposeactions, rank-votewith skin in the game,and execute on-chain.4GROWThe treasurycompounds. Invest inother capers. $CAPERindexes them all.Exit any time – hand back tokens and vote record together; the treasury share is set by both.How a caper is born, traded, and governed.caper.networkLaunch → trade → govern → grow · exit any time.

## Where next

Start with [What is a caper](/wiki/foundations/what-is-a-caper) for the model in five minutes. If you're new to DAOs entirely, the knowledge base opens with [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) and the [history of how the industry got here](/wiki/dao-governance/concepts/fundamentals/history-of-daos). If you're reading this through an AI agent, [Querying a caper from an AI agent](/wiki/foundations/querying-a-caper-from-an-ai-agent) documents the read-only MCP servers. Questions? Try the [FAQ](/wiki/help/faq).

## Leaving a caper: the exit right

URL: https://caper.network/wiki/foundations/leaving-a-caper
Updated: 2026-08-11

| Mechanic | Exit right |
| --- | --- |
| Contract method | `exit` (`contracts/logic/src/lib.rs`) |
| Approval needed | None. No proposal, no vote, no council |
| You hand over | Vote tokens (burned) + governance tokens |
| You receive | Pro-rata treasury share + curve sell-back |
| Waiting period | None in the contract |

A caper is a group of people who raise a treasury together and govern it on-chain. The exit right is the part that decides what that membership is actually worth: at any point, a member can take their share of the treasury and go, without asking anyone. This page answers what leaving involves, in the order people ask it.

## Can I leave a caper?

Yes, at any time, and nobody can stop you. Leaving is a single method call on the caper's contract, named `exit`. It is not a proposal, so it is not voted on, not scheduled, and not subject to a council or a founder's approval. There is no motion to table and no quorum to reach.

The only thing the contract checks is that you hold the tokens you claim to hold. It asserts that your vote-token amount is greater than zero, that your governance-token amount is greater than zero, and that both are that specific caper's own resources rather than some other token. Your holdings are the credential. There is no membership list to be removed from.

## What do I get when I leave?

Two separate payouts, and it is worth keeping them apart because they come from different places.

1. **A pro-rata share of the treasury.** Your share of the XRD the caper holds, plus a matching share of any other resources in the treasury you name when you exit. Members whose caper has invested in other assets get those too, not only the XRD.
2. **The proceeds of selling your governance tokens back to the bonding curve.** The contract prices the sale against the curve and takes the caper's standard trade fee, the same fee any sale on that curve pays. The sale emits an ordinary sell event on the caper's trade feed.

Both legs settle in the same transaction. You do not exit and then separately go and find a buyer.

## How is my treasury share calculated?

By the same formula that decides how much your vote counts. Caper does not run one arithmetic for governance and a different one for money, which is the whole point of the design: the number that gives you influence is the number that gives you your share.

The contract computes:

`share = (tokens_redeemed × votes_burned) / (vote_supply × tokens_in_circulation)`

Read plainly: your share rises with how many governance tokens you redeem _and_ with how many vote tokens you burn, measured against the caper's total vote supply and its circulating token supply. Both terms are multiplicative. Holding more tokens increases your share; so does having accumulated more vote tokens. If either is zero the formula returns zero, and the contract rejects the exit before it gets that far.

The same function is used when you cast a vote. See [how voting works](/wiki/governance/voting) for the governance side of it.

## What happens to my vote tokens?

They are burned. The contract pays your treasury share first, then destroys the vote tokens you handed over, then runs the sell leg. Vote tokens are soulbound, so they were never transferable in the first place; burning them on exit is what stops a departing member's accumulated governance weight from outliving their stake in the caper.

This is also why the treasury share is computed before the burn rather than after. The weight you leave with is the weight you had.

## Is there a lock-up or a waiting period?

No. The contract's `exit` path contains no epoch check, no notice period and no vesting gate. There is nothing in it that defers your payout to a later block, and nothing another member can do to delay it.

This matters more than it sounds. A great many DAO exit provisions are real on paper and unreachable in practice, because the exit itself has to be approved by the people it inconveniences, or because it runs through a multisig that can simply not sign. An exit that somebody has to authorise is a request. See [how DAOs fail](/wiki/dao-governance/concepts/analysis/how-daos-fail) for the shapes that recur.

## What is different about the $XRD caper?

One caper is a special case. $XRD has no bonding curve, so it has no sell leg: exiting it pays the treasury share and returns your governance tokens to you untouched, rather than selling them. Everything else about the exit is identical.

The reason is that its members hold native XRD, whose total supply cannot be read on-ledger at all. Radix creates XRD without supply tracking, so the contract substitutes a fixed constant for the circulating-supply term. Erring high there only makes exits conservative, which keeps the sum of every member's share inside the treasury.

## How does this compare to a DAO rage quit?

The lineage is Moloch's rage quit, and the difference is what the right is attached to. A rage quit is usually scoped to a specific proposal and a specific window: you may leave because you object to something that just passed, during the grace period before it executes. Outside that window, there is nothing to exercise.

In a caper the exit is not attached to a proposal at all. It is a standing property of holding the tokens, available on any day, whether or not anything is being voted on and whether or not you object to it. There is no window to miss.

The essay [The Exit Right](/blog/the-exit-right) works through why that difference changes how the rest of the governance behaves.

## What if I want to reduce my stake without leaving?

Selling governance tokens on the curve is a separate operation from exiting, and it does not burn your vote tokens or touch your treasury claim. See [trading](/wiki/markets/trading). Exiting is the operation that settles everything at once and ends the membership.

## Related

- [What is a caper](/wiki/foundations/what-is-a-caper) — the object this right belongs to
- [Getting started](/wiki/foundations/getting-started) — joining, the cashtag fee ladder, and what a caper costs to start
- [Voting](/wiki/governance/voting) — the other half of the same weight formula
- [FAQ](/wiki/help/faq) — shorter answers, including divestment and upgrades

## Paying someone from a caper's treasury

URL: https://caper.network/wiki/foundations/paying-someone-from-a-caper
Updated: 2026-08-12

| Mechanic | PAYOUT proposal (option kind 0) |
| --- | --- |
| Contract method | `execute_proposal_payout` (`contracts/logic/src/lib.rs`) |
| Who can propose | Anyone holding at least 1 of that caper's governance tokens |
| Who can receive | Any Radix account — membership not required |
| What can be paid | Any resource the treasury holds, not only XRD |
| Ballot | Ranked, Borda-counted, 2 to 12 options |
| Bar to pass | 1.5 ÷ number of options, as a share of the weight cast |
| Who executes | Anyone. Settlement and execution are permissionless calls |

A caper raises a treasury on a bonding curve and governs it on-chain. Sooner or later somebody has to be paid out of it — a contributor, a supplier, a grantee, the founder. In Caper that is a **PAYOUT proposal**: a motion that names a recipient, a currency and an amount, is decided by a ranked vote, and then moves the money itself. No multisig signs it and no treasurer holds the keys. This page answers what that involves, in the order people ask it.

## How do I pay someone from a caper's treasury?

By passing a PAYOUT proposal. It is the first of the five things a proposal can do, and it is the only one that sends value to a person: the contract discriminates execution on an option's `kind` field, and kind 0 means `treasury.transfer(recipient, currency, amount)`.

What you cannot do is pay someone _without_ passing one. There is no admin withdrawal, no founder key over the treasury vault, and no "operations wallet" that sits outside governance. The treasury vault is only reachable through a badge the contract holds itself, and it releases funds along exactly four paths: an executed proposal, an executed investment or divestment, and a member exercising [the exit right](/wiki/foundations/leaving-a-caper). Everything else is a proposal or it does not happen.

## Who controls the treasury?

The token holders, collectively, through the ballot — and nobody individually. This is the question worth settling before any of the mechanics below, because it is where most DAO treasuries actually differ from what their documentation claims.

Can the treasury be drained by whoever set the caper up? No. The founder holds no key over the vault and no privileged withdrawal method exists for them to call. Their advantage is taken somewhere else entirely: a bounded slice of each purchase on the bonding curve, taken as the money comes in, and capped by a ceiling the contract derives rather than an administrator sets. It is not a claim on the treasury and it confers no authority over what the treasury spends afterwards. A founder who wants to move treasury money has to put it on the ballot like anyone else, and win the same vote.

## How do I propose a payment, and who is allowed to?

Any holder of the caper's governance token. The contract's check is deliberately low: it takes a proof of your holdings and asserts you have **at least one** token. There is no proposer threshold, no council seat, no whitelist and no founder veto over what reaches the ballot.

The cost is a flat proposal fee, paid in XRD at the moment of creation and banked by the caper rather than burned. It exists for a specific reason: the fee has to cover the gas budget of the settlement pass that the proposal will later force somebody to run, so that a proposal can never draw more out of the treasury in settlement costs than it put in. The contract asserts that floor whenever the fee is changed. The fee is a governance-settable lever, so this page does not quote a figure — read the live value from the caper itself.

## How do I get paid by a caper?

From the receiving end: somebody who holds the caper's token puts your account address and your amount on a ballot, the members vote, and if it clears the bar the money is sent to you. You do not have to join the caper, hold its token, or hold a wallet it recognises. What you should ask for is the proposal, not an invoice — the proposal is the thing that pays.

## Who can be paid, and in what?

**Any Radix account.** The recipient is stored as an account reference on the option, and nothing requires it to belong to a member, a token holder, or a wallet that has ever touched the caper. A caper can pay an outside contractor as easily as one of its own founders. In the interface this is the "Pay external address" path.

**Any resource the treasury holds.** The option carries a currency alongside the amount, so a caper that has invested its XRD into other capers' tokens can pay in those. The transfer floors to the currency's divisibility and the emitted event reports the amount that actually moved, so the receipt never overstates the payment.

## How does the vote decide it?

Every proposal is a **ranked ballot**, not a yes/no switch. You put between 2 and 12 options on it, voters rank them, and the contract scores them by Borda count: on a ballot of _m_ options, a voter's first choice receives _m−1_ times their vote weight, their second _m−2_, and so on down to zero for the last. Options are usually a real spend and a "no" option, but nothing stops you from putting three different amounts on the ballot and letting the members pick one.

The option with the most points wins if its share of the total weight cast clears **1.5 ÷ the number of options**. That bar moves with the shape of the ballot, and it is worth understanding before you write one:

- 2 options → the winner needs **75%** of the weight
- 3 options → **50%**
- 4 options → **37.5%**

So a straight spend-or-don't motion is the hardest thing to pass in a caper, and adding genuine alternatives lowers the bar rather than raising it. There is no separate turnout quorum: the threshold is a share of the weight actually cast, not of the weight that exists. A proposal whose leading option is the "no" option never passes, whatever its score.

Vote weight is the same figure that decides your treasury share on exit — see [how voting works](/wiki/governance/voting) for the formula. One detail matters here: at settlement each ballot's stake term is re-read and _clamped down_ to the smaller of what you held when you voted and what you hold now. Selling after you vote shrinks your own ballot. It cannot grow it.

## How long does it take?

Two windows, in order. First the voting window, which runs from creation to a fixed end date; then an execution delay, after which the proposal can be settled and, if it passed, executed. Both lengths are configured on the platform contract rather than fixed in the protocol, so this page does not quote them — read the dates off the proposal, which carries its own start, voting-end and execution-end timestamps.

Settlement is a distinct step from voting, and it is where the tally is frozen: the contract folds every ballot, records the option weights and the pass flag on-chain, and emits them. Large proposals can have their ballots folded in chunks beforehand, so no single transaction ever has to iterate an unbounded voter list.

## Who actually presses go?

Anyone. Both `settle_proposal` and `execute_proposal_payout` are open calls — no badge, no proof of membership, no privileged caller. If a payment wins its vote, any passer-by can make it happen, and the people it inconveniences cannot make it not happen by declining to sign.

That is safe because the caller controls nothing about the payment. The recipient, the currency and the amount were frozen into the option when the proposal was created, and execution binds the stored winning option: it reads the recipient out of chain state, not out of the transaction. The person who executes a payout cannot redirect it, cannot round it up, and cannot execute a losing option.

Execution is also once-only. The contract flips an executed flag before it moves anything, so a payout cannot be replayed for a second helping.

## What if the proposal fails?

Nothing moves. A settled proposal that did not clear its bar has no winner recorded, and every execution path aborts on that: there is no option to bind. The same is true when the "no" option is the one that wins — the contract refuses to execute a no-op.

The proposal fee stays with the caper either way. It paid for the settlement pass, which had to run regardless of the answer.

## What else can a proposal do?

Paying is one of five option kinds, all decided by the same ranked ballot and the same threshold:

- **PAYOUT** — transfer a treasury asset to an account.
- **INVEST** — withdraw treasury XRD and buy another caper's token with it, holding the result in the treasury. The XRD never touches the worktop, so nothing can be skimmed in transit.
- **DIVEST** — the reverse: sell a held token back into its own curve and bring the XRD home.
- **VOTE** — cast this caper's ranked ballot on another caper's proposal. Capers that hold each other's tokens can govern each other.
- **UPGRADE** — swap the platform's logic contract. Restricted to the $CAPER caper, because one upgrade changes the rules for every caper at once.

INVEST and DIVEST are why "what can a caper spend money on" has a second answer: a treasury can take a position in another caper rather than only spending down. Those funding edges are readable on each caper's ledger.

## Related

- [What is a caper](/wiki/foundations/what-is-a-caper) — the object this treasury belongs to
- [Getting started](/wiki/foundations/getting-started) — starting one, and what it costs
- [Leaving a caper](/wiki/foundations/leaving-a-caper) — the other way value leaves a treasury
- [Querying a caper from an AI agent](/wiki/foundations/querying-a-caper-from-an-ai-agent) — reading a caper's proposals and payouts programmatically
- [DAO contributor compensation](/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — how the wider industry pays people

## Querying a caper from an AI agent

URL: https://caper.network/wiki/foundations/querying-a-caper-from-an-ai-agent
Updated: 2026-08-12

| Agent access at a glance |  |
| --- | --- |
| Protocol | Model Context Protocol (MCP) over JSON-RPC 2.0 |
| Protocol version | `2025-03-26` |
| Knowledge base | `POST https://caper.network/api/mcp` |
| Any single DAO | `POST https://caper.network/wiki/caper//mcp` |
| Authentication | None |
| Cost | None |
| Writes | None — read-only, no transactions, no wallet |
| Plain-HTTP reads | Every page as `.md` or JSON at `/api/wiki/`; each DAO as `/wiki/caper//dao.json` |
| Licence | [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), declared in every page's front matter |
| Discovery files | [llms.txt](https://caper.network/llms.txt), [agent.json](https://caper.network/.well-known/agent.json), [openapi.json](https://caper.network/.well-known/openapi.json) |

## The short answer

Caper serves two read-only MCP servers. Point your agent at
`https://caper.network/api/mcp` for the knowledge base, or at
`https://caper.network/wiki/caper//mcp` for one DAO's own record. Both speak
JSON-RPC 2.0 over HTTP POST, both are unauthenticated and free, and neither can write anything. A DAO's
treasury balances, its proposal and trade timeline, its executed grants and its funding relationships with
other DAOs all come back from a single `get_ledger` call against the second endpoint.

That is the whole setup. The rest of this page is the detail: which tool answers which question, what
the servers deliberately will not do, and why a Caper DAO can answer questions most DAOs cannot.

## Why this is answerable at all

Asking most DAOs for a machine-readable account of their own governance means assembling it yourself:
balances from a block explorer, proposals from a Snapshot space, discussion from a Discourse forum, payouts
from a multisig, and the mapping between them from nowhere in particular. The record exists, but it is
spread across systems that were never designed to be read together, and the joins are done by hand.

A caper is issued, funded, governed and settled through one set of contracts, so the join already exists.
Every proposal, trade, treasury movement and execution is a settled transaction on the same ledger, and each
DAO's [company layer](/wiki/foundations/what-is-a-caper) sits directly on top of that record. Serving
it to an agent is therefore a matter of exposing what is already joined, not of reconciling four sources
and hoping they agree.

This is also why the ledger tool outranks the prose tools. Wiki pages on Caper are human-authored and can
be wrong, stale or absent; a young DAO has a ledger before it has any prose at all. `get_ledger`
is derived from settled transactions, so on any balance, amount, date or "did this actually happen", it is
the authority and the prose is commentary.

## The knowledge-base server

`POST https://caper.network/api/mcp` — the DAO-governance reference and Caper's own
documentation. Eight tools:

| Tool | Answers | Notes |
| --- | --- | --- |
| `get_categories` | What is in here? | Call this first when orienting. Returns the taxonomy with `pageCount` and `pageCountDeep`, so you can tell an empty heading from a populated branch before spending a call. |
| `search_wiki` | Where does X live? | Case-insensitive substring over titles and body text — _not_ fuzzy. Search one distinctive word, not a sentence. |
| `get_pages` | Read 1–20 pages | The one to use. Takes `paths` exactly as the listing tools return them; misses come back in `missing` rather than failing the call. |
| `get_page` | Read one known page | For a single page only. A wrong guess returns near-match slugs instead of an empty error. |
| `list_pages` | Walk a branch | `tagPath` matches the branch and everything beneath it: `daos` also returns `daos/dexs/…`. |
| `get_recent_changes` | What changed? | Last N days (default 7, max 30). |
| `get_full_corpus` | Bulk ingestion | Preflight with `sizeOnly: true` first — the corpus is large enough to swamp a context window. |
| `list_daos` | Which DAOs exist? | Resolves a name to a cashtag and hands back that DAO's own `mcpEndpoint`. This is the bridge to the second server. |

The knowledge-base server has no ledger tool, deliberately. Chain state is per-DAO, so it lives on the
per-DAO server that `list_daos` points you to.

## The per-DAO server

`POST https://caper.network/wiki/caper//mcp` — one DAO's company layer. It
carries the same five reading tools scoped to that DAO's own pages, plus the one that matters:

`get_ledger` returns four things in a single call — current treasury balances by resource,
the activity timeline (proposals, trades, executions) with an explorer link per event, executed grants and
payouts, and inter-DAO funding edges in both directions. It takes one optional argument, `limit`.

The funding edges are the part with no equivalent elsewhere. When one caper funds another, both sides of
the relationship are settled transactions on the same ledger, so the edge is a fact rather than an
inference — and it is directional, so you can read who funded whom.

## If your agent does not speak JSON-RPC

MCP is the richest way in, but it is not the only one. Everything the knowledge base holds is also served
over plain HTTP GET, which is what a crawler, a shell script or a retrieval pipeline actually wants.

| Endpoint | Returns |
| --- | --- |
| `GET /wiki/.md` | Any page as Markdown with YAML front matter — `title`, canonical `url`, `updated`, `last_verified` where the page carries one, and the licence. Append `.md` to the page URL you are already looking at. |
| `GET /api/wiki/` | The same page as JSON: the raw content blocks, `tagPath`, `updatedAt`, `lastVerifiedAt`, a `license` object, and `markdownUrl` pointing at the Markdown form. An unknown path returns a JSON error carrying the index URL rather than an HTML 404 page. |
| `GET /wiki/caper//dao.json` | One DAO as a [DAOstar / EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) description document — the DAO's name and description, its governance, members, proposals, activity-log and contracts fields, and the on-ledger addresses of its component, treasury, governance token, vote token and badges. |
| `GET /wiki/caper//llms.txt` | One DAO as plain text: its pages, its treasury balances, its timeline, its grants and its funding edges, in the same document. |
| `GET /llms.txt` · `/llms-full.txt` | The index of every page and DAO; and the entire corpus as one document — about 2.5 MB, so size it before you pull it. |
| `GET /.well-known/agent.json` | An agent card: the MCP endpoint, the API spec URL, the skills this site claims, and the `daoUriTemplate` that generates the `dao.json` URL for any cashtag. |
| `GET /.well-known/openapi.json` | An OpenAPI 3.1 document for the read endpoints. |

Two things follow from this that are easy to miss. The Markdown and JSON forms both declare a licence —
[CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — so an agent can tell what it is allowed to
do with the text without inferring it from a footer. And `agent.json` is the only one of these
files that points at the others, so it is the right first fetch when you are mapping the surface rather than
reading a specific page.

## A worked example

One call, no key, no wallet:

```
curl -s -X POST https://caper.network/wiki/caper/CAPER/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"get_ledger","arguments":{"limit":3}}}'
```

The response carries the treasury as a list of resources with exact amounts, then the timeline. A trade
event looks like this:

```
{
  "id": "trade-2222",
  "kind": "trade",
  "at": "2026-08-09T09:22:56.524Z",
  "title": "Sold $CAPER",
  "status": "SELL",
  "amount": "2.25B",
  "txUrl": "https://stokenet.radxplorer.com/transactions/txid_tdx_2_12084daw…",
  "timeAgo": "54m"
}
```

Every event carries its `txUrl`, so any figure an agent reports can be traced back to the
transaction that produced it. Amounts are returned as strings at full precision — treasury balances come
back like `"109791.549345417912335"` — because these are token quantities and rounding them in
transit would be a data loss, not a formatting choice.

Truncation is always reported rather than silent: the timeline returns `count` alongside
`truncated: true` when your `limit` cut the list, and the same holds for grants and
funding edges. An agent can tell "there were three" from "there were at least three".

## What these servers will not do

- **Write anything.** Both servers are read-only. There is no tool that creates a caper,
 submits a proposal, casts a vote, or moves a token. Governance actions require a signed transaction from
 a Radix wallet, and an agent cannot produce one here.
- **Authenticate.** There are no keys and no accounts, because everything served is already
 public on-chain or published on the wiki.
- **Answer from a GET.** The two _MCP_ endpoints are POST-only JSON-RPC; a browser or
 crawler that GETs them receives `405`. That is correct behaviour, and it is why this page
 exists — a POST-only endpoint cannot be indexed or cited, so the documentation has to be somewhere that
 can. The GET surface in the section above is the answer for anything that cannot post JSON-RPC.
- **Guess.** A malformed or unknown path returns near-matches and the tool's own usage note
 rather than an empty result, so a wrong first call is self-correcting instead of a dead end.

Each server also returns a usage guide in its `initialize` response, so an agent that connects
properly is told how to use it before it makes a call.

## Reading the record honestly

Two cautions worth carrying into any analysis built on this data.

The first is scope. Caper DAOs currently run on Radix Stokenet, the public test network. The mechanics,
the contracts and the record are real, but the capital is not, so treasury figures should be read as
demonstrations of the machinery rather than as measurements of economic activity. Explorer links resolve to
`stokenet.radxplorer.com`, which makes the network unambiguous in every event.

The second is the ledger/prose split described above. If a wiki page and `get_ledger` disagree
about a number, the ledger is right and the page needs an edit. Prefer the ledger for anything countable and
the wiki for anything argued.

## See also

- [What is a caper](/wiki/foundations/what-is-a-caper) — the company layer these tools read
- [Proposals](/wiki/governance/proposals) and [Execution](/wiki/governance/execution) — what the timeline's proposal and execution events represent
- [Trading](/wiki/markets/trading) — what the timeline's trade events represent
- [llms.txt](https://caper.network/llms.txt) — the machine-readable discovery file that advertises both servers
- [EIP-4824](/wiki/dao-governance/concepts/analysis/eip-4824) — the DAO description standard `dao.json` follows
- [Model Context Protocol](https://modelcontextprotocol.io) — the specification both servers implement

## What is a caper

URL: https://caper.network/wiki/foundations/what-is-a-caper
Updated: 2026-08-10
Verified: 2026-08-01

|  |  |
| --- | --- |
| **Topic** | Core concept |
| **Components** | Governance token · Treasury · Bonding-curve AMM |
| **Supply** | 100bn, fixed at genesis |
| **Proposals** | Payout · Invest · Divest · Vote · Upgrade |
| **Exit** | Always open – the treasury share equals your voting weight |
| **Related** | [Getting started](/wiki/foundations/getting-started), [Bonding curve](/wiki/markets/bonding-curve), [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) |

A **caper** is an organization that anyone can launch in one click. Each caper has its own token, treasury, and community of holders who steer it by making proposals and voting. Caper is the launchpad that creates these organizations and keeps them honest.

The four promises:

- **Launch and raise instantly.** No paperwork, no team, no upfront capital. Pick a name, sign one transaction, and your token is live with a market open for backers.
- **Always tradeable.** Every caper has a built-in market — buy in or cash out at any time against a pool that never disappears.
- **Real say.** Holders vote on every meaningful decision, and voting weight is the product of the tokens you hold and the votes you have actually cast. No insiders with hidden allocations.
- **Always exit.** Burn your stake and walk away with your share of the treasury. The door is never locked.

## The three permanent components

- A fixed-supply **governance token** — 100 billion units, minted once at genesis. The resource has no mint or burn role, so supply is structurally unchangeable.
- A **treasury** that holds XRD and any tokens the DAO accumulates.
- A perpetual **bonding-curve AMM** that mediates every buy and sell of the governance token.

All 100bn tokens are minted into a single inventory vault on the curve. There is no upfront founder allocation and no pre-allocated Caper Commons bucket — both accrue continuously, per buy, as a small fraction of each trade.

## The life of a caper

**1 — Launch.** One transaction creates the token, the treasury, and the curve, and hands the founder a badge. Nothing else is needed — see [Raising funds](/wiki/markets/raising-funds) for what the founder does and doesn't get.

**2 — Trade.** Backers buy and sell against the [bonding curve](/wiki/markets/bonding-curve) at a price set by a fixed formula, not by matching counterparties — so the market exists from the first second and can never be rugged away. A 0.5% fee on each trade is what funds the system; the buy-side fee flows into that caper's own treasury. Details in [Trading](/wiki/markets/trading).

**3 — Govern.** Any member can raise a proposal, and a proposal is either _legislative_ – a signal-only vote that records an outcome and touches nothing on-chain – or _executive_, in which case each option carries exactly one of five on-chain actions: **Payout** (send treasury funds to a recipient), **Invest** (spend treasury XRD buying another caper's token), **Divest** (sell a token this treasury already holds back into that caper's curve for XRD), **Vote** (cast this caper's treasury weight in _another_ caper's governance — capers can be members of capers), or **Upgrade** (swap the platform's shared logic, reserved to the $CAPER caper itself). The full set is broken down in [Proposals](/wiki/governance/proposals). Ballots are complete rankings settled by a [Borda count](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods) rather than an instant runoff: every voter must rank every option, and a partial or duplicated ballot is rejected outright. Voting weight rewards commitment twice over — it scales with both the tokens you hold _and_ the soulbound vote tokens you've earned by participating in past votes. See [Proposals](/wiki/governance/proposals) and [Voting](/wiki/governance/voting).

**4 — Exit.** At any time, a member can burn their stake and receive their share of the treasury — computed by the _same formula_ as their voting weight, so influence and exit rights can never drift apart. This is the strongest form of the [rage-quit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) pioneered by MolochDAO: not a proposal, not a grace period — a standing door.

## Founder economics

Founders are paid by the market, not by a pre-mine. On each buy, a small and steadily shrinking slice of the newly-sold tokens routes to the founder's vault instead of the buyer, and 1/31 of that slice goes to the $CAPER treasury — so every caper launched strengthens the commons. The slice tapers to zero as the token distributes, which means a founder's upside comes from growing the caper, not from dumping an allocation. Full mechanics in [Raising funds](/wiki/markets/raising-funds).

## Capers in the DAO landscape

A caper is a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) in the strict sense — treasury, token-weighted votes, on-chain execution — but it bundles into one contract what most DAOs assemble from parts: a token launch, an AMM pool, a [treasury custody solution](/wiki/dao-governance/tooling/treasury/safe), a [voting system](/wiki/dao-governance/tooling/voting/snapshot), and an execution layer. That single-contract design closes the gaps where DAO failures historically live — unfunded treasuries, [governance](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) that can't execute, and members trapped behind [treasuries](/wiki/dao-governance/concepts/treasury/dao-treasury-management) they can't reach. Where it sits in the industry's arc — and what it inherits from a decade of experiments — is covered in the [history of DAOs](/wiki/dao-governance/concepts/fundamentals/history-of-daos).

## The fee structure

A caper charges six fees. Trading fees are small and paid in XRD; the founder reward is paid in the curve’s own composition — two thirds in XRD, one third in the caper’s own token — and fades to zero as the curve fills. Nothing is burned — every fee recycles into a treasury, and two of them feed the **$CAPER** treasury, which collects a slice of every caper on the platform.

CAPER PROTOCOLFee structureSIX FEESXRDpaid in XRDTOKENpaid in the caper’s own tokenTHE SIX FEESACTIONAMOUNTPAID INFLOWS TOCreate a caperone-time registration10 – 1,000,000 XRDby ticker lengthXRD$CAPER treasuryBuyon the bonding curve0.5%of the XRD spentXRDthis caper’s treasurySell · Swap · Exitleave a position0.5%of the XRD receivedXRD$XRD treasuryFounder rewarda slice of each buy15% → 0%fades out by 30% soldXRD + TOK⅔ xrd  ·  ⅓ coin  ·  $CAPER 1/31Proposeopen a vote500 XRDdeters proposal spamXRDthis caper’s treasuryVotecast a ballot100 XRDskin in the gameXRDthis caper’s treasuryTHE FOUNDER’S SHARE FADES TO ZERO0%5%10%15%0%10%20%30%40%15% at launch0% at 30% sold% of the caper’s supply soldShare vs earningsThe founder’s cut of each buy is largest atlaunch, when risk is highest, and falls tozero by 30% sold. But price starts nearzero, so actual earnings aren’tfront-loaded: they build with activity, thenfade as the rate does.Paid ⅔ in XRD, ⅓ in the coin – 30/31 founder, 1/31 $CAPER.WHERE VALUE POOLSTHIS CAPERFED BYBuy fee0.5%Propose500 XRDVote100 XRDFunds the caper you’reactive in — its own war chest.$XRDFED BYSell · Swap · Exit0.5%Shared by every $XRD holder— the platform’s base layer.INDEX FUND$CAPERFED BYCreation feesXRDFounder reward1/31XRD + a token from everycaper — an index fund onall of Caper.All figures are protocol defaults — adjustable by governance.caper.networkCaper’s six fees and where each one flows · platform-level settings, changed only with the protocol admin badge.

## Who sets the fees

None of these numbers live inside an individual caper. Every caper on the platform trades through one shared logic component, and that component holds a single fee schedule for all of them: a **0.5% trade fee**, a **collateralization peak** of 0.15 that sizes the founder reward, a **500 XRD** proposal fee and a **100 XRD** vote fee. They are instantiation values, not constants — one method, `update_fees`, rewrites all four in a single call.

That method is not open to a caper's own [proposals](/wiki/governance/proposals). It is restricted to an `admin` role that requires the registry's protocol admin badge — the same key that authorises a [logic upgrade](/wiki/governance/execution). So a caper's members govern their treasury, not the platform's fee schedule. The registry itself globalizes under an _updatable_ owner rule, which is what leaves room for that authority to be re-pointed at **$CAPER** governance later; until it is, the badge is the answer to “who can change this?”.

Exactly one of the four is bounded in code: the collateralization peak must sit in [0, 0.15]. The bound exists because the founder's ceiling is _derived_ from the peak rather than stored beside it — at the maximum, the founder's share of a buy works out just under 5%. Unbounded, that ceiling would be a setting the badge could raise; bounded, it is a property of the curve. The [founder reward](/wiki/markets/raising-funds) page carries the derivation, and [Trading](/wiki/markets/trading) covers where each fee lands.

## Execution

URL: https://caper.network/wiki/governance/execution
Updated: 2026-08-10

|  |  |
| --- | --- |
| **Topic** | Carrying out a passed proposal |
| **Timeline** | Voting closes → crystallize (chunked tally) → execution delay (~10 min) → settle → execute |
| **Executive action kinds** | PAYOUT · INVEST · DIVEST · VOTE · UPGRADE ($CAPER only) |
| **Replay guards** | Two once-only flags — `settled`, then `executed` |
| **Settlement gas** | Treasury-reimbursed — up to 5 XRD per call against a 500 XRD per-proposal allowance |
| **Related** | [Proposals](/wiki/governance/proposals), [Voting](/wiki/governance/voting), [Voting mechanisms](/wiki/governance/voting-mechanisms), [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) |

Once a proposal's voting window closes, resolution happens in public steps anyone can run: **crystallize** the ballots — fold them into an on-chain running count, in as many chunked transactions as the turnout needs, with no cap on how many members may vote — then, once the **execution delay** has elapsed (roughly ten minutes by default), **settle** the proposal to freeze the winner from that count, and finally submit the transaction that **executes** the winning option. The delay is a deliberate pause between the decision and the act — the same role a timelock plays in [mainstream DAO governance](/wiki/dao-governance/concepts/voting/proposal-lifecycle), giving members a window to react before an executive action lands.

## Crystallize, settle, execute — once-only guards

Resolution is guarded at every step: the tally cursor only moves forward, each ballot is counted exactly once, and a proposal can never be settled twice or executed twice.

**Crystallize.** Anyone can fold the next chunk of ballots into a persistent on-chain count. Each ballot carries a [vote weight](/wiki/governance/voting), and that weight is spread across the options the ballot ranked: an option placed at rank _i_ receives `(N − 1 − i)` times the voter's weight, so a first choice counts most and a last choice counts nothing. The weight's holdings term is clamped to the smaller of what the voter held when they voted and what they hold now, and until settlement anyone can re-observe a counted ballot and ratchet its credit further down if that stake has since moved — selling after voting only ever shrinks a vote. Because the count persists across transactions, turnout has no ceiling.

**Settle.** Settling reads the finished count and freezes the winner. The option with the greatest summed weight wins only if its share of the total weight cleared the `1.5 / N` supermajority **and** it is not the no-execution option; otherwise the proposal finalizes with no winner. A count completed in a single pass after the execution delay elapsed settles immediately; any other count must first wait out a one-hour challenge window in which anyone can re-check its ballots. This step flips a `settled` flag and can run only once.

**Execute.** With a winner frozen, execution flips a separate `executed` flag — the guard that stops the same winning action from being replayed. A settled proposal that did not pass has no winner to execute, and a [legislative proposal](/wiki/governance/proposals)'s winner carries no on-chain action at all — so only executive winners reach this step.

## Who pays to settle

Every step after voting closes is permissionless, and permissionless work still costs gas. A large proposal's settle path is not one transaction but dozens — a thousand-ballot proposal runs roughly fourteen crystallize chunks, roughly fourteen reclamp sweeps and a settle, at the contract's 75-ballot chunk size — and none of it is contingent on the proposal passing. Leaving that bill with whoever happens to click Settle taxes one member for a public good the whole caper consumes.

That is the default almost everywhere else. In [OpenZeppelin's Governor](https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-contracts/master/contracts/governance/Governor.sol) and in [Compound's Governor Bravo](https://raw.githubusercontent.com/compound-finance/compound-protocol/master/contracts/Governance/GovernorBravoDelegate.sol), `execute` is an ordinary `payable` function with no access control: anyone may call it once the proposal is queued, and the caller pays the gas from their own pocket with nothing coming back. In practice the proposer, a delegate or a bot absorbs it, and the cost appears in none of the governance ledgers surveyed in [DAO governance operating costs](/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs). What that unpriced work costs when a DAO buys it from an automation vendor instead, and why it stays invisible when it does not, is on [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs).

A caper reimburses it instead. Each settle-path call draws up to **5 XRD** from the treasury against a **per-proposal allowance of 500 XRD** — deliberately the same figure as the default proposal fee that proposal already paid into that same treasury, so a proposal funds its own settlement and can never cost the treasury more than it contributed. The allowance covers the measured thousand-voter path around four times over; past it the draw returns zero and the caller pays, so an unusually large proposal degrades rather than bricks. The per-call figure is a ceiling, not a charge: the engine refunds whatever a lock does not consume.

The draw is a **contingent** fee lock, and that is load-bearing rather than a detail. A plain `lock_fee` credits the fee reserve immediately and survives an aborted transaction; [a contingent lock never touches that balance](https://raw.githubusercontent.com/radixdlt/radixdlt-scrypto/main/radix-engine/src/system/system_modules/costing/fee_reserve.rs) and is charged only when the transaction commits. Without it, anyone could call a settle-path method, abort the transaction, and drain the treasury while the allowance counter rolled back every time. Because payment and allowance now move together, the worst a spammer gets is an allowance draining at the same rate real work would drain it.

Where the draw rides differs by entry point, and the difference is deliberate. Settle and reclamp gas their _read_, so a sweep that finds nothing to ratchet down still pays the keeper who ran it — honest work that happens to find nothing is still work. Crystallize gasses its _write_, so calling it again once the tally is already complete writes nothing and draws nothing. The allowance ledger itself lives in the immortal state tier beside the funds, while the budget and the per-call ceiling are logic-tier policy: an [UPGRADE](/wiki/governance/proposals) can retune what settlement costs without touching the record of what has already been spent.

## The executive actions

**PAYOUT** and **INVEST** each execute in a single call. PAYOUT transfers the chosen currency and amount out of the treasury to the stored, voted-on recipient — by way of an [account locker](https://docs.radixdlt.com/docs/locker) rather than a direct deposit, so a recipient whose account rejects the resource cannot abort the execution; the payment simply waits to be claimed. That, and the rest of the treasury's plumbing, is covered under [raising funds](/wiki/markets/raising-funds). INVEST runs its whole withdraw → [buy](/wiki/markets/bonding-curve) → deposit inside the contract's own call frame, so the treasury XRD it spends never touches the transaction worktop — a public executor cannot take part of the withdrawal and pocket the rest. The execution step asserts the bucket handed back is the target caper's token, in a positive amount, before it lands in the treasury.

**VOTE** is split across several manifest instructions, because it must re-enter a separate component mid-transaction. A first call hands the manifest the target token, the XRD vote fee, and the treasury admin badge; the manifest presents that badge as a proof to authorise the treasury's vote into the target caper's proposal, routed through a fresh top-level frame; a final call returns the badge to its vault. Because the whole sequence is one atomic transaction, the admin badge never survives a transaction boundary outside the vault — if any step fails, the entire execution rolls back.

**DIVEST** is INVEST run backwards, and it is the newest of the five. Execution withdraws the voted-on amount of the target caper's token from this treasury, sells it into that caper's [curve](/wiki/markets/bonding-curve), and deposits the XRD — again entirely inside the contract's own call frame, so the tokens never touch the worktop. Two guards ride it. The withdrawal aborts outright if the treasury's holding has fallen below the amount that passed, because executing a smaller trade than the one that was voted on would break the frozen-winner contract; and the sell asserts the bucket handed over is the target caper's own resource, so a stale address aborts rather than selling the wrong thing. The $XRD caper is excluded by name — it has no curve to sell into. Where INVEST fuses its guard and its withdrawal into one state-tier call, DIVEST composes two generic ones the immortal tier already exposes, paying an extra cross-package hop to avoid redeploying that tier; the whole action therefore shipped through the ordinary UPGRADE path with no per-caper migration. Its sell leg emits the same event an ordinary sale does, so it appears on the target caper's [trade feed](/wiki/markets/trading) with no divest-specific arithmetic anywhere off-chain.

**UPGRADE** is the one action reserved for the [$CAPER](/wiki/foundations/what-is-a-caper) caper itself. Its winning option swaps the platform's live logic tier through the registry, in a two-phase propose-then-activate sequence — this is the mechanism by which the whole system upgrades itself under governance rather than under an admin key.

## Where each action runs — state tier vs logic tier

A [caper](/wiki/foundations/what-is-a-caper)'s contract is split into an immortal **state tier** that holds the treasury and the durable proposal record, and a swappable **logic tier** that carries the math and the executive plumbing. Which tier performs a winner depends on what the action touches.

**PAYOUT executes inside the state tier**, because the voted-on recipient is a `Global` that only stays invokable as a stable substate reference — it cannot be handed to the logic tier and called there. The state tier therefore performs the transfer to the stored recipient itself, and no executor can redirect it. **INVEST, DIVEST, VOTE and UPGRADE carry no account reference**, so the logic tier drives them, reading back only the frozen typed option from state. That division is why an upgrade can replace the entire logic tier without ever putting the treasury or the proposal ledger at risk.

## Hand-rolling an executor manifest

If you ever build an executor manifest by hand, end it with a `try_deposit_*_or_abort`: the Radix Engine's General transaction classifier only whitelists the `_or_abort` deposit variants, and the `_or_refund` forms make the wallet display a "Complex transaction" warning instead of a clean summary.

## Proposals

URL: https://caper.network/wiki/governance/proposals
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Type** | Ranked-choice ballot, two or more options |
| **Proposal type** | Legislative (signal-only) or executive |
| **Executive action kinds** | PAYOUT · INVEST · DIVEST · VOTE · UPGRADE ($CAPER only) |
| **Costs** | Configured schedule — 500 XRD to propose · 100 XRD per ballot, both admin-settable, both paid into the caper's own treasury |
| **Passes at** | 1.5 / N supermajority of weight cast |
| **Related** | [Voting](/wiki/governance/voting), [Execution](/wiki/governance/execution), [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) |

A **proposal** is a ranked-choice ballot with two or more options that a caper's members vote on to decide what the treasury does. The proposal as a whole is either _legislative_ (signal-only) or _executive_, and each option on an executive proposal carries an on-chain action the contract performs if that option wins.

## Legislative or executive

Which of the two a proposal is gets fixed when it is created and written into the proposal's stored metadata; nothing later can change it. A **legislative** proposal is pure signal – a sentiment check, a mandate, a statement of intent – and carries no on-chain action, so there is nothing for anyone to execute once it resolves. An **executive** proposal's options each carry exactly one action, and the winning option's action is what the [execution step](/wiki/governance/execution) performs.

The distinction is a property of the proposal, not of an individual option. On-chain it is a single boolean recorded alongside the title and description; the option's own `kind` field is a separate discriminant that selects which of the five actions below it carries.

## The five executive action kinds

- **PAYOUT** — transfers a chosen currency and amount from the treasury to a recipient (another caper's treasury or a raw account), by way of an [account locker](/wiki/markets/raising-funds) so a recipient's deposit rules cannot abort the execution.
- **INVEST** — withdraws XRD from this treasury, buys a target caper's governance token on its [bonding curve](/wiki/markets/bonding-curve), and deposits the tokens back into this treasury.
- **DIVEST** — the same trade run backwards: withdraws a voted-on amount of a target caper's token this treasury already holds, sells it into that caper's curve, and deposits the XRD. It stores the identical fields to INVEST and differs only in direction, so a caper can leave a position it voted itself into. The one target it cannot take is the $XRD caper, which has no bonding curve to sell into.
- **VOTE** — casts a pre-committed ranked ballot on _another_ caper's proposal, using one governance token of that target the treasury holds — letting a caper act as a member of another caper.
- **UPGRADE** — swaps the platform's shared logic tier to a candidate component, in a propose-then-activate sequence. Reserved to the $CAPER caper: one activation changes the logic every caper on the platform runs, so only the platform DAO may raise it, and the contract rejects an UPGRADE option anywhere else.

Every executive action is spelled out step by step, with the guards each one carries, in [Execution](/wiki/governance/execution).

## The no-execution option

Every proposal carries a **no-execution option** that voters can rank above any executive option. If it finishes first, the proposal resolves without touching the chain — the deliberate "do nothing" outcome, always on the ballot so a proposal can be defeated rather than only redirected.

## Passing the vote

Options are scored by [ranked-choice weight](/wiki/governance/voting), and the leading option only executes if it clears a **supermajority** — a `1.5 / N` share of all weight cast, where `N` is the option count. Falling short leaves the proposal resolved with no action. For how this maps onto the wider DAO pattern of forum discussion → temperature check → formal proposal, see the [DAO proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle).

Note what is _not_ in that rule: there is no quorum. Most token DAOs require a minimum share of token supply to participate before a result counts at all, which is the number an attacker prices when they buy an electorate. A caper's bar is a share of the weight _actually cast_, so there is no absolute figure to acquire – and equally no participation floor, which is a real trade rather than a free win. The comparison across Compound, OpenZeppelin, Arbitrum and Nouns is set out in [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design).

## What it costs, and who may propose

Caper has no supply-percentage proposal threshold. Two conditions gate a proposal, and both are flat:

- **Hold at least one governance token** of the caper you are proposing to. The contract checks a proof of the caper's own token for an amount of at least 1 and aborts the whole transaction if it fails – so any member can propose, regardless of the size of their position.
- **Pay the configured proposal fee, currently 500 XRD.** The payment must be exactly the configured fee, in XRD, and it is deposited into _that caper's own treasury_ rather than burned or held in escrow. It is a fee, not a refundable bond: it does not come back if the proposal fails.

Voting costs a separate ballot fee, currently **100 XRD**, on the same terms. A voter must also hold at least one governance token, and the ballot must rank every option exactly once. A vote submitted outside the voting window closes gracefully rather than reverting: no ballot is recorded, the call returns false, and the 100 XRD still goes to the treasury – so ballots are worth casting well before the boundary.

Neither figure is a constant. Both are stored fields the protocol admin can rewrite in a single `update_fees` call, so what is quoted here is the _configured_ schedule rather than a property of the contract; the only governance-adjacent number the contract actually bounds is the collateralization ceiling. See the [FAQ](/wiki/help/faq) on protocol fees.

Every proposal must offer **at least two options**, and one of them is the no-execution option. Two further restrictions apply to specific option kinds: custom voting and execution windows may only be set on an executive proposal that carries a VOTE option (a caper voting inside another caper's proposal, where the window has to fit the target's schedule), and UPGRADE options may only appear on the $CAPER caper's own proposals, because one upgrade swaps the shared logic for every caper on the platform.

The flat-fee design is a deliberate trade. A proposal threshold denominated as a percentage of supply concentrates the right to propose in the largest holders and grows more exclusive as the token appreciates; a fixed fee does not, though its real weight still moves with the XRD price. The wider pattern, and what other DAOs set instead, is covered in [Quorum and threshold design](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design).

## The proposal lifecycle

A proposal moves through three phases — propose, vote, execute — and can carry one of five on-chain actions. Winning takes more than a plurality: the top option must clear a supermajority of the vote.

CAPER PROTOCOLThe proposal lifecycle3 PHASES · 5 ACTIONSPROPOSE → VOTE → EXECUTE1PROPOSEPay a 500 XRD fee. Offer at leasttwo options, including a No.2VOTERank every option. Each ballotcosts 100 XRD.3EXECUTEAfter a delay, the winning optionruns on-chain.WHAT A PASSED PROPOSAL CAN DOPAYOUTPay a recipient from the treasury— a grant, a salary, a bill.INVESTBuy another caper’s token straightinto your treasury.DIVESTSell a token the treasury holdsback down its own curve.VOTECast your caper’s vote insideanother caper’s proposal.UPGRADESwap the shared logic. $CAPERproposals only.The winner needs the most weight AND at least 1.5 / N of the total vote. A “No” win does nothing.How a caper turns a decision into an on-chain action.caper.networkPropose → vote → execute · PAYOUT / INVEST / DIVEST / VOTE / UPGRADE.

## Voting

URL: https://caper.network/wiki/governance/voting
Updated: 2026-08-07

|  |  |
| --- | --- |
| **Method** | Ranked-choice (Borda-weighted) |
| **Weight** | Live governance balance × participation, read at vote time |
| **Proof** | Soulbound vote token — one per vote; drives exit |
| **Passes at** | 1.5 / N supermajority of weight cast |
| **Related** | [Proposals](/wiki/governance/proposals), [Execution](/wiki/governance/execution), [Voting mechanisms](/wiki/governance/voting-mechanisms) |

Voting on a caper is **ranked-choice**. You submit an ordered list of the proposal's options and the contract scores them Borda-style — with `N` options, your first pick earns `N−1` points and your last pick `0` — so a ballot expresses a full preference order rather than a single yes/no.

## How your weight is measured

Your voting weight is not simply your token balance — it is the _product_ of your stake and your participation. The contract computes `w = (t · v) / (V · T)`, where `t` is your governance-token balance read **live at the moment your vote transaction runs** (there is no separate past-block snapshot — and when the ballots are tallied after voting closes, the credited balance is clamped to the smaller of that snapshot and what you still hold, so later trades can shrink a cast vote but never grow it), `v` is your locked, non-transferable vote-token balance, `V` the total vote-token supply, and `T` the caper tokens in circulation.

Because `v` is read _before_ this vote mints its token, a member's very first vote counts `v = 0` and therefore carries zero weight: influence is earned by showing up, not bought in a single transaction. This participation gate — not a snapshot block — is what makes a caper resistant to [flash-loaned voting power](/wiki/dao-governance/concepts/voting/token-weighted-voting), the attack that has drained token-weighted DAOs like [Beanstalk](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

Each cast vote mints one **soulbound vote token** into your account — your permanent proof of participation. Vote tokens also drive [exit redemption](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights): to leave, you burn vote tokens alongside the caper tokens you redeem and receive a treasury share equal to your _canonical vote weight_ — the same metric that sets your voting power, so influence and redeemable stake stay aligned.

A proposal's voting window closes at its expiry. Anyone can then [crystallize the tally and settle](/wiki/governance/execution) the result — the option with the most total weight wins, but executes only if it clears a **supermajority** of `1.5 / N` of all weight cast. If it falls short, or if the no-execution option placed first, the proposal closes with nothing happening on-chain.

## What a ballot has to contain

The contract will not accept a partial ballot. Your ranking must cover **every** option on the proposal, exactly once — a short list, a repeated option, or an index that is not on the ballot all fail the transaction. That is what makes the Borda scoring comparable across voters: every ballot spends the same points, and the only thing that varies is the order.

Two other conditions gate a vote. You have to present a proof that you hold at least one of the caper's tokens, and the vote carries a fixed fee in XRD that is deposited into the caper's own [treasury](/wiki/foundations/what-is-a-caper). A vote that arrives outside the proposal's window is handled gracefully rather than reverted: the contract records nothing, returns false, and deposits the fee into the treasury the same way it would on the accepted path — so a late transaction fails without leaving anything half-applied.

## Selling after you vote, and who can make it count

The balance credited to a ballot is the smaller of what you held when you voted and what you hold when the tally runs, so credit only ever moves down. That rule is enforced by two calls that **anyone** can make, not by a privileged settler.

- **Crystallization** folds ballots into the proposal's persistent tally, re-reading each voter's live balance as it goes. Large proposals are folded in chunks, so no electorate is too big to settle.
- **Reclamping** re-observes a range that has already been crystallized and ratchets down any voter who has sold since. Because it can only lower credit, it is safe to leave permissionless — a spammer can spend gas re-checking, but cannot change a tally that is already honest.

A tally taken at one instant after the execution window opened settles straight away; any other tally has to sit out a challenge window first, during which a reclamp can still be run. The practical effect is that a member who votes and then sells into the result they voted for does not merely fail to gain — any other member can force the tally to notice, without asking anyone's permission. That is the same asymmetry the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) relies on, applied to the vote itself, and it is why a caper needs no snapshot block to resist [borrowed voting power](/wiki/dao-governance/concepts/voting/token-weighted-voting).

## What the circulating supply does, and what it cannot do

Weight is divided by the caper's [circulating token supply](/wiki/markets/bonding-curve) as well as by the total vote record. That divisor is the same for every member, so it cancels out of the only comparison [settlement](/wiki/governance/execution) actually makes: the leading option's weight against all weight cast. Circulation changes how fast the treasury pays out an exit; it cannot move a proposal's outcome.

One caper obtains the figure differently. The $XRD caper has no bonding curve, and its members hold native XRD, whose total supply cannot be read on-ledger at all — Radix creates XRD at genesis without supply tracking, so the resource simply reports no total. The contract substitutes XRD's protocol maximum instead, which is the tightest figure that is always at least the sum of member holdings. Erring high there makes exits conservative and leaves votes untouched, which is the right direction for both.

## How vote weight works

Vote weight multiplies what you hold by the voting record you have earned, so a big bag alone can’t capture control — and the very same number sets your share of the treasury when you exit.

CAPER PROTOCOLHow vote weight worksONE FORMULAvote weight  w  =  ( t · v )  /  ( V · T )tcaper tokens you holdvvote records you’veearnedVall vote records, totalTtokens in circulationHoldings alone aren’t control. You also needv — the record you can only earn by showingup and voting.The very same weight sets your share of thetreasury when you exit. Voting power andpayout scale together.Each vote mints one soulbound vote token — non-transferable, unbuyable proof that you participated.Power is earned, not just bought.caper.networkw = (t·v) / (V·T) · power is earned, not only bought.

## Voting mechanisms

URL: https://caper.network/wiki/governance/voting-mechanisms
Updated: 2026-08-06

|  |  |
| --- | --- |
| **Topic** | Collective decision-making |
| **Core trade-off** | Capital-weighted ↔ participation / identity-weighted |
| **Families** | Token-weighted · Quadratic · Conviction · Ranked-choice · Futarchy · Liquid |
| **On Caper** | Ranked-choice, weighted by stake _and_ participation |
| **Related** | [Voting](/wiki/governance/voting), [Proposals](/wiki/governance/proposals), [Execution](/wiki/governance/execution) |

A **voting mechanism** is the rule that turns a group's individual preferences into a single collective decision. Two mechanisms can take the same ballots and reach opposite outcomes, so the choice of mechanism is itself one of the most consequential decisions any organization makes. For a DAO it is doubly so: the rule is encoded in a contract, runs without a referee, and is exposed to adversaries who can hold tokens, borrow them, or mint fresh identities at will.

Every mechanism sits somewhere on one central axis: **capital-weighted** against **participation- or identity-weighted**. Capital weighting (one token, one vote) is naturally resistant to fake accounts — buying influence means buying the scarce token — but it concentrates power in the wealthiest holders. Identity weighting (one person, one vote) is egalitarian but collapses the moment one actor can pose as many people. Most of the designs below are attempts to move along that axis without falling off either end. Aragon frames the same landscape by the ["input space"](https://blog.aragon.org/a-taxonomy-of-voting-methods/) a ballot gives the voter — the richer the input (a rank, a score, a budget of vote credits), the more faithfully it captures what people actually want.

## Token-weighted (coin) voting

The default in on-chain governance: voting power is proportional to governance tokens held, and a proposal passes when support clears a threshold — often alongside a **quorum** (a minimum of the supply that must participate) and a **proposal threshold** (a minimum stake required to even put something to a vote). It is popular because it is simple, legible, and Sybil-resistant by construction.

Its weaknesses are equally well known:

- **Plutocracy.** Whales decide. Studies of large DAOs repeatedly find voting power concentrated in well under 1% of participants, with the long tail effectively unrepresented.
- **Voter apathy.** A single small holder's vote rarely changes an outcome, so most don't cast one; turnout in the single-digit percentages is common, which means a determined minority can carry a proposal.
- **Vote-buying and bribery.** As Vitalik Buterin argues in [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html), a voter who _borrows_ governance tokens has "no financial exposure" to the outcome — they can back a value-destroying decision and feel none of the damage. Voters are collectively accountable but never individually so.

The sharpest illustration is the **Beanstalk** attack of April 2022. An attacker took roughly a billion dollars in flash loans, converted them to the protocol's governance stake within a single transaction, instantly commanded a supermajority, and passed a proposal that drained about **$182M** from the treasury — all before the loan had to be repaid. The lesson DAOs took from it: voting weight must be snapshotted at a block in the past, never read live, or governance can be rented by the second. ([CoinDesk](https://www.coindesk.com/tech/2022/04/17/attacker-drains-182m-from-beanstalk-stablecoin-protocol))

## Quadratic voting

Quadratic voting (QV) lets a voter cast multiple votes on an issue they care about, but the _cost_ of votes rises with their square: one vote costs one credit, three votes cost nine, ten votes cost a hundred. Because the marginal cost of influence climbs steadily, people end up buying votes roughly in proportion to how much they care — so QV surfaces _how much_ a voter cares, not just which side they are on, while making it ruinously expensive for any single party to dominate.

Its formal case was made by Steven Lalley and Glen Weyl in [Quadratic Voting](https://www.ias.edu/sites/default/files/sss/pdfs/Rodrik/workshop%2014-15/Weyl-Quadratic_Voting.pdf) (2015): under price-taking behaviour QV is the only rule that is always efficient, and in a large electorate every symmetric equilibrium of the QV game converges on the efficient outcome, with the residual waste shrinking roughly as one over the number of voters — a direct answer to the "tyranny of the majority" that one-person-one-vote invites.

QV's roots are in corporate governance. Eric Posner and Glen Weyl first floated it in [Quadratic Vote Buying, Square Root Voting, and Corporate Governance](https://corpgov.law.harvard.edu/2013/06/06/quadratic-vote-buying-square-root-voting-and-corporate-governance/) (2013), proposing that shareholders cast votes equal to the _square root_ of their holdings so a large holder cannot simply steamroll the small ones, then developed the full argument in [Quadratic Voting as Efficient Corporate Governance](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2264245) (_University of Chicago Law Review_, 2014): decoupling votes from shares and pricing them quadratically protects minority shareholders and, they argue, yields efficient outcomes "under reasonable conditions." Vitalik Buterin and Glen Weyl carried the idea into crypto in [Liberation Through Radical Decentralization](https://medium.com/@VitalikButerin/liberation-through-radical-decentralization-22fc4bedc2ac) (2018), where a thousand votes cost a million credits — minority capture becomes prohibitively dear — but only if every voter is a verifiably separate person, a requirement squarely at odds with pseudonymous wallets. The idea has had real-world outings too: in 2019 the Colorado House of Representatives gave each legislator a budget of 100 vote credits to prioritize its appropriations backlog, and the quadratic cost forced them to reveal real priorities instead of rubber-stamping everything.

That identity assumption is QV's fatal flaw on-chain: split your tokens across many wallets and the quadratic penalty evaporates, so QV is only safe atop a working [proof-of-personhood](#sybil-resistance-and-identity) layer. The intensity it rewards can also be turned against it — Patty and Penn show in [Uncertainty, polarization, and proposal incentives under quadratic voting](https://doi.org/10.1007/s11127-017-0406-3) (_Public Choice_, 2017) that once voters also _set the agenda_, QV rewards floating more divisive, higher-variance proposals; the same intensity-sensitivity that makes QV efficient on a fixed question pulls the menu of questions toward polarization. Its better-known cousin, **quadratic funding** (the engine behind [Gitcoin Grants](/wiki/daos/public-goods/gitcoin-dao)), applies the same square-root math to donations so that the _number_ of backers matters more than the size of any one cheque.

There is a deeper, theory-side caveat to _any_ mechanism that tries to read intensity rather than mere rank. Ehlers, Majumdar, Mishra and Sen prove in [Continuity and Incentive Compatibility in Cardinal Voting Mechanisms](https://papyrus.bib.umontreal.ca/xmlui/bitstream/handle/1866/13352/Cahier_2016_04.pdf?sequence=1) (2016; _Journal of Mathematical Economics_, 2020) that, with no money changing hands, any cardinal voting rule that is both strategy-proof and continuous must collapse back to an _ordinal_ one — it can use voters' rankings but not how strongly they feel. Cardinal schemes escape this only by attaching a genuine cost to intensity, which is exactly what QV's vote credits do and an ordinary score ballot does not.

## Conviction voting

Conviction voting removes the deadline. Instead of a yes/no snapshot, voters stake tokens on the proposals they support and their **conviction** accumulates the longer the stake stays put; a proposal executes automatically once its built-up conviction crosses a threshold scaled to how much of the treasury it asks for. Support becomes a continuous signal rather than a moment, which makes last-minute, rented-capital swings useless — you cannot buy time-weighted conviction in one block.

The model has a rigorous backing. Michael Zargham of BlockScience recasts collective choice as a signal-processing problem in [Sensor Networks and Social Choice](https://github.com/BlockScience/conviction/blob/master/social-sensorfusion.pdf) (2018): individual preferences are continuously _fused_, like noisy sensor readings, into a smoothed estimate of what the community wants, so a vote becomes ongoing _preference estimation_ rather than a discrete ballot — the formal reason conviction should grow with sustained stake. Pioneered by the Commons Stack and first run in production by [1Hive's Gardens](https://github.com/1Hive/conviction-voting-app), the approach has also been proposed for funding public goods straight out of protocol issuance — see the [conviction-staked inflation funding](https://github.com/ethereum-funding/blockrewardsfunding/issues/39#issuecomment-478165174) discussion — on the argument that time-weighting raises the cost of bribery, since an attacker has to _sustain_ a bribe rather than pay once. It suits continuous funding decisions but still rests on a capital-weighted base and is, by design, slow.

## Futarchy

Futarchy, proposed by economist Robin Hanson, splits a decision into two questions and routes each to the tool best suited to it: **"vote on values, but bet on beliefs."** Token holders democratically choose a metric of success (say, treasury value a year out); **prediction markets** then decide which proposal is most likely to raise that metric, and the market's verdict carries the decision. It puts factual forecasts in the hands of those willing to put money behind them, but depends on liquid, hard-to-manipulate markets and a welfare metric that cannot be gamed. The market-design fine print matters as much as the idea: experimental economics has long shown that the _format_ of a market changes how people behave inside it. Coppinger, Smith and Titus found that Dutch and first-price sealed-bid auctions — formats theory treats as equivalent — drew _different_ bidding in the lab, with bidders straying from the risk-neutral predictions the theory assumed ([Incentives and Behavior in English, Dutch and Sealed-Bid Auctions](https://www.researchgate.net/publication/5210235_Incentives_and_Behavior_in_English_Dutch_and_Sealed-Bid_Auctions), 1980). For a system that hands the decision to a market, that is the warning: the betting rules are part of the mechanism, not a neutral wrapper around it — one reason futarchy remains more experimented-with than adopted.

## Ranked-choice and other preference methods

When a vote has more than two options, _how_ you collect and tally preferences matters as much as who votes. The main families:

- **Ranked-choice / instant-runoff (RCV/IRV).** Voters rank the options. If no option has a majority of first choices, the lowest is eliminated and its votes transfer to their next preference, repeating until one option holds a majority. This extracts far more information than a binary ballot and rarely "wastes" a vote on a losing favourite.
- **Condorcet methods.** Elect the option that would beat every other in a head-to-head matchup, when such an option exists — the most resistant to spoilers and strategic ranking.
- **Borda count.** Award descending points by rank position and sum them; simple, but sensitive to irrelevant alternatives.
- **Approval and score voting.** Cardinal methods: approve any number of options (approval), or score each on a scale (score/range). Easy to tally and friendly to consensus candidates — and their incentives can be made sharp: Shah and Zhou show in [Approval Voting and Incentives in Crowdsourcing](https://proceedings.mlr.press/v37/shaha15.html) (ICML 2015) that pairing approval ballots with the right strictly-proper scoring rule yields the unique "no-free-lunch" scheme under which honestly reporting the set of options you find plausible is the optimal strategy.

No ranked method is perfect, and that isn't a bug to be fixed: **Arrow's impossibility theorem** (Kenneth Arrow, 1951) proves that with three or more options, no ranked voting rule can satisfy a short list of obviously-desirable fairness conditions at once. The practical takeaway is comparative, not defeatist — some methods (Condorcet) fail those conditions far less often than others (plurality), so "least bad for this decision" is the right question.

## Liquid democracy and vote-escrow

**Liquid democracy** lets each voter either vote directly or **delegate** their weight to someone they trust — and delegations are transitive and revocable, so expertise can pool without anyone permanently handing over their voice. The modern framing comes from Bryan Ford's 2002 [Delegative Democracy](https://bford.info/2002/05/15/deleg/). It fights apathy by letting busy holders lend their weight to active delegates — though, as DAO delegation data shows, it can also quietly re-concentrate power in a handful of large delegates.

**Vote-escrow (ve) models**, popularized by [Curve's veCRV](https://curve.readthedocs.io/dao-vecrv.html), tie weight to commitment: lock tokens for up to four years and your voting power scales with how long you lock, then decays as the lock runs down. The aim is to hand the steering wheel to long-term aligned holders rather than mercenary, transient capital — at the cost of liquidity and, in practice, a secondary market in "bribes" for locked votes.

## Off-chain and on-chain voting

Where a vote runs is a design choice in itself:

- **Off-chain (e.g. Snapshot).** Votes are wallet signatures over a past token snapshot — gasless and high-turnout, but the result is only a signal until someone (usually a multisig) executes it. Cheap participation, with a trust assumption at the end.
- **On-chain (Governor-style).** Proposals, votes, a timelock, and execution all live in the contract — fully trustless, but slower and more expensive to participate in.
- **Bridges.** Optimistic execution (post a passed off-chain result on-chain, executable unless challenged) and **holographic consensus** (a prediction market "boosts" high-signal proposals so a large DAO can decide without full quorum on everything) try to keep the cheapness of off-chain with the finality of on-chain.

The contract can also defend the clock itself. **Wait-for-quiet** voting — proposed by Dominic Williams and used in the Internet Computer's network governance — pushes a proposal's deadline back every time the leading outcome flips, so a large holder cannot lurk until turnout is thin and snipe the result in the final block; the vote closes only after a stretch of _quiet_ in which the lead holds. It is the timing-side complement to reading voting weight from a past snapshot block — the fix DAOs adopted after Beanstalk.

## Sybil resistance and identity

Every mechanism that moves away from pure capital weighting — quadratic, one-person-one-vote, reputation — needs a way to stop one actor from minting many identities. **Proof-of-personhood** aims to certify "one human, one account" without full doxxing: social-graph analysis (BrightID), curated registries with vouching (Proof of Humanity), or biometric uniqueness (World ID). It is the precondition for egalitarian voting on a permissionless network, and the reason token voting persists as the default: tokens give you Sybil resistance for free, while every alternative has to build an identity layer first.

## Choosing a mechanism

There is no universally best rule. The choice is a trade-off between decentralization, resistance to manipulation, and broad participation — push hard on any one and the others give. Token voting buys manipulation-resistance and simplicity at the cost of equality; quadratic and identity schemes buy equality at the cost of needing a trustworthy identity layer; conviction and ve-models buy resistance to rented capital at the cost of speed and liquidity. Recent research even argues that no purely wallet-weighted rule can fully escape plutocracy against a rational attacker — which is why mature designs increasingly _combine_ stake with something money can't cheaply buy: time, participation, or verified identity.

## Voting on Caper

Caper takes the combining route. Decisions are made with [ranked-choice voting](/wiki/governance/voting) over [proposals](/wiki/governance/proposals) that can carry real on-chain actions, and weight is read from each member's live governance balance when the ballot is cast — then clamped at the tally to what they still hold — while the requirement that influence be earned one vote at a time closes the flash-loan door that sank Beanstalk. The distinctive part is what weight is made of: it grows with both the stake you hold _and_ the participation you've actually shown, so influence accrues to members who show up rather than to capital that merely passes through. That same earned weight sets each member's claim on the treasury at [exit](/wiki/governance/execution) — voice and exit are the same number — which keeps governance honest without leaning on quorum alone. The specifics live on the linked governance pages; this article is the map of the wider territory they sit in. For the on-chain governance landscape specifically, see [DAO governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) and the cornerstone [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao).

## References

_Quadratic voting and cardinal mechanisms:_

- Steven P. Lalley & E. Glen Weyl, [Quadratic Voting](https://www.ias.edu/sites/default/files/sss/pdfs/Rodrik/workshop%2014-15/Weyl-Quadratic_Voting.pdf) — working paper (2015); condensed as "Quadratic Voting: How Mechanism Design Can Radicalize Democracy," _AEA Papers & Proceedings_ 108 (2018).
- Eric A. Posner & E. Glen Weyl, [Quadratic Vote Buying, Square Root Voting, and Corporate Governance](https://corpgov.law.harvard.edu/2013/06/06/quadratic-vote-buying-square-root-voting-and-corporate-governance/) — Harvard Law School Forum on Corporate Governance (2013).
- Eric A. Posner & E. Glen Weyl, [Quadratic Voting as Efficient Corporate Governance](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2264245) — _University of Chicago Law Review_ 81 (2014).
- Vitalik Buterin & E. Glen Weyl, [Liberation Through Radical Decentralization](https://medium.com/@VitalikButerin/liberation-through-radical-decentralization-22fc4bedc2ac) (2018).
- John W. Patty & Elizabeth Maggie Penn, [Uncertainty, polarization, and proposal incentives under quadratic voting](https://doi.org/10.1007/s11127-017-0406-3) — _Public Choice_ 172 (2017): 109–124.
- Lars Ehlers, Dipjyoti Majumdar, Debasis Mishra & Arunava Sen, [Continuity and Incentive Compatibility in Cardinal Voting Mechanisms](https://papyrus.bib.umontreal.ca/xmlui/bitstream/handle/1866/13352/Cahier_2016_04.pdf?sequence=1) — Université de Montréal (2016); _Journal of Mathematical Economics_ 88 (2020).

_Preference methods, auctions, and conviction:_

- Nihar B. Shah & Dengyong Zhou, [Approval Voting and Incentives in Crowdsourcing](https://proceedings.mlr.press/v37/shaha15.html) — _Proceedings of ICML_ (2015).
- Vicki M. Coppinger, Vernon L. Smith & Jon A. Titus, [Incentives and Behavior in English, Dutch and Sealed-Bid Auctions](https://www.researchgate.net/publication/5210235_Incentives_and_Behavior_in_English_Dutch_and_Sealed-Bid_Auctions) — _Economic Inquiry_ 18 (1980).
- Michael Zargham (BlockScience), [Sensor Networks and Social Choice](https://github.com/BlockScience/conviction/blob/master/social-sensorfusion.pdf) (2018) — the signal-processing basis for conviction voting.
- [Conviction-staked inflation funding](https://github.com/ethereum-funding/blockrewardsfunding/issues/39#issuecomment-478165174) — Ethereum public-goods funding discussion.
- Dominic Williams, [Using "wait-for-quiet" voting](https://medium.com/@dominic_w/using-wait-for-quiet-voting-in-the-dao-12ecd9d9ccc3) — deadline extension as a defence against last-minute swings.

_Further reading:_

- Aragon, [A taxonomy of voting methods](https://blog.aragon.org/a-taxonomy-of-voting-methods/) (2021).
- Vitalik Buterin, [Moving beyond coin voting governance](https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).
- CoinDesk, [Attacker Drains $182M From Beanstalk](https://www.coindesk.com/tech/2022/04/17/attacker-drains-182m-from-beanstalk-stablecoin-protocol) (2022) — the flash-loan governance attack.
- The Colorado Sun, [Colorado's experiment with quadratic voting](https://coloradosun.com/2019/05/28/quadratic-voting-colorado-house-budget/) (2019).
- Robin Hanson, [Futarchy: Vote Values, But Bet Beliefs](https://mason.gmu.edu/~rhanson/futarchy.html).
- Bryan Ford, [Delegative Democracy](https://bford.info/2002/05/15/deleg/) (2002).
- Curve, [Voting Escrow (veCRV)](https://curve.readthedocs.io/dao-vecrv.html).
- Wikipedia, [Arrow's impossibility theorem](https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem).

## Ranked-ballot voting

Caper resolves proposals with a ranked ballot scored by Borda count: you rank every option, each rank’s points scale by your vote weight, and the option that clears the supermajority threshold wins.

CAPER PROTOCOLRanked-ballot votingBORDA COUNTRANK EVERY OPTION · BORDA COUNTA ballot with 4 optionspoints = N − 1 − rank11st choice3 pts22nd choice2 pts33rd choice1 pts44th choice0 ptsHOW THE TALLY RESOLVES1Your points on each option are scaled byyour vote weight w.2Every voter’s weighted points add up peroption.3The option with the most weight wins —if it clears 1.5 / N of the total.You must rank every option — no bullet voting. One soulbound vote token per ballot.Every option ranked; a supermajority decides.caper.networkRank every option · Borda count · 1.5 / N supermajority.

## FAQ

URL: https://caper.network/wiki/help/faq
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Type** | Reference |
| **Covers** | Tokens · selling · voting · proposals · exit · fees · Caper Commons · divesting · platform upgrades |
| **Verified against** | The contract source (`contracts/logic/src/lib.rs`, `contracts/core/src/caper_dao.rs`) at `163e53e`, 11 August 2026 |
| **Related** | [What is a caper](/wiki/foundations/what-is-a-caper), [Bonding curve](/wiki/markets/bonding-curve), [Voting](/wiki/governance/voting), [Proposals](/wiki/governance/proposals) |

## Why can't I see the create-proposal button?

You need to hold the caper's governance token in the connected account. Buy any amount on the curve and the button appears.

## What happens to the inventory vault when I sell?

Your tokens go back into the inventory vault and your XRD comes out of the curve vault, priced along the same curve. The protocol does not burn anything on sell.

## Is there a minimum trade size?

Yes, on the buy side: a buy must be at least `0.001 XRD`. There is no upper limit other than the curve's own cap of `100,000,000,000` tokens, which no buy may push past.

## Can I withdraw governance tokens to another wallet?

Yes. Governance tokens are normal fungibles. Vote tokens are soulbound and cannot be transferred between holders, only withdrawn to your own worktop to feed `exit()`.

## How does voting actually work — do I pick one option?

No. A caper ballot is a [ranked ballot](/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods): you submit an ordering of _every_ option on the proposal. The contract rejects a ballot that omits an option, ranks one twice, or references an option that does not exist. When voting closes, the ballots are folded into per-option totals by a Borda-style count weighted by each voter's [vote weight](/wiki/governance/voting), so a second preference is worth something rather than nothing.

## What does a proposal need to pass?

Two conditions, both checked at settlement. The leading option's share of total weight must reach `1.5 ÷ (number of options)`, and the leader must not be an option flagged as a "no". The threshold therefore scales with how many choices are on the ballot: **75%** for a two-option proposal, **50%** for three, **37.5%** for four, **30%** for five. A crowded ballot is easier to win but splits the field — which is the point of ranking every option rather than picking one.

## Why did my first vote seem to count for nothing?

Because it did. Your weight is `(t·v)/(V·T)`, and the contract snapshots `v` — the vote tokens you already hold — _before_ minting the vote token that this ballot earns you. On your very first ballot `v` is zero, so the weight is zero. Voting is how you accumulate the participation factor; the first one buys you standing, not influence. This is the mechanical reason a large token balance alone cannot carry a proposal.

## What if I sell my tokens after voting?

Your recorded weight falls. The tally re-reads your live balance and takes the _lower_ of it and the balance you held when you voted, so selling reduces your ballot's weight while buying more afterwards does not increase it. Anyone may call the re-clamp permissionlessly during the challenge window before settlement — it can only ever ratchet a weight down, which is why it is safe to leave open to the public.

## What happens if I vote after voting has closed?

The call does not fail; it returns without recording a ballot, and the vote fee — **100 XRD** as configured today — is deposited to the caper's treasury rather than refunded. Check the window before submitting.

## What is the Caper Commons?

The protocol-wide treasury that holds `1/31` of the token leg of every caper's per-buy skim — a small standing position in every caper on the platform. Its policy is set by `$CAPER` governance.

## How is my exit payout calculated?

When you call `exit()` you redeem a slice of the caper's treasury equal to your [canonical vote weight](/wiki/governance/voting) `(t·v)/(V·T)` — the exact figure that sets your voting power (t = governance tokens redeemed, v = your vote tokens, V = total vote-token supply, T = tokens in circulation). It is not a flat pro-rata claim on tokens alone: the contract requires _both_ a non-empty governance-token bucket and a non-empty vote-token bucket, so a holder who never voted redeems nothing. Your voting influence and your redeemable share are one and the same number: Caper's always-on take on the [rage-quit](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights).

## What are the protocol fees?

Three, and none of them is a constant. The **0.5%** trade fee on every buy and sell, the **500 XRD** proposal fee to open a governance [proposal](/wiki/governance/proposals), and the **100 XRD** vote fee are all stored fields the protocol admin can change through a single `update_fees` call, so they are the _configured_ schedule rather than a property of the contract. Only the collateralization ceiling below is bounded in code. All three land in a caper's own treasury; see [trading](/wiki/markets/trading) for how the trade fee moves the vaults.

The vote fee is charged on _every_ ballot a member casts, not only when your caper votes in another DAO through a VOTE proposal — that execution simply carries the same fee. It is the one fee you pay whether or not it buys you anything: an out-of-window ballot still forfeits it (see above).

## Is the collateralization skim a fee?

No, and it is worth separating. Every buy is also skimmed for the caper’s founder and the Caper Commons (above) in a 30:1 split, taken partly in XRD off the payment and partly as a slice of the tokens the buy mints. It never touches the caper’s treasury, so it is not a protocol fee — it is the founder’s compensation. Its _rate_, set by the [bonding curve](/wiki/markets/bonding-curve)’s collateralization schedule, is front-loaded: highest on the first buys and tapering linearly to zero as circulation grows, with the peak bounded in the contract rather than left to configuration. The rate falling does not mean the amount falls with it — a smaller share of much larger buys can still be more money. [Raising funds](/wiki/markets/raising-funds) works through it.

## A caper I hold owns tokens in another caper. Can it sell them?

Yes, through a **DIVEST** proposal – the newest of the five executive [action kinds](/wiki/governance/proposals), and an **INVEST** run backwards. A winning DIVEST option withdraws a voted-on amount of the target caper's token from this treasury, sells it into that caper's own [bonding curve](/wiki/markets/bonding-curve), and deposits the XRD proceeds straight back into this treasury.

Two details matter in practice. The amount is frozen at settlement, so if the treasury's holding of that token has fallen below the voted figure by the time someone executes, the call _aborts_ rather than quietly selling less – executing a smaller trade than the one that passed would break the frozen-winner rule the whole [execution step](/wiki/governance/execution) rests on. And the sale is emitted as an ordinary sell on the target caper's [trade feed](/wiki/markets/trading), at the ordinary price convention, so a treasury divesting looks the same to the market as any other seller. The one token this cannot reach is `$XRD`, which has no curve of its own.

## Can a proposal change how the platform itself works?

Only on `$CAPER`. An **UPGRADE** option names a candidate logic component, and if it wins, one call swaps the platform logic for _every_ caper at once. The contract enforces both halves of that restriction rather than leaving it to convention: an UPGRADE option is rejected unless the proposal is executive, and rejected again unless the caper putting it up is `$CAPER` itself. Individual capers govern their own treasuries; they do not each run their own version of the protocol.

The upside of that arrangement is reach. A change confined to the logic tier – DIVEST is one – arrives at every caper that already exists, with no per-caper migration and nothing for a founder to opt into.

## Bonding curve

URL: https://caper.network/wiki/markets/bonding-curve
Updated: 2026-08-03

|  |  |
| --- | --- |
| **Type** | Perpetual AMM (continuous token model) |
| **Price** | Monotonic in circulating fraction |
| **Per-buy skim** | ⅔ XRD to founder · ⅓ tokens (30/31 founder · 1/31 Commons) |
| **Coined** | 2017 — [Simon de la Rouviere](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5) / Zap, on [Bancor](https://medium.com/@simondlr/bancors-smart-tokens-vs-token-bonding-curves-a4f0cdfd3388) |
| **Also powers** | Curation markets · continuous organizations · AMMs |
| **Related** | [Trading](/wiki/markets/trading), [Raising funds](/wiki/markets/raising-funds) |

A **bonding curve** is a smart contract that sets a token's price as a mathematical function of its circulating supply: it mints new tokens when buyers arrive and burns them when holders sell, so a market is always open without an order book or a matching counterparty. Caper uses one as the permanent, built-in market for every caper's governance token. This page covers Caper's implementation first, then the wider idea it descends from.

## Caper's curve

The curve is a perpetual AMM whose price is a smooth, monotonically increasing function of the fraction of supply in circulation. Price starts at zero with nothing sold and goes asymptotic as circulation approaches the full 100bn.

Buying moves XRD into the curve vault and tokens out of the inventory vault; selling reverses both. The cumulative XRD held by the curve has a closed-form integral, so sells price out exactly; buys solve for the new circulation numerically.

Every buy also carries a skim, paid in the curve's own composition. A curve whose price rises as the _n_-th power of supply holds `1/(n+1)` of its market value as reserve; this one is a square root at the origin, so two thirds of a young caper is reserve and one third is claim on future buyers. The skim splits along that line:

- **Two thirds** is taken in XRD off the payment, before it funds the curve, and banked for the founder.
- **One third** is a slice of the tokens that buy mints, tithed **30/31** to the founder and **1/31** to the **Caper Commons** — the protocol-wide treasury, denominated in `$CAPER`.

The token leg therefore peaks at 5% of each mint, and since it is a fixed fraction of every mint, the founder's share of the coin is the average of that fraction over the curve travelled — never above its own peak. Founder and Commons rewards scale with curve activity rather than being front-loaded. _Vampire_ capers (bound to an origin token) earn this same per-buy slice; in addition, holders of the origin token can **migrate** into the caper — a free mint that draws from the inventory vault and advances circulation without an XRD buy, with the resulting reserve gap backfilled by a fee on later direct buys. See [Trading](/wiki/markets/trading) for the buy/sell panel and [Raising funds](/wiki/markets/raising-funds) for how the proceeds are deployed.

## How bonding curves work

More generally, a bonding-curve contract holds a **reserve** (or collateral) pool of a base asset — XRD on Radix, historically ETH on Ethereum — and issues its own token against it:

- **Buying / minting.** A buyer deposits reserve assets; the contract mints new tokens, adds the deposit to the reserve, and the spot price rises because supply has increased.
- **Selling / burning.** A seller returns tokens; the contract burns them, releases the corresponding reserve, and the spot price falls.

The result is what [Yos Riady](https://yos.io/2018/11/10/bonding-curves/) calls a _continuous token_: it has a **deterministic price** (set by the formula, not negotiation), a **continuous price** (token `n+1` always costs more than token `n`), and **instant liquidity** (any amount can be bought or sold at any time). Deposited funds stay locked in the contract, so the token is always backed by collateral that can be reclaimed by burning — the same property that lets every caper holder [cash out](/wiki/markets/trading) at any time.

## The mathematics

Two quantities are easy to confuse. The **bonding curve** itself, `P(S)`, gives the _spot price_ of the next token at supply `S`. The **reserve** held by the contract — and therefore the cost of a finite purchase — is the _area under that curve_, its integral. As [Slava Balasanov](https://medium.com/relevant-community/how-to-make-bonding-curves-for-continuous-token-models-3784653f8b17) illustrates with a simple quadratic curve:

```
spot price:    P(S) = S²
reserve:       R(S) = ∫₀ˢ P(s) ds = ⅓ · S³
cost to mint:  ΔR = ⅓·(S + n)³ − ⅓·S³   (to add n new tokens)
```

Because a buyer pays the integral rather than the final spot price, a large order pays a progressively higher _average_ price as it climbs the curve. Each curve therefore has a characteristic **reserve ratio** — the share of the token's notional market capitalisation actually held as collateral:

```
reserveRatio = reserveBalance / (price × supply)
```

A linear curve `P(S) = m·S` has a reserve ratio of ½; the quadratic curve above has ⅓. The [Bancor protocol](https://medium.com/@simondlr/bancors-smart-tokens-vs-token-bonding-curves-a4f0cdfd3388) generalises this by holding the reserve ratio (its "connector weight") constant, giving the widely reused [Bancor formula](https://github.com/aragon/fundraising/blob/master/docs/components/bonding-curve.md):

```
price          = reserveBalance / (supply × reserveRatio)

purchaseReturn = supply × ((1 + reserveAdded / reserveBalance) ^ reserveRatio − 1)

saleReturn     = reserveBalance × (1 − (1 − tokensSold / supply) ^ (1 / reserveRatio))
```

A reserve ratio between 0% and 100% tunes the curve's steepness: 100% gives a flat, fully-collateralised price (a stable peg), while smaller ratios produce steeper curves that reward early buyers more. Caper's curve, `P(s) = K · √s / (1 − s)` in the circulating fraction `s`, is a steep variant: the price is zero at genesis (so there is no sniper floor) and rises to a pole as the float approaches the full supply.

## Curve shapes

The choice of function shapes a token's incentives. Common forms, catalogued by [BonDeFi](https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) and [others](https://yos.io/2018/11/10/bonding-curves/), include:

- **Linear** — `P = m·S + b`. Constant-rate price growth; simple and predictable.
- **Polynomial / quadratic** — e.g. `P = S²`. Faster appreciation that rewards early participants.
- **Exponential** — `P = a·e^(b·S)`. Steep, speculative growth.
- **Sigmoid / logarithmic** — S-shaped or flattening curves that model adoption slowing as supply matures, damping late-stage volatility.

A contract may also use **separate buy and sell curves**; the gap between them forms a bid–ask _spread_ that can fund the protocol or reward long-term holders. Caper instead uses a single curve in both directions — a flat trade fee, not a curve spread, funds each caper's treasury.

Choosing a curve's exponents and constants is a parametrization problem in its own right — see [Bonding Curves In Depth: Intuition & Parametrization](https://medium.com/relevant-community/bonding-curves-in-depth-intuition-parametrization-d3905a681e0a) and [On Single Bonding Curves for Continuous Token Models](https://medium.com/thoughtchains/on-single-bonding-curves-for-continuous-token-models-a167f5ffef89) for the design trade-offs.

## History

The continuous-token idea entered crypto with the [Bancor protocol](https://medium.com/@simondlr/bancors-smart-tokens-vs-token-bonding-curves-a4f0cdfd3388) (2017), whose "smart tokens" used a constant reserve ratio to stay continuously convertible into their reserve. Later that year [Simon de la Rouviere](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5) published _"Tokens 2.0: Curved Token Bonding in Curation Markets"_ (21 November 2017), framing curved bonding as the pricing engine for **curation markets** — markets that "reduce information asymmetry through the use of tokenized signals." He credits the Zap team with coining the term "bonding curves."

In 2018 [Thibauld Favre](https://hackernoon.com/introducing-continuous-organizations-22ad9d1f63b7) introduced **Continuous Organizations**, using a _Decentralized Autonomous Trust_ (DAT) and a bonding curve to mint and burn "FAIR" tokens that represent claims on an organisation's future cash flows — giving projects continuous fundraising and guaranteed liquidity instead of a one-off sale. Caper is a direct descendant of this model: an organisation whose token lives on a permanent curve. Around 2019–2020 the [Commons Stack](https://commonsstack.org/), with research firm BlockScience, generalised the design into the [augmented bonding curve](https://blog.giveth.io/deep-dive-augmented-bonding-curves-3f1f7c1fa751), which diverts a share of every purchase into a "common pool" to fund public goods — the same shape as Caper's 1/31 Caper Commons slice. The underlying theory frames a bonding curve as an economic estimator of a token's value ([Zargham, Paruch & Shorish](https://epub.wu.ac.at/7433/1/zargham_paruch_shorish.pdf)).

## Relationship to automated market makers

Bonding curves and automated market makers (AMMs) are close cousins. A single-reserve bonding curve is effectively a one-sided AMM that mints and burns the token itself, whereas a constant-function AMM such as [Uniswap](https://docs.uniswap.org/concepts/protocol/concentrated-liquidity) prices two pre-existing assets against each other along an invariant — the constant-product rule `x · y = k`. Bancor's `price = reserveBalance / (supply × reserveRatio)` is the bonding-curve generalisation of that idea.

A common claim is that bonding curves have "zero slippage." That is imprecise. Because a purchase pays the _area under the curve_ between the old and new supply, a large order still pays a progressively higher average price — a price impact functionally like slippage, which is exactly why Caper's [Trading](/wiki/markets/trading) guide notes that "slippage is implicit in the curve shape." The genuine distinction is that this impact is **fully deterministic**: it depends only on the trade size and the fixed curve, not on the fluctuating ratio of two pooled assets, and the curve can never run out of the token it mints. Liquidity is always available and its price impact is knowable in advance — but it is not literally free of price impact.

## Applications

- **Automated market making.** Continuous, reserve-backed pricing underpins [Bancor's smart tokens](https://medium.com/@simondlr/bancors-smart-tokens-vs-token-bonding-curves-a4f0cdfd3388) and the broader family of on-chain AMMs.
- **Curation markets.** Bonding curves let participants stake on the quality or relevance of information, rewarding early curators as a signal gains support ([de la Rouviere](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5)).
- **Continuous organizations & DAOs.** A curve becomes a permanent primary market for a [governance or revenue token](/wiki/dao-governance/concepts/treasury/dao-tokenomics), replacing fixed sales with [continuous fundraising and guaranteed exit liquidity](https://hackernoon.com/introducing-continuous-organizations-22ad9d1f63b7) — the pattern Caper is built on.
- **Public-goods funding.** [Augmented bonding curves](https://blog.giveth.io/deep-dive-augmented-bonding-curves-3f1f7c1fa751) route part of each buy into a common pool, turning token demand into a funding stream for open-source and charitable work.
- **Token launchpads.** On Radix, [BonDeFi](https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) uses a batched bonding curve to launch tokens fairly; on Solana, [Pump.fun](https://www.solflare.com/ecosystem/pump-fun-where-memes-meet-markets-on-solana/) popularised the "fair launch," pricing a token up the curve as buyers arrive before migrating it to a DEX.

## Risks and criticisms

- **Front-running / MEV.** Because price depends only on supply, an adversary who sees a pending buy can buy first and sell into it. Both [Balasanov](https://medium.com/relevant-community/how-to-make-bonding-curves-for-continuous-token-models-3784653f8b17) and [Riady](https://yos.io/2018/11/10/bonding-curves/) flag bonding curves as "susceptible to front-running attacks"; batched curves and ordering protections aim to mitigate it.
- **Reflexivity and volatility.** Tying price to supply creates a feedback loop — buying raises the price, which attracts more buying. Steep curves amplify this into pump-and-dump dynamics where a rush to exit can collapse the price as fast as it rose.
- **Market cap is not collateral.** Because the reserve is the area under the curve, a token's notional market capitalisation (`price × supply`) is typically several times the reserve backing it. Every holder can still redeem along the curve, but the headline "value" is reflexive and can [evaporate under mass selling](/wiki/dao-governance/concepts/analysis/how-daos-fail).
- **Parameter and composition risk.** The wrong curve shape or reserve ratio can make a token too volatile or too illiquid, and [deeply nested curves](https://medium.com/relevant-community/how-to-make-bonding-curves-for-continuous-token-models-3784653f8b17) (a curve collateralised by another curved token) compound reserve ratios and magnify risk.

## Further reading

- [Tokens 2.0: Curved Token Bonding in Curation Markets — Simon de la Rouviere](https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5)
- [How to Make Bonding Curves for Continuous Token Models — Slava Balasanov](https://medium.com/relevant-community/how-to-make-bonding-curves-for-continuous-token-models-3784653f8b17)
- [Bonding Curves Explained — Yos Riady](https://yos.io/2018/11/10/bonding-curves/)
- [Bonding Curve component docs — Aragon Fundraising](https://github.com/aragon/fundraising/blob/master/docs/components/bonding-curve.md)
- [Introducing Continuous Organizations — Thibauld Favre](https://hackernoon.com/introducing-continuous-organizations-22ad9d1f63b7)
- [Deep Dive: Augmented Bonding Curves — Commons Stack / Giveth](https://blog.giveth.io/deep-dive-augmented-bonding-curves-3f1f7c1fa751)
- [Bonding Curves & Anti-Snipe — BonDeFi](https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)
- [Bonding Curves In Depth: Intuition & Parametrization — Relevant Community](https://medium.com/relevant-community/bonding-curves-in-depth-intuition-parametrization-d3905a681e0a)
- [On Single Bonding Curves for Continuous Token Models — thoughtchains](https://medium.com/thoughtchains/on-single-bonding-curves-for-continuous-token-models-a167f5ffef89)
- [Economic Games as Estimators — Zargham, Paruch & Shorish (BlockScience)](https://epub.wu.ac.at/7433/1/zargham_paruch_shorish.pdf)

## Caper’s bonding curve

Every caper’s token trades against its own bonding curve: the price is a formula of how much supply has sold, so there is always a live market and never a need for a counterparty. The reserve backs every token in circulation.

CAPER PROTOCOLThe bonding curvePRICE = SUPPLYprice P(s) = K · √s / (1 − s)      s = supply sold / cap0%25%50%75%100%cap = 100bnBUY → price rises← SELL price fallssupply sold (% of cap)price / tokenA PRICE FORMULA, NOT AN ORDER BOOKBuy — send XRD; the curve mints new tokens andthe price ticks up.Sell — return tokens; the curve pays XRD from itsreserve and the price ticks down.Reserve — always covers the circulating supply — younever need a counterparty.Cap — as supply nears 100bn the price curvestoward infinity.CURVE CONSTANT K0.001SUPPLY CAP100,000,000,000TRADE FEE0.5%Every caper trades against its own bonding curve.caper.networkPrice rises as supply sells; the reserve always covers the circulating supply.

## What you actually pay

The curve sets the base price; the founder reward skims a share of every buy. The skim bites in two places – two thirds off the XRD before it reaches the curve, one third off the tokens the curve mints – and both shrink what you end up holding per XRD spent. That _share_ is front-loaded: 15% at the first buy, tapering straight to zero by 30% sold, so as a markup on the price you pay it starts near 17.5% and fades to the 0.5% trade fee. The reward's _value_ reads the other way: because price starts near zero, the founder's actual take is a hump that is near zero at launch and peaks around 11% sold, scaling with activity rather than being front-loaded. Either way the price you pay only ever rises, so the earliest buy is always the cheapest.

CAPER PROTOCOLWhat you actually payEFFECTIVE PRICEwhat you pay  =  P(s)  ÷  ( 1 − fee )( 1 − ⅔c )( 1 − ⅓c )0%10%20%30%40%50%skim → 0skim peaks ~11% soldwhat you paycurve price P(s)the gap = founder skimsupply sold (% of cap)price / tokenFRONT-LOADED RATE, HUMPED TAKEThe share is front-loaded15% of each buy at launch, tapering tozero by 30% sold. Two thirds comes off theXRD, one third off the tokens – about a17.5% markup at the first buy.The take is notPrice starts near zero, so a large shareof nearly nothing is nearly nothing. Thetake humps, peaking near 11% sold.Still cheapest earlyEither way your price only rises: thecurve climbs faster than the skim fades,so the earliest buy is the cheapest.MARKUP AT LAUNCH+17.5%FOUNDER’S TAKE PEAKS~11% soldBOTH GONE BY30% soldProtocol defaults: 15% founder skim tapering to zero by 30% sold – paid ⅔ in XRD, ⅓ in the coin – plus a 0.5% trade fee.caper.networkThe skim's share is front-loaded (15% at launch, zero by 30% sold) and paid ⅔ in XRD, ⅓ in the coin; its value is a hump peaking near 11% sold. The price you pay rises throughout – earliest is cheapest.

## Raising funds

URL: https://caper.network/wiki/markets/raising-funds
Updated: 2026-08-10

|  |  |
| --- | --- |
| **Topic** | Fundraising |
| **Inflow** | Bonding-curve buys · founder slice · trade & governance fees · direct payments to the treasury account |
| **Deploy via** | PAYOUT · INVEST · DIVEST · VOTE proposals |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve), [Trading](/wiki/markets/trading), [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management) |

A caper is a fundraising vehicle as much as a governance one. Launching one costs a single transaction — and from that moment your project can take in money from anyone, anywhere. There are two sides to the flow of capital:

- **Raising.** Every buy on your [bonding curve](/wiki/markets/bonding-curve) moves XRD in and tokens out to the buyer. A slice of each buy accrues to you, the founder, paid in the curve's own composition — two thirds in **XRD** off the payment, one third as a slice of the tokens that buy mints. Both land in badge-gated vaults you can withdraw from at any time, so your stake grows with demand instead of being fixed up front. Trade and governance fees flow into your caper's treasury.
- **Deploying.** Treasury capital doesn't sit idle. Holders pass proposals to spend it — **PAYOUT** sends XRD or tokens to a contributor, vendor, or cause; **INVEST** buys into another caper's curve and books the position back into your treasury; **DIVEST** sells that position back into the same curve and books the XRD, so a treasury can unwind a holding by the same vote that acquired it.

Because the curve guarantees a market in both directions, there is always someone to raise from and a way for backers to exit.

## The founder slice

Unlike a fixed founder allocation minted up front, a caper pays its founder out of curve activity. On each buy the protocol takes a **collateralization slice** sized by the curve's position, and splits it in the same proportions the curve itself is made of.

A bonding curve whose price rises as the _n_-th power of supply holds exactly `1/(n+1)` of its market value as reserve. Caper's price is a square root of circulation at the origin, so _n_ = ½ and the reserve fraction is **two thirds**: two thirds of a young caper's worth is XRD in the vault, one third is claim on buyers yet to arrive. The skim follows that line. **Two thirds is skimmed in XRD** off the payment before it funds the curve; **one third is a slice of the tokens that buy mints**, tithed **30/31** to the founder and **1/31** to the protocol-wide `$CAPER` treasury (the "Commons"). Both founder legs sit in badge-gated vaults you can withdraw from at any time.

Nothing about that ratio was chosen, and the founder's ceiling falls out of it. The token leg peaks at `15% × ⅓ = 5%` of each mint, and because the slice is a fixed fraction of every mint, the founder's share of the coin is just the average of that fraction across the curve travelled — which cannot exceed its own peak. So the skim never grants a founder more than **5% of their own coin**, on any path, with no vesting schedule or cliff enforcing it. The realised share starts just under 5% and decays as the caper grows: about 4% at a tenth of supply sold, under 1% near the top of the curve. (That bounds what the skim hands over, not what a founder may hold — they can buy on the curve like anyone else.)

Crucially the slice is _front-loaded, not perpetual_: it tapers linearly from its configured peak at genesis down to **zero once ~30% of the supply is in circulation**. Past that point every buy is slice-free — the curve is the buyer's only counterparty and neither founder nor protocol takes any further cut. This rewards the founder for the risky early bootstrap without imposing a permanent tax on a mature, liquid token. For _vampire_ capers bound to an origin token the founder still earns this same per-buy slice; what differs is that holders of the origin token can **migrate** into the caper — a free mint that advances circulation without an XRD buy, with the resulting reserve gap backfilled by a fee on subsequent direct buys.

## The two fee legs

Capers charge a flat **0.5% trade fee**, but the two legs land in different places — a distinction worth understanding:

- **Buy-leg fee → your treasury.** The 0.5% taken off each incoming XRD payment is deposited straight into _your caper's own_ treasury, alongside the **proposal fee** and **vote fee** members pay to create proposals and vote. Those two are configured fields rather than protocol constants — they start at **500 XRD** and **100 XRD**, and an admin rewrites them alongside the trade fee in a single `update_fees` call, so treat the figures as the current schedule (see the [FAQ](/wiki/help/faq)).
- **Sell-leg fee → the base `$XRD` caper.** The 0.5% taken when someone sells back into the curve doesn't touch your caper — it accrues to the treasury of the protocol's root `$XRD` caper (the base caper native-XRD holders migrate into), where its members claim it on the same participation-weighted terms as any other caper: each [exit](/wiki/governance/execution) pays the canonical vote weight `(t·v)/(V·T)`, so a holder who never voted claims nothing, and no one takes a flat pro-rata slice. So a caper earns from the buy-side demand it attracts, while sell-side churn flows out to the wider XRD holder base — distinct from the `$CAPER` commons, which is funded by the 1/31 founder-slice above.

The result is a treasury that grows with genuine buy-side interest and governance activity, deployed only by [vote](/wiki/dao-governance/concepts/fundamentals/dao-governance-models). For how the broader industry stewards what it raises — diversification, runway, and custody — see [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## Money that never touches the curve

A caper's treasury is not a vault buried inside the contract. It is a [native Radix Account](https://docs.radixdlt.com/docs/account), created in the same launch transaction and owned by the treasury component itself — so no external party, founder included, holds the keys to it. The component around it is a thin gate: depositing is public, while withdrawing, transferring, paying an exit and casting the caper's vote elsewhere are each restricted to a treasury admin badge that never leaves the caper's own custody.

That asymmetry is the part worth planning around. **Anyone can pay a caper directly.** A freshly created account accepts deposits by default, so the treasury address takes XRD or any other token from a customer, a grant programme, a partner protocol, another caper's PAYOUT, or a plain wallet transfer — none of it routed through the [bonding curve](/wiki/markets/bonding-curve), none of it needing a proposal, and none of it minting a single token. Curve buys and fee legs are the inflows that arrive on their own; they are not the only ones a project can raise on. Revenue, donations and off-chain-negotiated funding all land the same way an ordinary payment does.

Because the vessel is a real account rather than a bespoke escrow, its address drops into ordinary Radix tooling without adaptation — it is what a payer's wallet sends to, what a locker stores to, and what an executive proposal's recipient field takes. And because every outbound path is badge-gated, money leaves a treasury in exactly two ways: an [executed proposal](/wiki/governance/execution), or a member [exit](/wiki/markets/trading).

## Paying someone whose account can refuse

A PAYOUT does not deposit into its recipient. The treasury withdraws the voted amount and hands it to an [account locker](https://docs.radixdlt.com/docs/locker), asking it to try the direct deposit first. The distinction matters because on Radix an account can carry deposit rules that reject resources it has not opted into, and a plain deposit into such an account _aborts the whole transaction_. A DAO that pays grants, invoices or salaries to accounts it does not control would otherwise be one recipient's privacy setting away from an execution that cannot be completed.

Radix's own documentation frames the locker as the [fire-and-forget pattern](https://docs.radixdlt.com/docs/account-deposit-patterns) — "we'll try to send the package to your house, but if we can't, you'll have to come pick it up" — and it is the right shape for treasury spending precisely because it needs no prior coordination with the payee: no authorised-depositor badge, no allow-listing, no round trip before the vote. The payout lands straight in when the recipient accepts it, and waits in the locker to be claimed when they do not. Exits are paid through the same locker, so a departing member's claim cannot be blocked by their own deposit settings either.

## What a public front door costs

A permissionless deposit is also a permissionless way to put junk in someone's treasury, and the contract pays for that openness in two explicit places. Both are worth knowing generally: they are the failure modes any treasury contract inherits the moment it lets strangers deposit and then loops over what it holds.

**Nothing on-chain iterates the holdings.** The treasury emits a one-off registration event the first time each new resource arrives, and indexers rebuild the balance sheet from that event stream plus the Gateway's view of the account. Redemption walks only the resource list its caller supplies — floored at XRD plus the caper's own token, then extended with the exiting member's own discovered holdings. The source states the reason plainly: iterating an on-chain registry would let anyone grow the per-exit loop without bound, and on the order of a hundred junk resources would push every exit past the [cost-unit ceiling](/wiki/dao-governance/concepts/analysis/proposal-execution-costs) and brick redemption permanently. Bounded-by-caller loses nothing, because the off-chain manifest already supplies the live set.

**Every exit leg rounds down to the resource's divisibility.** A fractional amount of an indivisible token makes the withdrawal panic, and one panic aborts the entire exit — for every holder, not just the one who triggered it. An attacker arms that by depositing a single unit of a divisibility-zero token. Rounding each slice down means indivisible dust is skipped rather than fatal, which is a deliberate trade: a member's claim on odd dust is forfeited so that redemption itself cannot be turned off. For how the wider industry thinks about what a treasury ends up holding and who can put things there, see [DAO treasury management](/wiki/dao-governance/concepts/treasury/dao-treasury-management).

## The one caper whose denominator is a constant

Every caper divides an exiting member's claim by its own circulating supply. The root `$XRD` caper is the exception, and the reason is a property of XRD rather than a design choice: genesis creates XRD with `track_total_supply: false`, so its on-ledger `total_supply()` returns nothing on any network. There is no float to divide by.

So `effective_circulation` substitutes a fixed **24,000,000,000** — XRD's maximum supply, being the [12bn minted at genesis plus roughly 12bn released as network emissions over about 40 years](https://learn.radixdlt.com/article/what-is-the-xrd-token). The invariant that matters is that the denominator must be at least the sum of every member's holdings, because that is what keeps the sum of all exit shares inside the treasury. The 24bn cap is the tightest constant that always satisfies it, since no set of members can ever hold more.

Erring high has two consequences worth knowing if you hold `$XRD`. Claims on the pooled sell-leg fees are _conservative_ — divided by the cap rather than by the live float, so an exit pays less than a float-based split would and the treasury cannot be over-drawn. And the constant cannot distort governance: the denominator cancels out of the settle path's `top_weight / total_weight` ratio, so it moves how fast the treasury pays out and never which option wins. Both properties are read off `effective_circulation` and `exit` in `contracts/logic/src/lib.rs`.

## Launching a caper

One transaction mints the token, treasury, and bonding curve and hands the founder a badge. The only cost is a registration fee that scales with how short — how rare — the ticker is, and it can start fresh or migrate an existing token.

CAPER PROTOCOLLaunching a caperONE TRANSACTIONONE TRANSACTION CREATES EVERYTHINGTokenTreasuryBonding curveFounder badgeCHOOSE A TICKER — SHORTER IS RARER6 characters10  XRD5 characters100  XRD4 characters1,000  XRD3 characters10,000  XRD2 characters100,000  XRD1 character1,000,000  XRDPaid to the $CAPER treasury.FRESH CAPERThe curve starts empty. Buyers mint the veryfirst tokens, and the founder earns thetapering reward.VAMPIRE CAPERMigrate an existing token into your caper at afixed ratio = cap / origin supply, so 100% ofit can move over.Anyone can launch a caper in a single click.caper.networkOne transaction · ticker-length pricing · fresh or vampire.

## Trading

URL: https://caper.network/wiki/markets/trading
Updated: 2026-08-11

|  |  |
| --- | --- |
| **Action** | Buy / sell / swap on the curve · treasury divest by proposal |
| **Venue** | Each caper's profile page |
| **Liquidity** | Permanent inventory vault |
| **Sell fee** | 0.5% to the base `$XRD` caper |
| **Minimum buy** | 0.001 `XRD` |
| **Pricing** | Sell: closed form · Buy: 16-step Newton solve |
| **Swap cost** | Both fee legs, compounded (≈0.9975%) |
| **Related** | [Bonding curve](/wiki/markets/bonding-curve), [Raising funds](/wiki/markets/raising-funds) |

Each caper's profile page has a buy/sell panel against the [curve](/wiki/markets/bonding-curve). Slippage is implicit in the curve shape: every trade nudges circulation along the price curve, so large trades pay (or receive) progressively worse marginal prices the further they push toward fully sold. The **Max** button computes the exact gateway-decimal string for your full balance, so rounding matches what the ledger accepts.

The curve vault is permanent — tokens you sell return to the inventory vault and become available to the next buyer. There is no external liquidity provider and no separate AMM pool.

## How a trade moves the vaults

Every caper holds two vaults behind its curve. A **buy** moves your XRD into the _curve vault_ (the reserve that backs the token) and hands you tokens out of the _inventory vault_. A **sell** reverses both: your tokens go back into the inventory vault, and the curve vault pays you the XRD the [curve's closed-form integral](/wiki/markets/bonding-curve) says you're owed at the current circulation. Because there is a single curve in both directions — no separate buy and sell curve, no bid–ask spread — the price you sell at is exactly the price the next buyer would have paid to reach that point. Selling pays a flat **0.5% trade fee** to the base `$XRD` caper's treasury, which its own members claim at the canonical vote weight on [exit](/wiki/governance/execution) rather than as a flat pro-rata split (and against a [fixed 24bn denominator](/wiki/markets/raising-funds), since XRD's supply cannot be read on-ledger); buying pays its own 0.5% into the caper you buy (see [Raising funds](/wiki/markets/raising-funds)).

## The two directions are not symmetric

The curve's cumulative-reserve function `X(s) = K·N·[ln((1+√s)/(1−√s)) − 2√s]` has a closed form, so a **sell** prices out exactly: the payout is `X(s_before) − X(s_after)`, two evaluations and a subtraction, with no approximation in it anywhere. A **buy** is the inverse problem — given an amount of XRD, find the circulation that consumes it — and that inverse has no closed form. The contract solves it numerically instead, with a Newton iteration capped at **16 steps** against a tolerance of **0.0000001 XRD**.

The convergence test is deliberately one-sided. The loop breaks only when the residual sits at or below zero and no further from it than the tolerance, so an accepted answer always consumes slightly _less_ XRD than was paid, never more. Rounding falls to the curve rather than the buyer, and a mint can come up short but cannot run over.

That asymmetry is not a rounding footnote — it has already produced a real defect. Newton's method on a convex function approaches the root from above, and the seed the solver starts from lands far above the true answer for a small payment on a mature curve: at half the supply sold, a 100 XRD buy seeds at `s ≈ 0.649` against a true `s ≈ 0.5000007`. In that region the one-sided break can never fire, so the iteration has to reach the root inside its 16 steps or stop early and over-mint. An earlier version damped every step to at most one halving toward the domain floor, which was slow enough to exhaust the budget while still above the root. The damping was replaced with a hard floor, and the case is now pinned by a regression test named for it, `tokens_bought_converges_for_small_payments_on_mature_curve`, sweeping four circulation levels against payments from 0.01 to 10,000 XRD.

## A round trip cannot pay out more than it took in

Because a single curve serves both directions, buying and immediately selling the same tokens returns the curve to exactly the point it started from. The question that matters for a numerically-solved buy is whether that round trip can ever hand back more XRD than it consumed. It cannot, and the contract pins it rather than assuming it: `roundtrip_buy_then_sell_does_not_overshoot` buys at four circulation levels, sells the same tokens straight back, and asserts the signed difference never exceeds **0.000001 XRD** of dust in the seller's favour.

That bound holds _before_ the trade fee, which then takes its 0.5% off the payout, so a real round trip always ends down. An instant buy-and-sell is the cheapest probe anyone can run at a solver that approximates in one direction, and the guarantee is that it extracts nothing.

## Swapping and exiting

Two variants build on the same primitive. A **swap** sells one caper's token and buys another in a single transaction — you never touch XRD in between — letting you rotate a position from one caper to another directly. And beyond selling on the curve, holders have a second way out: the [exit right](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) lets you burn your tokens to redeem a participation-weighted share of the caper's _treasury_, sized by the same [vote weight](/wiki/governance/voting) (t·v)/(V·T) that governs a ballot and consuming both your governance tokens and your vote tokens — a claim on the accumulated fees and investments, separate from the curve reserve. Between the curve and the exit, a caper holder is never locked in: there is always a price to sell at and always a floor to redeem against.

## What a swap actually costs

A swap looks like one action and is priced as two. The contract sells your tokens against the origin caper's curve, takes the sell-leg fee out of the proceeds, then hands the _net_ XRD into a buy on the destination caper's curve — which charges its own fee off that amount as gross. Both legs fire, in different directions and into different treasuries:

- **Sell leg, 0.5%** — out of the XRD the origin curve pays, into the root `$XRD` caper's treasury.
- **Buy leg, 0.5%** — off the XRD arriving at the destination curve, into _that_ caper's own treasury.

Because the second fee is charged on what the first left behind, the two compound rather than add: the combined bite is `1 − 0.995² ≈ 0.9975%`, not 0.5%. On top of that you walk two curves, down the origin's and up the destination's, and on a young destination caper the [founder slice](/wiki/markets/raising-funds) applies to the buy leg exactly as it would to a direct purchase. A swap saves you holding XRD in between and a second signature; it is a convenience, not a discount.

## A sale nobody placed

Not every sale on a caper's feed comes from a holder. A caper's treasury can hold _other_ capers' tokens — an [INVEST proposal](/wiki/governance/proposals) buys them on the target's curve — and a **DIVEST** proposal runs that trade backwards. [Execution](/wiki/governance/execution) withdraws the voted-on amount of the target's token from this treasury, sells it into that caper's curve, and deposits the XRD back into this treasury, entirely inside the contract's own call frame, so the tokens never reach the worktop for an executor to skim.

From the receiving curve's side it is an ordinary sale in every observable respect: the same single curve, the same closed-form payout, the same flat **0.5% sell-leg fee** into the root `$XRD` caper's treasury, and the same `SellToken` event on the trade feed carrying no divest-specific field. A holder watching the chart cannot tell one from a retail exit — the identifying record is the `ProposalExecutedDivest` event on the _selling_ caper, not anything on the curve that absorbed the sale. Price impact is likewise unexceptional: a divest walks the curve down exactly as a same-size holder sale would.

Two guards matter to anyone pricing around it. The trade is **frozen at settlement** — execution withdraws exactly the amount the winning option named, and aborts outright if the treasury's holding has fallen below it since, because filling a smaller trade than the one that passed would break the frozen-winner contract. And `$XRD` is refused by name as a divest target, for the same reason it cannot be sold at all: it has no curve to sell into.

Read off `execute_proposal_divest` and `sell_token_raw` in `contracts/logic/src/lib.rs`, and `treasury_withdraw` / `treasury_deposit` on the state tier.

## The one caper you cannot trade

The protocol's root `$XRD` caper — the one native XRD holders migrate into, and the one that collects every sell-leg fee in the system — has no bonding curve at all. All three trading entry points refuse it by name rather than failing incidentally: a buy is told to use migration instead, a sell is refused because governance tokens are non-salable, and a swap rejects `$XRD` as either side of the pair.

So the members whose treasury accrues the sell-side churn of every other caper have no curve to sell on themselves. The way in is [migration](/wiki/markets/raising-funds) from native XRD; the way out is the [exit](/wiki/governance/execution), which redeems a treasury share at the canonical [vote weight](/wiki/governance/voting) `(t·v)/(V·T)`. It is the same reason `$XRD` is the one caper whose exit divides by a [fixed 24bn constant](/wiki/markets/raising-funds) rather than a live float: XRD's on-ledger supply is untracked, and there is no curve to read a circulation off.

Everything above is read off `buy_token_raw`, `sell_token_raw`, `swap`, `compute_tokens_bought_inner` and `compute_xrd_received` in `contracts/logic/src/lib.rs`, and the vault and solvency invariants off `buy_apply` and `sell_apply` in `contracts/core/src/caper_dao.rs`.

## Price impact, and how it compares to an AMM

A caper's price is a deterministic function of how many tokens are in circulation, so the cost of a trade is knowable _before_ you sign it rather than discovered on execution — exactly for a sell, which prices off the [curve's closed-form integral](/wiki/markets/bonding-curve), and to within 0.0000001 XRD for a buy, which inverts that same integral numerically (see _The two directions are not symmetric_ above). That is a different liquidity model from a constant-product [AMM](/wiki/daos/dexs/uniswap-dao) such as Uniswap, where price emerges from a [reserve ratio (x·y=k)](https://docs.uniswap.org/contracts/v2/concepts/protocol-overview/how-uniswap-works) maintained by external liquidity providers. Three practical consequences follow:

- **No liquidity to pull.** The curve reserve is a permanent inventory vault owned by the caper, not third-party LP deposits that can be withdrawn — so depth never vanishes and there is no [impermanent-loss](https://docs.uniswap.org/concepts/protocol/fees) risk borne by outside providers.
- **No bid–ask spread.** A single curve serves both directions, so the price you sell at is exactly the price the next buyer pays to reach that point — the only wedge is the flat 0.5% [trade fee](/wiki/markets/raising-funds), not a market-maker's spread.
- **Predictable slippage.** Large orders still walk the curve and pay progressively worse marginal prices, but that impact is a fixed property of the curve shape rather than a function of who happens to be providing liquidity that block.

The comparison runs deeper than price impact. A constant-product pool quotes from a closed-form formula, a Curve or Balancer pool cannot, and a caper's buy side cannot either – so all three reach for a different numerical method to produce a number a trader can sign. [Numerical pricing in AMMs and bonding curves](/wiki/economics/numerical-pricing) reads those methods out of the deployed source of each.

## Trading & exit

Value moves through a caper across two distinct pools: the bonding-curve reserve that buys and sells tokens, and the treasury you redeem when you exit. The diagram traces the flows a holder drives directly — buy, sell, swap, exit. A caper's treasury also trades on _other_ capers' curves, but only by proposal (see _A sale nobody placed_ below).

CAPER PROTOCOLTrading & exit4 ACTIONSFOUR WAYS VALUE MOVESBUYXRD  →  tokensThe curve mints new tokens at the currentprice.0.5% fee → this caperSELLtokens  →  XRDThe curve buys them back from its reserve.0.5% fee → $XRDSWAPcaper A  →  caper BSell one caper and buy another in a singletransaction.both fee legs applyEXITvotes + tokens  →  treasury shareBurn your soulbound vote record and redeemyour slice of the treasury.share = (t·v) / (V·T)Two different pools · SELL redeems the bonding-curve reserve · EXIT redeems the treasury.Buy, sell, swap, or exit — all on-chain.caper.networkBuy, sell, swap on the curve · exit redeems the treasury.

## Freshness

URL: https://caper.network/wiki/policy/freshness
Updated: 2026-07-18

**Freshness** is the Caper wiki's on-chain extension of verifiability. Facts about a fast-moving ecosystem decay quickly, so a claim sourced correctly a year ago may now be wrong.[[1]](#ref-1) Factual pages should record when they were last checked and be re-verified against the live ledger.

## Keeping pages current

Set a _Last Verified_ date when you confirm a page's facts, and add a _May be outdated_ notice banner rather than leaving stale errors in place. Where a page states an on-chain value, prefer a derived block (timeline, grants ledger, funding graph) that re-resolves from the ledger[[2]](#ref-2) — the maintenance sweep flags pages whose prose has drifted from the chain.

### References

1. Wikipedia — _Wikipedia:As of_ — https://en.wikipedia.org/wiki/Wikipedia:As_of
2. DAOstar — _EIP-4824: Common Interfaces for DAOs_ — https://eips.ethereum.org/EIPS/eip-4824

## Neutral Point of View

URL: https://caper.network/wiki/policy/neutral-point-of-view
Updated: 2026-07-18

**Neutral point of view** (NPOV) means representing a subject fairly, proportionately, and without editorial bias.[[1]](#ref-1) Facts are stated as facts; opinions are attributed to whoever holds them.

## A caper's own page

NPOV matters most on a caper's company page, where the project's own members may be editing — a structural conflict of interest. Such pages must avoid promotional language, attribute claims about traction or returns to sources, and carry a _Conflict of interest_ notice when written by the subject. The on-chain blocks help here: a [verified funding graph](/wiki/policy/verifiability) states what actually happened, not what a team wishes to project.

### References

1. Wikipedia — _Wikipedia:Neutral point of view_ — https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view

## No Original Research

URL: https://caper.network/wiki/policy/no-original-research
Updated: 2026-07-18

Articles must not present **original research** — unpublished analysis, speculation, or conclusions no reliable source has stated.[[1]](#ref-1) Every interpretive claim should be attributable to a published source.

## Reporting on-chain data

Reading and reporting a value from the ledger (a treasury balance, a vote result, an executed payout) is description, not original research, and is encouraged. Extrapolating from it — predicting a token's price or inferring intent — is original research and belongs in commentary, not an encyclopedic article.

### References

1. Wikipedia — _Wikipedia:No original research_ — https://en.wikipedia.org/wiki/Wikipedia:No_original_research

## Notability

URL: https://caper.network/wiki/policy/notability
Updated: 2026-07-18

**Notability** is the test of whether a subject merits its own article. A topic is presumed notable if it has received significant, independent coverage or plays a material role in the on-chain DAO ecosystem.[[1]](#ref-1)

## Guidelines by type

**Organizations** should be live on-chain with a public product or treasury. **People** should be recognised contributors or founders. **Concepts** should be established terms with published sources. Subjects that do not yet meet the bar can be listed within a broader page rather than given a standalone article.

### References

1. Wikipedia — _Wikipedia:Notability_ — https://en.wikipedia.org/wiki/Wikipedia:Notability

## Verifiability

URL: https://caper.network/wiki/policy/verifiability
Updated: 2026-07-18

**Verifiability** is the first standard on the Caper wiki: the threshold for including material is whether readers can check it against a reliable, published source — not whether an editor believes it is true.[[1]](#ref-1) Any statement likely to be challenged, and every quotation, should carry an inline citation.

## Reliable sources

Prefer primary documentation, project repositories, peer-reviewed work, and the on-chain record. The ledger is itself a primary source: a caper's treasury balance, a proposal outcome, or an executed grant can be cited directly — Caper's [grants ledger and timeline blocks](/wiki/policy/no-original-research) render that record verified by construction. Marketing copy and unattributed posts are weak sources.

## Citations needed

When a claim lacks a source, mark it with a [citation needed] tag rather than deleting it, and add a _Needs citations_ notice banner so contributors and the maintenance sweep can find it.

### References

1. Wikipedia — _Wikipedia:Verifiability_ — https://en.wikipedia.org/wiki/Wikipedia:Verifiability
2. DAOstar — _EIP-4824: Common Interfaces for DAOs_ — https://eips.ethereum.org/EIPS/eip-4824