A fixed share of every Zcash block is paid to somebody other than whoever mined it, and that has been true in one form or another since 2016. The share is 20%. It is enforced by consensus rules rather than by agreement, and there are currently 4 separate specifications describing where it should go.
Search the phrase and nothing ranks. Search the arrangement it replaced and you get four news stories from November 2020 about the old system ending, three of them the same wire copy.
Nobody covers what came after. So here are the four documents, what each one specifies, who is named in them, plus the part none of them settles.
What a funding stream actually is
The word "fund" suggests a pot of money that somebody somewhere controls and can decide to spend at will. That picture is wrong in a way that matters for everything below it, and correcting it first explains why nobody in particular is able to redirect any of this.
A funding stream is a consensus rule. Every node validating a block checks that the required portion of the subsidy went where the rules say, and a block that pays it elsewhere is not a valid block. There is no treasury, and no transfer for anybody to authorize.
The practical consequence is that changing the arrangement requires changing the rules every participant enforces, which means a network upgrade. Our guide to Zcash network upgrades covers what that involves, and the short version is that it is a slow and public process rather than a decision anybody makes alone. Our guide to how mining works covers who receives the rest of each block.
That property is the strongest argument for the design and the strongest argument against it, depending on where you stand, and this article returns to it once at the end.
It also explains why nobody can answer a question like "who could stop this" with the name of a person or an organization. The answer is everybody running a node, collectively, at a scheduled block height.
The reference implementation treats these allocations as protocol constants rather than as policy, which is the same point stated in code (source: zcash/zips). Nothing in a wallet or a node exposes a setting for them.
For the mechanism in general terms, see how a chain's rules get changed. The other 80% goes to whoever did the proof of work.
The original structure, and who was named
The arrangement that replaced the founders' reward is set out in ZIP 1014, and it is unusually specific about its recipients for a protocol document. Most consensus specifications describe mechanisms; this one names organizations, which is what makes it readable and also what makes it contentious.
It describes a fund "to be enacted in Network Upgrade 4 and last for 4 years", made up of "20% of the block subsidies, split into 3 slices: 35% for the Bootstrap Project (the parent of the Electric Coin Company); 25% for Zcash Foundation (for internal work and grants); 40% for additional 'Major Grants' for large-scale long-term projects (administered by the Zcash Foundation, with extra community input and scrutiny)" (source: ZIP 1014).
Those three percentages are shares of the 20%, not of the block subsidy. So the Bootstrap Project slice is 35% of 20%, which works out to 7% of what each block pays. Getting that wrong inflates every figure by a factor of five, and it is the most common error in writing about this subject.
Two other details are worth pulling out. The document names organizations rather than roles, which is what makes it a funding arrangement rather than a governance framework. And it specifies a four-year term, so it was written to expire rather than to continue by default.
The index lists ZIP 1014 as Active (source: Zcash Improvement Proposals).
That status is worth pausing on, because it is not the vocabulary the consensus specifications use. Deployment ZIPs are marked Final. Funding ZIPs carry Active, Proposed or Obsolete, and the difference between those two vocabularies is the first hint that this subject is governed differently from the rest of the protocol.
What replaced it
The next document moved the money in a noticeably different direction. Our guide to How Zcash mining works covers its exact figures from the mining side, so what follows summarizes rather than quoting them again, then puts its weight on what changed about the shape of the recipients.
In short, it directs 8% of the block subsidy toward grant-making through an established body, and routes 12% into an in-protocol lockbox. That is still 20% in total, and the recipients have changed shape: one slice funds grants through an existing body, and the other accrues into a pool.
The lockbox is defined by its own specification, which "specifies a change to the Zcash consensus protocol to define a pool of issued Zcash value to be used to fund future development efforts within the Zcash ecosystem" and "defines a new 'DEFERRED_POOL' funding stream type", building on the general funding stream mechanism (source: ZIP 2001).
So the second arrangement changed the shape rather than only the recipients: less money going to named organizations, more money accumulating in a protocol-level pool. Our guide to the Bitcoin halving covers the schedule that shrinks the absolute amount over time on any capped chain.
The index lists both of those documents as Final, which in the funding context sits alongside Active rather than replacing it.
The arithmetic is unchanged from the reader's point of view. Twenty percent of every block leaves the miner either way, and what moved is the destination rather than the size.
The lockbox, and the missing exit
Here is the part that makes this subject genuinely unsettled rather than merely complicated. It is also the reason a plain question about who receives the fund turns out to have no plain answer at the moment, which is unusual for something written into consensus rules.
The lockbox accrues value by consensus rule. What it does not have is a mechanism for paying anything out. Our guide to How Zcash mining works recorded that point from the allocation document's own abstract, which states that no disbursement mechanism is currently defined and that the community will need to decide upon and specify one in a future proposal.
Read that plainly: a portion of every block accumulates into a pool that, as specified, nobody can spend.
The pool itself is a real protocol object rather than an accounting fiction. The reference libraries model funding streams and their destinations directly (source: zcash_protocol), so the value is tracked by every node exactly as ordinary supply is.
That reflects a deliberate sequencing choice rather than an oversight or a scandal, where the decision to set money aside was made first and the decision about who releases it was left for later. Whether that ordering was wise is exactly the argument this is not having.
What it does mean is that anyone asking "who receives the dev fund" is asking a question with two different answers depending on which slice they mean. One slice has a recipient. The other has a destination and no exit.
What is proposed next
The third arrangement exists as a proposal rather than as a rule, and its status is the single most important thing about it. Reading it as a description of how things work would be an easy mistake, since the text reads exactly like the two enacted documents.
It "outlines a funding model that gives the community and coin holders distinct voices", allocating "8% of the block rewards" to the community grants committee and directing that "12% of the block rewards will accrue to a fund controlled by decisions of coin holders, seeded by the Deferred Dev Fund Lockbox". That coinholder-controlled fund "may be used to distribute larger grants to ecosystem participants, or left at rest" (source: ZIP 1016).
The index lists this one as Proposed, which in this context means written, published, and yet not enacted.
Two things follow. The proposal is an answer to the missing-exit problem above, since it would give the accumulated pool a decision procedure. And the fact that it remains a proposal is itself the clearest available evidence that the question is open.
Worth noting that the wallet software everyone runs carries no opinion about any of this. It implements whatever the consensus rules currently say, versioned release by release (source: librustzcash changelog), which is why a holder never sees a choice about it.
To inspect the transparent side of any of this yourself, reading a block explorer is the practical starting point. Our guide to Zcash halving handles the halving that shrinks the 20% in absolute terms.
What none of these documents settle
Four things, and the first of them explains why what follows contains no figure describing what is happening right now. Each is a question the documents raise and leave open, which is a more useful thing to know than a confident answer would be.
None of them tells you which allocation is paying out today. The four documents carry three different statuses: Active, Final and Proposed. A status describes a document rather than a network, which this series has now found in three separate contexts, and no capture in hand settles which rules the chain is currently enforcing. Read that from a node rather than from any page.
None of them resolves who decides. The original arrangement named organizations. The replacement created a pool with no disbursement mechanism. The proposal would hand that pool to coinholders and has not been enacted. Those are three different answers to the same question, and the sequence is the evidence that it is unsettled.
None of them is permanent. The original was written with a four-year term. The current arrangement has already replaced it, and a further proposal exists. Anyone treating today's arrangement as the end state is reading a snapshot.
The project's own documentation describes the chain's economics without resolving any of this either (source: Zcash documentation), which is a fair reflection of the state of the question rather than an omission.
And none of them is this article's argument to win. The dispute about who should control the fund is covered separately in our guide to Zcash crosslink proof of stake, and the job here is to state what the documents say and where they disagree.
For the wider question of how a protocol-level cost affects anyone holding the asset, our guide to portfolio basics is the general starting point.
BloFin receives nothing from any of this, which is worth saying on a page about who gets paid.
Why funding in the protocol changes the argument
Most projects settle their funding privately before launch. Putting it in the consensus rules produces a structurally different situation, and three consequences follow.
The arrangement is enforced rather than agreed. A block paying the wrong proportions is rejected by every node, which means no organization administers the allocation and none can vary it without a consensus change.
Changing it requires the public process. There is no boardroom in which this gets decided. A change needs a specification, implementations and an activation height, all of which happen in the open, which guarantees a public argument every time the question comes up.
And the arrangement expires or renews on a schedule visible to everyone. That produces recurring decision points rather than a settled position, and each one reopens the question of who should receive what.
The result is a project that argues about its own economics publicly and repeatedly. Whether that is a strength depends on what you value: it is slower and noisier than the alternative, and it is also the reason anyone outside the project can read exactly where the money goes.
What the documents settle and what they do not
Four things the record establishes, and three it leaves open, because the two get merged in almost every account of this subject.
It establishes the current split, as a consensus rule with a specification behind it. That is checkable rather than reported.
It establishes the history of how the split has changed, since every change went through the same documented process.
It establishes which recipients are named, and it establishes that one destination accumulates without a defined way for value to leave it.
Whether the arrangement is fair goes unsettled. That is a value question, and the documents contain arguments rather than answers.
It does not settle what happens to the accumulating balance. Proposals exist, none has activated, and the specifications describe alternatives rather than a decision.
And it does not settle whether the arrangement has worked. Assessing that requires a counterfactual about a project that funded itself differently, and no document supplies one.
Why this argument recurs rather than resolving
Three structural features guarantee the subject comes back, and none of them is anyone's fault.
The arrangement has an end date by design. Every version has been time-limited, which means a decision point arrives on a known schedule whether or not anyone has reached agreement in the meantime.
The value at stake grows while the argument runs. An accumulating destination with no defined exit means each passing block increases the quantity the eventual decision governs, so delay changes the stakes rather than preserving them.
And the participants have genuinely different interests that no amount of discussion reconciles. Miners, holders, the organizations receiving grants and the developers doing the work all bear different costs and receive different benefits, and the disagreement is about distribution rather than about facts.
Read that way, the recurrence stops looking like dysfunction. A public, documented, recurring argument about distribution is what you get when the alternative, deciding it privately once, has been ruled out by putting the arrangement in the consensus rules.
For a holder, almost none of it requires action. The split affects who receives newly issued coins and nothing about how any existing balance is held, moved or secured. What it is worth knowing is that any figure describing the current allocation carries a date, that the arrangement has changed before and will again, and that a page quoting proportions without saying when it was written is describing an unspecified moment.
The one place it becomes concrete for a holder is the supply schedule. Coins directed to any of the destinations were issued under the same curve as everything else, which means the arrangement redistributes newly issued supply rather than adding to it. Anyone describing the allocation as inflationary has misread the mechanism, and the correction is worth making because it is the most common error on this subject and it points in the direction that causes unnecessary alarm.
Frequently asked questions
What percentage of Zcash goes to the dev fund?
Twenty percent of the block subsidy, across every arrangement described so far. What changes between the documents is how that 20% is divided and who receives it. The most common error in reading about this is treating the internal splits as percentages of the whole subsidy: in the original arrangement, the 35% slice is 35% of the 20%, which is 7% of what a block pays. Getting that wrong inflates every figure by five.
Who receives the Zcash dev fund?
That depends on which document you are reading. The original arrangement named the Bootstrap Project, described in the specification as the parent of the Electric Coin Company, the Zcash Foundation, and a Major Grants slice administered by the Foundation. The arrangement that replaced it splits the same 20% between grant-making through an established body and a protocol-level lockbox, which is a destination rather than a recipient.
Can the dev fund be changed or removed?
Yes, and only by changing the consensus rules, which in practice means a network upgrade. There is no treasury account and no administrator who could redirect it, because the allocation is checked by every node validating every block. That makes the arrangement hard to change quietly and equally hard to change quickly, which is the same property viewed from two directions. It also means any change arrives with a schedule attached, since upgrades activate at a stated block height rather than on somebody's decision.
Why is money accumulating in a lockbox nobody can spend?
Because the decision to set value aside was made before the decision about who releases it. The allocation document states that no disbursement mechanism is currently defined and that the community will need to specify one in a future proposal. A later proposal would hand the accumulated pool to coinholder control, and it remains a proposal. Whether that sequencing was sensible is an active argument with its own place in this series.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the Zcash Improvement Proposals repository and its specification index. All facts independently verified against cited documentation current as of August 2026. what follows states what each specification says, makes no claim about which allocation the network is currently enforcing, and takes no position on who should control the fund.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.