How DAOs Manage Market Making Without Selling the Treasury

A private issuer can sign a loan agreement, grant options, and disclose nothing. A DAO cannot. The treasury is on-chain, transfers are visible, and any tranche moved to a market maker will be spotted, screenshotted, and interpreted — usually as a sell. That reality shapes every part of the structure, from the compensation model to the wording of the proposal.

The second constraint is process. Selecting a provider requires a competitive review, a public rationale, and a vote. Contributors who are used to moving in a week need to plan for a cycle measured in months, which means liquidity planning must start before it is urgent.

There is also a translation problem. A treasury committee or working group typically does the actual diligence, but the full token-holder vote is where legitimacy comes from, and the two audiences read differently. Delegates want a one-paragraph summary and a number; the working group wants the underlying model. Publishing both — a plain-language summary at the top and the full analysis linked beneath — avoids the common failure mode where a sound proposal is voted down because nobody outside the committee understood it.

Token loans transfer float and grant options over treasury assets. In a private company that is a negotiated commercial trade-off. In a DAO it is a public transfer of community assets to a counterparty with an upside interest, and it invites a predictable governance fight — particularly when the strikes become visible and the market interprets them as a ceiling.

Where a loan is genuinely necessary because the treasury lacks stablecoins, keep the tranche small, the strikes high and few, the term short, and the entire structure disclosed in the proposal. Anything discovered later rather than disclosed upfront costs more in trust than it ever saved in cash.

Most protocol treasuries hold a stablecoin reserve precisely so that operating costs do not require selling the native token. Liquidity provision is an operating cost. Paying a retainer from that reserve keeps the native token in treasury, avoids options entirely, and produces a line item any contributor can audit.

It also simplifies governance: the vote is on a budget with a defined term and a defined performance schedule, not on a derivative structure that most voters will not model. Simplicity is a governance feature, not a compromise.

A liquidity proposal that passes cleanly contains: the problem stated with data, the venues in scope, the KPI schedule, the budget and term, the selection process and shortlist rationale, the reporting commitment, and the termination conditions. Publish the specification you sent providers so the community can see the process was competitive.

Include a review gate. A six-month mandate with a public performance review at month three gives voters a genuine off-ramp and gives the provider a clear standard, which tends to improve behaviour more than any contractual clause.

Many protocols hold their own AMM positions rather than renting depth. This keeps fee income in the treasury and removes counterparty risk, and for on-chain-native tokens it is often the right backbone. But it carries divergence loss, it requires active range management on concentrated designs, and it does nothing for centralised order books, where institutional flow still lives.

The mature answer is usually both: protocol-owned liquidity as the on-chain foundation, plus a measured order-book mandate wherever the token has a centralised listing that matters.

Publish monthly: spread and depth by venue, uptime, volume excluding provider activity, budget consumed, and any incidents. Where possible source the numbers from exchange sub-account data rather than the provider's dashboard, and state which method was used. Verifiability is the whole point.

Treat the reporting standard as part of provider selection. A desk that resists granular public reporting is telling you what its performance will look like in month five.

On most token-voting systems a liquidity proposal competes for delegate attention alongside grants, parameter changes, and emergency votes, so it needs to be legible on a first read. Lead with the problem in one sentence, the ask in one number, and the term in one date. Delegates voting on a dozen proposals a week reward clarity and punish anything that reads like a sales deck. A proposal that requires a call to understand has usually lost votes it did not need to lose.

Separate the governance decision from the operational detail. The on-chain vote should approve a budget ceiling, a KPI schedule, and a review date; the choice of venues, quoting bands, and specific desk belongs in a linked specification the treasury committee can update without a further vote. Bundling operational minutiae into the vote itself is the most common reason liquidity proposals stall in discussion for months rather than progressing to execution.

Where the DAO runs a Snapshot-plus-multisig pattern, state explicitly which multisig executes the mandate and under what signer threshold, and require that any material change to the approved terms — a larger tranche, an extended term, a new venue — return to governance rather than being absorbed as operational flexibility. Silent scope creep of this kind is the largest single source of later disputes over treasury liquidity spend.

A stablecoin retainer is only treasury-safe if the treasury can actually afford it for the life of the mandate. Before proposing a budget, model runway under a conservative case: current burn plus the proposed liquidity spend, held constant, against current stablecoin holdings, with no assumption of future token sales or grants converting to cash. If that runway falls below twelve months, the proposal should either shrink the mandate or pair it with a separate, explicitly disclosed treasury diversification plan.

Communities respond far better to a liquidity proposal that shows its arithmetic against runway than to one that simply states a number. Include a sensitivity line — what happens to runway if the mandate is renewed at the same size for a second term — since renewal is the default outcome most committees underestimate when they first model a pilot budget.

The tokens or stablecoins earmarked for a mandate should sit in a purpose-built multisig, separate from the general treasury, with a signer set and threshold documented in the proposal rather than decided informally afterwards. A three-of-five or four-of-seven arrangement drawn from a mix of core contributors and independent, reputationally-exposed delegates is a reasonable default; a signer set drawn entirely from one team concentrates operational and reputational risk in a way voters will eventually notice.

Define in advance what each signature authorises: routine transfers within the approved schedule should need the standard threshold, while anything outside the schedule — an early top-up, a change of counterparty, an emergency withdrawal — should require either a higher threshold or a return to governance. Publish the multisig address so the community can verify flows independently rather than relying on the committee's word for it.

Delegates, core contributors, and market makers move in a small industry, and it is common for a committee member to have a prior relationship with one of the bidding desks. That is not automatically disqualifying, but it needs to be disclosed in the proposal before the vote, not surfaced afterwards by someone checking LinkedIn. Undisclosed relationships, once found, do more damage to a mandate's legitimacy than almost any commercial term inside it.

A workable policy is to require committee members to declare relevant relationships in writing, to recuse themselves from scoring that specific bidder, and to have at least one independent reviewer — an advisor with no stake in the outcome — sign off on the shortlist before it goes to the community. This costs little and removes the single most predictable governance attack on a liquidity proposal.

Protocols deployed across several chains or rollups face a version of the vetting problem that single-chain issuers do not: liquidity spread thinly across five venues on three chains looks active but is shallow everywhere, and a provider mandate that tries to cover all of it usually ends up quoting adequately nowhere. Decide, before drafting the proposal, which one or two venues actually carry the trading activity that matters to holders, and concentrate the budget there rather than distributing it evenly for the sake of appearing comprehensive.

Where a genuinely material portion of activity sits on a second chain, treat it as a separate line item with its own KPIs and its own reporting, rather than folding it into a single blended target that obscures which venue is actually underperforming. Blended reporting is a common way for weak quoting on a secondary chain to hide behind strong numbers on the primary one.