Zcash has a pool of value accumulating by consensus rule that nobody can currently spend, and the argument about what happens to it is usually reported as a single unresolved question. It is 4 live specifications in two families, and reading any one of them gives you a confident and incomplete picture.
Three searches covering this subject return no ranking pages at all, including the exact name of a three-proposal package under discussion since 2023.
what follows maps the documents and their statuses. Our guide to Zcash dev fund covers the dev fund itself and why the lockbox has no exit.
The lockbox, and the two proposals that would empty it
Our guide to Zcash dev fund established the situation the lockbox is in: value accrues to it under consensus rules and no disbursement mechanism is defined, so as specified nobody can move it. That is the starting position and this guide does not re-argue it.
What has not been written up is that two different specifications now propose to resolve it, and they are alternatives to one another rather than successive stages.
The first is the community and coinholder funding model, which our guide to Zcash dev fund covers in detail and which would give the accumulated pool a decision procedure rather than emptying it.
The second is ZIP 271, "Dev Fund Extension and One-Time Disbursement", which carries the status Proposed and was created on February 19, 2025. Its approach is blunter: it proposes "a one-time disbursement of the full contents of the lockbox to a transparent P2SH multisig address", whose key-holders would then distribute the funds as development grants, alongside an extension of protocol-based funding past the scheduled end of the current streams.
That these two are competing rather than complementary is not an inference. ZIP 271 states it directly, saying the proposal "is intended to be evaluated in the context of the Community And Coinholder Funding Model" proposal, which is a specification telling its reader to weigh it against a named rival.
Both would route money through institutions that already exist. The grants body named in this arrangement runs a public application process and invites proposals (source: Zcash Community Grants), which is worth knowing because a debate about mechanisms is easy to read as a debate about whether anyone is doing the work.
The half nobody connects
Now the material that no summary of this subject includes, and it is not a footnote to the lockbox argument but the other half of it. Three further specifications address a different question entirely, and the two halves only make sense together.
While two proposals compete over money already set aside, three others address where money comes from at all. They are a package rather than three ideas, and ZIP 233 says so in its own abstract, describing itself as working "in combination with ZIP 234" and ZIP 235.
All three have carried the status Draft since 2023, and the specification index lists all three among its candidates for whatever the next network upgrade turns out to contain. Whether a chain's issuance ought to change at all is the sort of question that has produced contentious forks elsewhere.
ZIP 233, created August 16, 2023, proposes a mechanism letting anyone voluntarily remove funds from circulation (source: ZIP 233). The community thread discussing the package has been running since well before any of the three reached its current form (source: Zcash Community Forum). ZIP 235, created September 21, 2023, would "remove 60% of transaction fees from circulation, while the remaining 40% is directed as before" (source: ZIP 235).
ZIP 234, created August 23, 2023, is the structural one. It proposes that "instead of following a step function around the 4-year halving intervals inherited from Bitcoin", the subsidy should follow "a smooth logarithmic curve" (source: ZIP 234).
Read that as a proposal and nothing more. The halving schedule described in our guide to Zcash halving is what the network runs today, and our guide to Zcash tokenomics covers the issuance shape it produces. Our guide to Bitcoin's 21 million supply covers the step-function model both chains currently share.
The two families join at a single point. Removing funds from circulation only makes sense if something reissues them, and smoothing the curve is what makes reissuance predictable. The three documents are one design in three parts, and the lockbox proposals are a separate argument running alongside them.
Why burning is the wrong word
The sustainability package is universally described as burning, including by the people who wrote it and by the repository that hosts it, and the specification defining the mechanism states in its own abstract that this is not what the mechanism does.
ZIP 233's abstract is explicit about the intent: removed funds "will be returned to circulation through future block subsidies, rather than being permanently destroyed or held in reserve for discretionary use".
Those are two distinct rejections in one clause. Not destroyed, so the supply is not reduced. Not held in reserve, so nobody acquires a discretionary pot. What is proposed is a delay in issuance rather than a removal of value.
The proposer's own promotional page nonetheless describes the mechanism as enabling "the burning of ZEC from circulating supply" (source: Shielded Labs), and the tracking issue in the specification repository is still titled "Network Sustainability Mechanism: Burning" and remains open (source: zcash/zips), while the specification itself has been renamed to "Removing Funds From Circulation".
A document renamed away from a word its own author still uses in public is a signal worth catching. It is not a criticism of anybody: burning is shorter, it is the familiar term, and no promotional page is written to specification standards. It does mean that a reader who arrives via the word will start with the wrong model, and that model, permanent destruction, changes what the whole package appears to be for.
Anyone wanting to check the current rules rather than the proposals can read the chain directly, which is what a block explorer is for.
What Draft and Proposed mean here
Five documents carry two different statuses between them, and the gap those two labels appear to describe is a good deal narrower than almost any reader would assume on first encountering them (source: Zcash Improvement Proposals). Neither label means what its everyday sense suggests.
ZIP 271 and the funding model proposal carry Proposed. The three sustainability documents carry Draft. Neither status means enacted and neither means scheduled. Why the labels in this repository describe documents rather than the network is our guide to Zcash roadmap nu7 and ironwood's subject, at length.
What is worth noticing instead is the age of each. The three sustainability drafts date from August and September 2023 and are still Draft three years later, while ZIP 271 arrived in February 2025 and reached Proposed. Nothing about that ordering is unusual for consensus work, and nothing about it predicts anything.
The one durable observation is structural rather than procedural. A candidate list is not a queue. The same index that lists all three among its candidates carries an explicit disclaimer against reading inclusion into that listing, and our guide to Zcash roadmap nu7 and ironwood quotes it word for word.
The practical consequence is that a reader can find all five documents, read them accurately, and still have no idea what will happen, which is an unusual position for public specifications to leave someone in.
For anyone weighing what this means for holding the asset, the honest answer is very little in the short term, and crypto market cycles covers why protocol governance is a poor timing input.
What none of this decides
Which proposal wins is not addressed anywhere here and will not be. Four live documents, two of them competing directly, three of them a package written by a single proposer, and every one with advocates who have argued at length (source: Zcash Improvement Proposals).
what follows reports what each document says about itself and stops there.
Nothing here says the lockbox will be disbursed, extended, redirected or left alone. Those are four possible outcomes and the specifications describe only two.
Nothing here changes issuance either. The halving remains the rule the network runs, ZIP 234 is a proposal about replacing it, and a reader who comes away thinking the curve has already been smoothed has been misread by it.
No timeline appears anywhere. The oldest of these documents is three years old and still a draft, and the index listing the candidates warns its readers not to treat that listing as a commitment.
And none of it is about whether the arrangement is fair. That argument is genuinely live, it involves real disagreements between people who have thought about it for years, and our guide to Zcash dev fund covers the history that produced it without taking a side either. Our portfolio basics guide is the right frame for anything you were planning to do with the conclusion.
One further limit belongs here. Nothing above establishes that the funding question needs resolving urgently, and a pool accumulating under a rule everyone can read is a slower problem than an undocumented one. Our explainer on how proof of work secures a chain covers the mechanism the sustainability package is ultimately trying to pay for.
The mechanism, expressed as consensus state
Describing the arrangement in terms of protocol state rather than in terms of intentions removes most of the ambiguity that surrounds it, because the state is unambiguous even where the intentions are contested.
A consensus rule apportions each block's subsidy across a defined set of destinations, and one of those destinations accumulates rather than disburses. The apportionment is enforced by every validating implementation, which means no organization administers the allocation and none can vary it. It is a property of the chain that nodes reject blocks for violating.
The accumulating destination has no specified spend path. In protocol terms it is neither a locked account awaiting a key nor an address whose holder is unknown. It is a quantity the consensus rules track and for which no rule authorizing a decrease has been written. The distinction matters because the two situations have entirely different remedies: a missing key is unrecoverable, whereas an unwritten rule can be written.
Two proposals address that gap and they are not equivalent. One would define a disbursement path, leaving the accumulation rule intact and specifying how value may leave. The other would alter the issuance schedule itself, changing what accumulates rather than what may be withdrawn. Conflating them produces the most common misreading in this subject, because they imply different magnitudes of change and different constituencies of opposition.
Neither has been activated, and both carry statuses describing the maturity of the document rather than the state of the network. A specification may be complete while the change it describes has never been deployed, and that gap between documentary and deployed status has arisen repeatedly on this chain.
What the arrangement implies for a holder
Three implications follow directly, and none of them requires taking a position on the underlying dispute.
The issuance schedule already reflects the allocation. Coins directed to the accumulating destination were issued according to the same curve as everything else, so the arrangement redistributes rather than expands supply, and any characterization of it as inflationary misdescribes the mechanism.
The eventual resolution requires a consensus change, which means it is observable in advance. A specification must exist, an implementation must ship, and an activation height must pass, and each of those is public. Nobody will be surprised by the outcome unless they were not looking.
And the accumulation continues while the argument does. That is the property which makes the disagreement sharpen over time rather than fade, since every block that passes increases the quantity the eventual decision governs.
Why an accumulating balance with no exit is unusual
The situation is easy to state and hard to find a parallel for, which is part of why it attracts so much argument.
A consensus rule directs a share of every block reward into a balance. The same rules define no mechanism for anything to leave that balance. So value accumulates automatically, at a rate nobody has to approve, into a place nothing can currently be spent from.
That is not a bug in any specific sense. It is what happens when a funding rule is written and the disbursement rule that was meant to accompany it is left for later, and later has not yet arrived.
Three consequences follow, and they explain why the disagreement is sharper than the sums involved would suggest.
The balance grows regardless of the outcome of the argument, which means the stakes rise while the discussion continues. Every block that passes makes the eventual decision larger.
Any resolution requires a consensus change, because the rule is in the protocol rather than in anyone's policy. That means it needs a specification, an implementation and an activation, which is a slower path than a committee vote.
And the absence of a mechanism is itself a decision with an effect. Doing nothing is not neutral here; it is equivalent to choosing accumulation, and some participants prefer that outcome to any of the proposed alternatives.
How to read the proposals without picking a side
Four checks, and they apply to any governance document rather than only these.
Read the status field and treat it as describing the document rather than the network. A proposal in any state is a piece of writing until an upgrade activates it.
Separate what a document specifies from what its authors argue for. Specifications contain both, and the argument is often the longer part.
Check whether a proposal changes issuance, changes distribution, or changes only the exit path. Those are three different magnitudes of change and they get discussed as though they were one.
And notice which proposals are mutually exclusive and which could coexist. Some of the disagreement is about direction and some is only about ordering, and the two look identical from outside.
Why the statuses are the hardest part to read
Anyone checking this subject against the primary documents runs into the same obstacle, and it is worth naming before it costs an afternoon.
A status field describes the maturity of a document within an editorial process. It does not describe whether the change is deployed, and the two have diverged on this chain more than once in both directions.
The consequence is that a proposal can look authoritative and enforce nothing, while a rule the network enforces today can sit behind a document still labeled provisionally. Either misreading produces a confident and wrong statement about what the protocol currently does.
The reliable procedure is to treat the document and the chain as separate sources and check both. Where they disagree, the chain is what participants are actually running, and the document is a description that has not caught up.
Frequently asked questions
What is the Zcash lockbox?
A pool of value that accrues under consensus rules from a portion of each block and, as specified, has no defined disbursement mechanism, so nobody can currently spend it. Our guide to Zcash dev fund covers how it came to exist and why the exit is missing. What what follows adds is that two separate specifications now propose to resolve it, and that they are alternatives to each other rather than successive steps.
What is ZIP 271?
A proposal, carrying the status Proposed and created in February 2025, for a one-time disbursement of the full contents of the lockbox to a transparent multisig address whose key-holders would distribute the funds as development grants, plus an extension of protocol-based funding beyond the current streams' scheduled end. It states in its own text that it is intended to be evaluated against the competing community and coinholder funding model.
Does the Zcash network sustainability mechanism burn ZEC?
Not in the usual sense, and its own specification says so. ZIP 233 states the intent is that removed funds will be returned to circulation through future block subsidies rather than being permanently destroyed or held in reserve. The proposer's promotional page and the repository's tracking issue both still use the word burning, while the specification has been renamed to "Removing Funds From Circulation". The mechanism delays issuance rather than reducing supply.
Are these proposals happening?
None of the five is enacted. Three carry the status Draft and have done since 2023, and two carry Proposed. The specification index lists all three sustainability documents among its candidates for the coming upgrade, while attaching an explicit warning against reading inclusion into that listing. No prediction about any of it appears here, deliberately. Three years of Draft status is a fact about the documents and not a signal about their prospects.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are ZIPs 233, 234, 235 and 271 and the specification index, the proposing organization's own project page, the specification repository's issue tracker, and the grants body's public site. All facts independently verified against cited documentation current as of August 2026. Every status quoted is the status printed on that date, and this article makes no prediction about any proposal's outcome.