# One ZIP for Both Taps: Fixing the Colossal Treasury Problem **URL:** \ **Category:** Governance\ **Created:** [November 15, 2026, 4:06pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325 "2026-11-15T16:06:27Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![vaspholdings](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/vaspholdings/32/30024_2.png) [@vaspholdings](https://forum.zcashcommunity.com/u/vaspholdings)\ **Post date:** [November 15, 2026, 4:06pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/1 "2026-11-15T16:06:28Z")
**TL;DR:** The current proposals ask only ZCG to give something up. That’s wrong. My draft ZIP described here applies one test to both treasuries, capped at the ‘compromise’s’ own 50,000 ZEC for ZCG and 75,000 ZEC for the CCF. Until it can be considered, I’ll be voting for the status quo (Question 4). * * * As [@zooko says](https://forum.zcashcommunity.com/t/the-zcg-lockbox-one-tap-off-the-bigger-one-left-running/59027/4), these are good problems to have to deal with. Treasuries that have grown faster than anyone planned are a sign of success. But ZEC has fallen by about a third in the past week, and it could swing just as hard either way before any of these proposals takes effect. Now the price has fallen, do we still need to worry about the colossal treasury problem? **Yes, we do.** Even at today’s price (USD 800), ZCG holds over USD 80 million, nearly ten years of its current spending. The CCF’s lockbox grows by about 79,000 ZEC a year, whatever the price, and the CCF’s treasury is now worth about USD 56 million. And ZEC was above USD 1,600 only seven weeks ago. What has fallen can rise again, and the problem will be back. Polling on the future of ZCG opens tomorrow (16th Nov). In [Two Taps](https://forum.zcashcommunity.com/t/59027) I said I know railroading when I see it. Nothing since has changed my mind. That’s about the timetable, not the people. @aquietinvestor has, as usual, run the advisory poll with grace and patience, totally in the open, and offered a runoff if it’s needed, and I’m grateful for that. The [Future Dev and Legal Defense Fund ZIP](https://github.com/zcash/zips/pull/1428) (the ‘lockbox ZIP’) is being presented by some of our leaders as their preferred solution. I don’t doubt that they genuinely believe it is the best option among the ZIPs presented so far. But it appeared only on 29th October. Comments on the ballot close today (15th Nov). Polling begins the following day. ZCG has been sentenced before the community has had time to finish examining why the current arrangements exist, let alone determine what changes would work best. And it isn’t a compromise. The Oxford dictionary defines one as an agreement “in which each side gives up some of the things they want”. Here, only ZCG gives anything up. As @Julian put it: “All four options leave the existing CCF [Coinholder-Controlled Fund] and its 12% stream unchanged.” As Icelanders say, I’ve just come from the mountains. (I’m English, but I’ve lived in Iceland long enough for some of the culture to rub off.) I couldn’t get to Zcon because the flights didn’t work out, and I have a day job, so I missed the start of this dispute and most of the noise on X. I’d spent October on a [proposal to fund new Ambassadors and emerging communities through ZecHub](https://forum.zcashcommunity.com/t/draft-proposal-zechub-communities-sub-dao-for-ambassadors-and-emerging-communities/58135), and on [helping people recover old Sprout wallets](https://forum.zcashcommunity.com/t/recover-an-old-zcash-wallet-before-the-sprout-freeze-wallet-dat-zc-addresses-and-sprout-recovery/57718) before NU7. When I posted a final Sprout warning on 3rd November, I had no idea a full-blown governance dispute was already under way. I wasn’t reading widely on the Forum or X, so I’d missed that the proposals were already written and the polls about to be scheduled. (But you can rest assured that since the post announcing the poll came out, I’ve been catching up on my reading.) Eighteen days, from the ZIP’s appearance to the start of polling, is enough time if you helped shape the proposals before they reached the Forum. It isn’t enough for everyone else to examine the arguments properly, let alone write an alternative ZIP. In this post I’ll explain my ZIP, which I’ll call **the both-taps ZIP**. It’s a genuine compromise: both programmes give up any excess in their treasuries to the NSM. It’s also a form of governance minimisation: one published rule instead of repeated fights over the money. Along the way, I’ll point out serious flaws in the lockbox ZIP. Perhaps coming to this dispute with fresh eyes is no bad thing. It’s worked before: the lockbox at the heart of today’s Dev Fund started as a proposal from Skylar Saveland of free2z, an independent developer outside the main Zcash organisations, and his idea ended up in the design the community chose in 2024. So in the spirit of the independent voices who have come before me, I’ve written an alternative. It builds on the thinking in my three governance essays: [An Ode to Rough Consensus](https://forum.zcashcommunity.com/t/an-ode-to-rough-consensus/58990), [When We Disagree](https://forum.zcashcommunity.com/t/when-we-disagree-making-rough-consensus-work/59026) and [Governance in a Shielded World](https://forum.zcashcommunity.com/t/governance-in-a-shielded-world/59256). I don’t claim it’s the last word. It’s my best attempt, and others will no doubt have ideas to improve it. That’s what the discussion part of the ZIP process is for. In [Two Taps](https://forum.zcashcommunity.com/t/59027) I said my answer was to let both streams expire in 2028, with no new mechanism, and to leave any surplus until closer to then. That’s still my first choice, and it’s why I’m voting for the status quo in the advisory poll opening tomorrow. But if the community wants to deal with the surplus now, **it should be done fairly: to both treasuries, with a test that works at any price**. This both-taps ZIP is that option. No new committee, no new lockbox, and it ends in 2028. **Disclosure:** I’m a ZCAP member standing for a ZCG seat in December. This proposed draft ZIP caps the treasury of the committee I’m standing for. ## Capping both treasuries: the both-taps ZIP [Capping the Treasuries of Zcash Community Grants and the Coinholder-Controlled Fund ZIP](https://github.com/zcash/zips/issues/1464) One test, applied to both grant programmes: - Each quarter, each programme works out what it needs: everything it has already committed to pay, plus a reserve of two years of its own spending, with a minimum. - Its spendable treasury is valued in USD at a six-month average ZEC price, building on [@valardragon’s TWAP idea](https://forum.zcashcommunity.com/t/zcg-gets-too-much-zec-heres-our-plan-to-fix-that/58566/28), or at the last week’s average if that’s lower, so a price crash in the ZEC-USD exchange rate can’t make it take too much. - Anything above what it needs goes to the NSM, up to a cap each quarter. Transfers start once the NSM can accept them, which needs ZIP 233 to be implemented. The lockbox ZIP’s 50,000 ZEC also needs a network upgrade before it can be made. - Each programme should also hold at least its approved commitments plus a year’s spending in dollars, building on ZCG’s existing hedging practice. I’ve taken the Future Dev and Legal Defense Fund ZIP’s own number, 50,000 ZEC, as ZCG’s cap, and applied the same 8:12 ratio as the two streams to the coinholder programme: 75,000 ZEC. The minimum reserves follow the same ratio: USD 25 million and USD 37.5 million. This ZIP doesn’t change how the Dev Fund is shared: ZCG still gets 8% and the CCF 12%, as ZIP 1016 sets out. **The difference: it depends on the price.** Let’s solve this in a way that works at USD 100 and at USD 5,000, not just at today’s price. A fixed number can’t do that. Here’s the first year of transfers for ZCG under each ZIP: | ZEC price | Both-taps ZIP: ZCG sends to the NSM | ZCG keeps | Lockbox ZIP: ZCG sends to the NSM | ZCG keeps | | --- | --- | --- | --- | --- | | USD 100 | nothing | about USD 15m, and its stream | 50,000 ZEC | about USD 7m, and no stream | | USD 500 | about 83,000 ZEC | about USD 27m, and its stream | 50,000 ZEC | about USD 24m, and no stream | | USD 1,000 | about 109,000 ZEC | about USD 27m, and its stream | 50,000 ZEC | about USD 47m, and no stream | | USD 1,500 | about 117,000 ZEC | about USD 27m, and its stream | 50,000 ZEC | about USD 69m, and no stream | | USD 5,000 | about 129,000 ZEC | about USD 27m, and its stream | 50,000 ZEC | about USD 224m, and no stream | **The lockbox ZIP fails at both ends.** At USD 100, it leaves ZCG with about nine months of spending and no income. At USD 5,000, it leaves ZCG with over USD 200 million, while ZCG’s 8% stream, about 52,500 ZEC a year, goes into a new lockbox: more than USD 250 million a year. **The both-taps ZIP takes nothing when ZEC is cheap, keeps trimming when it’s dear, and always leaves ZCG what it needs to keep working. The same goes for the CCF.** Some will say a lockbox is safer than a treasury held in keys. That’s a fair point: money in a lockbox has no keys to steal, and releasing it takes a network upgrade. But the both-taps ZIP sends the excess somewhere safer still: the NSM, which has no keys, and where nobody decides who gets it. It goes back to miners by formula. What stays in keys is only what each programme needs to keep paying for work, and the limit applies to both programmes, not just ZCG. That includes the coinholder programme. Its 12% stream still builds up in a protocol lockbox, so the test applies to the funds already released to its key-holders, and to each future release. On rough estimates, it would send nothing at USD 100 or USD 500, about 27,000 ZEC at USD 1,000, about 41,000 at USD 1,500 and about 61,000 at USD 5,000. Under the lockbox ZIP, it sends nothing at any price. Real figures for it are needed. _Figures assume the price holds for the year, ZCG spends about USD 8.7 million a year and the coinholder programme about USD 6 million a quarter. They’re rough, and the ZIP’s open questions include the reserve length and the cap._ What it doesn’t change: - Both streams still end in November 2028, as ZIP 1016 already says. - Neither programme’s governance or grant process changes. - Work already approved is protected. - The CCF’s lockbox isn’t touched. Any future release from it has to pass the same test. ## A question about NU7.1 One thing stood out after I caught up with my reading, that I would like an answer to. Sending ZEC to the NSM needs ZIP 248. The both-taps ZIP needs it, and @nuttycom says it would make the lockbox ZIP simpler too. Yet the timeline leaves transaction-format changes out of NU7.1. Why, and on what technical assessment? [I asked](https://forum.zcashcommunity.com/t/zcg-and-the-dev-fund-timeline-for-proposals-and-polling/58906/37) for technical changes unrelated to ZCG funding to be kept out of the current advisory poll. They belong in a separate advisory poll on technical changes after this poll: ZIP 248 and ZIP 233, and 20-second blocks too, once its ZIP is complete. By then we’ll also have this advisory poll’s signals on the current funding proposal ZIPs. Either way, NU7.1’s scope should be discussed more openly with the wider community before it’s settled. ## Why both grant programmes need limits Think of a supermarket. ZCG is the staffed till: a named cashier checks every item, and you can see who waved what through. It’s slower, there’s a queue, and now and then a cashier waves a friend’s shopping through. That’s why my [conflict-of-interest ZIP](https://github.com/zcash/zips/issues/1374) sets rules for cashiers. Retroactive grants are self-checkout: quicker and cheaper, and fine for most shoppers. But even self-checkout has limits: a basket size, and some items kept behind the counter. Nobody runs a supermarket on self-checkout alone, and nobody would let it take the whole trolley. The both-taps ZIP puts a limit on both tills. ZCG’s figures come from @Julian’s [analysis of the dashboard and FPF’s Q3 report](https://forum.zcashcommunity.com/t/zcg-and-the-dev-fund-timeline-for-proposals-and-polling/58906/122). Thank you, Julian. Comments on the ZIP are welcome here or on GitHub, especially on the reserve length, the caps, and how much to hold in USD. I’d also welcome the CCF’s real figures from its key-holders. ## How I’m voting in the current advisory poll This alternative can’t be on the current ballot. So, until it can be properly considered, I’ll be voting for the status quo: **Question 4: “Do you support maintaining ZCG’s existing funding and operations?” Support.** Under rough consensus, no change is the default anyway. Keeping ZIP 1016 as it is, for now, closes no doors. Every other funding option on the ballot does. When you vote, I’d ask you to do the same. Then let’s have the proper debate this deserves. ---
**Author:** ![dismad](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/dismad/32/18432_2.png) [@dismad](https://forum.zcashcommunity.com/u/dismad)\ **Post date:** [November 15, 2026, 4:10pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/2 "2026-11-15T16:10:29Z")
Price-dependent treasury caps introduce a capture surface that a fixed-ZEC rule avoids. The both-taps ZIP values holdings in USD via a 6-month (or 1-week) average and applies USD-denominated needs floors. That makes the amount sent to the NSM depend on an external price source and on whatever spending rate is accepted as “two years of needs.” Either can be influenced around the measurement window, or the accounting can be adjusted to retain more (or less) ZEC. Averages reduce crash risk but do not remove the dependency. A pure ZEC quantity (or simply letting both streams expire in 2028) has no such oracle or baseline. The fairness of applying the same test to both funds is worth keeping; the USD price trigger is the part that adds a new vector. Any entity that can influence, delay, or selectively report that price (exchange, oracle, data aggregator, or even coordinated trading around the measurement window) can change how much is classified as “excess.” ---
**Author:** ![vaspholdings](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/vaspholdings/32/30024_2.png) [@vaspholdings](https://forum.zcashcommunity.com/u/vaspholdings)\ **Post date:** [November 15, 2026, 4:14pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/3 "2026-11-15T16:14:38Z")
@skyl, it was good to see you back on the Forum! I’m posting here to get this in early on in the thread. I’ve been meaning to respond to your [29th October post](https://forum.zcashcommunity.com/t/zcg-gets-too-much-zec-heres-our-plan-to-fix-that/58566/69), but that thread is now closed. I’ve also read your [Fund Zcash Development Forever. Entitle Nobody.](https://free2z.cash/free2z/fund-zcash-forever-entitle-nobody) essay. I particularly appreciated your correction of the claim that “98.6% of coinholders” opposed ZSAs. It was 98.6% of participating ZEC-weighted votes. That’s an important distinction, not pedantry. And I’ve acknowledged your original lockbox proposal in my opening post here. It’s a good example of how important ideas can come from independent developers rather than established organisations. I’ve always thought we need to make room for people tinkering at the edges. Not everything they try will work, or be ready for mainstream adoption. But that’s often where good ideas begin. There’s a great deal in [your treasury argument](https://free2z.cash/free2z/fund-zcash-forever-entitle-nobody) I agree with. Zcash still has enormous work ahead of it. Development funding matters. Competition, experimentation and careful spending matter too. And no organisation should be entitled to funding indefinitely. But I think we differ on two important points. First, you argue that no development war chest can be too big by definition. I think a treasury can become too big for the responsibilities and spending capacity of the people controlling it. That’s why my ZIP protects existing commitments and substantial operating reserves, but sends any excess to the NSM. The same rule applies to both ZCG and the Coinholder-Controlled Fund. Neither gets a free pass. Second, you write: > Saying that authority should ultimately derive from ZEC holders does not mean every governance action must be a raw instantaneous token vote with no checks whatsoever. I agree with the need for checks. But I don’t think legitimate authority should ultimately derive from any single constituency. Not coinholders, not developers, miners, ZCAP or any committee. You’ve recognised the dangers of whale capture yourself, and I found your Zenate idea interesting. But if the safeguards themselves ultimately derive their authority from the same coin-weighted electorate, isn’t that still concentrating power in one place? Having capital at risk creates incentives. It doesn’t necessarily create accountability. My preference is for independent constituencies that can constrain one another, working towards rough consensus rather than establishing sovereignty over the others. We may have different answers, but I think we’re asking some of the same important questions about how Zcash funds development without creating permanent entitlements or concentrating power. I’d welcome your thoughts on this ZIP and on the wider difference in our governance philosophies. Good to have you back in the fray of governance discussion! ---
**Author:** ![vaspholdings](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/vaspholdings/32/30024_2.png) [@vaspholdings](https://forum.zcashcommunity.com/u/vaspholdings)\ **Post date:** [November 15, 2026, 4:23pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/4 "2026-11-15T16:23:30Z")
Thanks @dismad, that’s fair. I agree with the part worth keeping: the same test for both funds. Letting both streams expire in 2028 is still my first choice. **On the price** : there’s no on-chain oracle. It’s a published calculation anyone can check: the median daily close across at least three exchanges, averaged over six months, or over the last week if that’s lower. Pushing the price up can’t trigger a transfer, because the lower average is used. Pushing it down to avoid one means holding the median down across several exchanges for a week, in public, and it only delays the transfer by a quarter. **On the accounting** : ZCG already publishes its spending and commitments every quarter, and the ZIP requires both programmes to. The reserve uses a full year of actual spending, not a forecast. The only way to “spend more” is to fund more work, which is what the programmes are for. Each calculation is also checked independently before anything moves. A fixed ZEC amount doesn’t remove the price dependency. It hides it. 50,000 ZEC was chosen with a price in mind, and it means something very different at USD 100 and at USD 5,000. The both-taps ZIP makes that dependency explicit and checkable. If you can see a way to keep the fairness with less reliance on a price source, I’d welcome it here, or on the GitHub issue. This is a very early draft. ---
**Author:** ![fabacab](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/fabacab/32/38834_2.png) [@fabacab](https://forum.zcashcommunity.com/u/fabacab)\ **Post date:** [November 15, 2026, 4:57pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/5 "2026-11-15T16:57:24Z")
> [@vaspholdings](#): > > Under rough consensus, no change is the default anyway. Keeping ZIP 1016 as it is, for now, closes no doors. Every other funding option on the ballot does. This isn’t true. The [Zcash Adoption Pool (ZAP) ZIP](https://zips.z.cash/draft-dairaemma-governance-zap) is the one existing proposal does not modify any funding streams. It is effectively status quo plus a formalized definition of adoption that can be used to guide future ZIPs in a meaningful way towards further securing the Zcash network and project, and it _explicitly_ reaffirms existing open doors including future legal and technical development, regardless of where the funding for a specific effort comes from. You are bluntly remiss to not even mention this option in this discussion. ---
**Author:** ![lawzec](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lawzec/32/50732_2.png) [@lawzec](https://forum.zcashcommunity.com/u/lawzec)\ **Post date:** [November 15, 2026, 5:08pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/6 "2026-11-15T17:08:15Z")
This post was flagged by the community and is temporarily hidden. ---
**Author:** ![vaspholdings](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/vaspholdings/32/30024_2.png) [@vaspholdings](https://forum.zcashcommunity.com/u/vaspholdings)\ **Post date:** [November 15, 2026, 5:20pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/7 "2026-11-15T17:20:57Z")
Thanks for joining the discussion here, @fabacab, and for all the work you’ve put into ZAP. I see this a little differently, though. ZAP leaves the funding streams alone, I agree, but it changes how ZCG works and narrows what it can fund. That’s the door it closes, and I’m not comfortable with it. I’ve put my objections in the ZAP thread, and [they still stand](https://forum.zcashcommunity.com/t/zip-zcash-adoption-pool-zap/58656/297). **That’s another advantage of voting for the status quo** : it leaves room for a separate discussion about reforming ZCG. There are already several ideas on the table, including my hybrid election by ZCAP/coinholders, @thowar2’s [proposal to switch ZCG elections to token holder voting](https://forum.zcashcommunity.com/t/proposal-to-switch-zcg-elections-to-token-holder-voting/53533), your [ZAP](https://forum.zcashcommunity.com/t/zip-zcash-adoption-pool-zap/58656) itself, @emersonian’s [ZIP to expand ZCG to seven seats](https://forum.zcashcommunity.com/t/zip-expand-zcg-to-seven-seats-adjust-limits/59047), and others. You’re welcome to make the case here that ZAP is better. I’m less against it than the other proposals, but I can’t endorse it. ---
**Author:** ![fabacab](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/fabacab/32/38834_2.png) [@fabacab](https://forum.zcashcommunity.com/u/fabacab)\ **Post date:** [November 15, 2026, 5:29pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/8 "2026-11-15T17:29:47Z")
> [@vaspholdings](#): > > ZAP leaves the funding streams alone, I agree, but it changes how ZCG works and narrows what it can fund. No, ZAP does not narrow what it can fund. It explicitly reaffirms that the funding stream used for ZCG currently can fund everything that it is currently being used for _and also_ provides a definition of adoption that offers a more objective model for how to asses the effectiveness of grant proposals. There are so many instances in the ZAP ZIP where we go out of our way to define this that I am bluntly kind of bewildered that you seem to not be hearing us when we say it. Should I detransition before trying to be heard again? Would that help this community hear me when I say things? ---
**Author:** ![CR8](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@CR8](https://forum.zcashcommunity.com/u/CR8)\ **Post date:** [November 15, 2026, 6:00pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/9 "2026-11-15T18:00:54Z")
> [@vaspholdings](#): > > ZAP leaves the funding streams alone, I agree, but it changes how ZCG works and narrows what it can fund. That’s the door it closes, and I’m not comfortable with it. I’ve put my objections in the ZAP thread, and [they still stand](https://forum.zcashcommunity.com/t/zip-zcash-adoption-pool-zap/58656/297). I wonder if you haven’t read the [latest merged version](https://zips.z.cash/draft-dairaemma-governance-zap), which I think clarifies that ZAP allows any project if there’s evidence that it will lead to more adoption. (I have no inside information, but my reading of the conversations here is that the ZIP has been revised to clarify this _because_ of reasoned arguments such as yours). ---
**Author:** ![lawzec](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lawzec/32/50732_2.png) [@lawzec](https://forum.zcashcommunity.com/u/lawzec)\ **Post date:** [November 15, 2026, 6:04pm UTC](https://forum.zcashcommunity.com/t/one-zip-for-both-taps-fixing-the-colossal-treasury-problem/59325/10 "2026-11-15T18:04:04Z")
i am reasonably confident the only sensible option in zcash will always be on the one that remains censored…