Zcash Crosslink is a proposed upgrade from Shielded Labs that would add a proof-of-stake BFT layer on top of Zcash's proof-of-work chain. The extra layer would finalize blocks that miners produce; it would not replace mining. The design is a living draft, its code is a prototype, and in the sources we read there is no ZIP and no mainnet date.
Status as of October 12, 2026
Sources are Shielded Labs' Crosslink page, the Crosslink design overview (its header says "Living document, draft 10",
file dated 2026-09-14), the crosslink_monolith repository README and the official ZIP index, all read on October 12,
2026. Everything described below is a proposal or prototype, not a deployed feature. We did not run the
prototype and did not read every chapter of the design book.
What Crosslink is meant to do
Shielded Labs describes Crosslink as "a proposed upgrade for Zcash" and states its goals as strengthening the 21 million supply cap with "the combined security of Proof of Work and Proof of Stake" and letting people "get paid to hold ZEC." Today Zcash is secured only by proof of work (see how Zcash is mined). The idea of a hybrid is to combine the two kinds of security; how well that combination holds is exactly what the open questions and the missing proofs below are about. Shielded Labs frames the goal as strengthening, not changing, the max supply of 21 million ZEC; how issuance would be split is covered below as a proposal.
How the design works
Everything in this section comes from the design overview (draft 10) and is subject to change.
- Proof of work stays in charge. The overview says the BFT layer's job is to finalize proof-of-work blocks, not to replace proof of work or hold ledger state, and that "if the BFT layer fails the network decays gracefully back to plain PoW."
- A BFT layer finalizes blocks. The finalizing layer is called Tenderlink, a Tendermint-derived reimplementation. Each of its certificates finalizes a proof-of-work block and carries a number of block headers above it as evidence of work. Proof-of-work blocks point to the certificate with a "fat pointer," so all ledger state stays on the proof-of-work chain. In steady state finality lags the chain tip by at least a few blocks; the prototype uses a parameter of 4 for that depth, which the document says has not been checked for security or performance (and a later list of open parameters mentions 3, which the document does not reconcile).
- Sticky fork choice. The chain with the most work is still preferred, but a node's finalized point acts as a floor: it will not switch to a heavier chain that excludes it. In the document's words, the BFT layer "does not choose the chain." It only ratchets a floor under the work rule. The document lists limits of its own: if finality stalls, the gap to the tip is unbounded, and no safety or liveness proof is published for this rule.
For a plain-language comparison of the two kinds of consensus, see our guide to how Zcash works.
Staking and rewards in the draft
- Delegation bonds. The draft describes anonymous, fixed-denomination delegation bonds created from shielded funds (see shielded pool).
- A weekly rhythm. One day per week is a staking day, and unbonding and withdrawing are two separate actions on two different staking days, so the minimum exit is two weeks.
- A proposed issuance split. After the development fund, the overview proposes 48 percent for miners, 48 percent for stakers and finalizers, and 4 percent as a miner bounty for including a new finality. The remaining 52 percent is burned unless the finality condition is met. This is separate from the test split used on Crosslink's incentivized test network, described in our staking guide. Neither number is a decided mainnet rule. For how issuance works today, see how the halving works.
- No automatic slashing. The draft says punishing stake behind misbehaving finalizers is "a user-coordinated hard fork," because validators cannot agree on exact vote sets.
If you came here asking whether you can stake ZEC today, the answer in our staking guide is not on mainnet.
Where it stands
| Question | What the sources say |
|---|---|
| Is there a ZIP? | None found: no ZIP title in the official index mentions Crosslink, proof of stake, BFT or finality |
| Is it in NU7? | No: Crosslink is not among the ZIPs in NU7's scope (see the network upgrade tracker and NU7 explained) |
| Is the code production-ready? | No: the repository README calls it "a prototype" that is "not production-ready code" and "not what would ultimately be proposed upstream" |
| Is the design final? | No: the document is a "living document", several sections are marked to be confirmed and it lists open questions |
| Is there a mainnet date? | None found in the sources we read |
Open questions the draft itself lists include where to store the finality pointer, whether the pointer could be made fixed-size with zero-knowledge proofs or aggregate signatures, how to define "close to the tip," and post-quantum readiness of the pointer and key types (compare our quantum article).
How a proposal becomes a Zcash upgrade
A change to Zcash's consensus rules goes through a Zcash Improvement Proposal and a coordinated network upgrade, as the history in our network upgrades timeline shows. Crosslink has not reached that stage in the sources we read, so any date you see for it elsewhere is a guess.
What we could not verify
- Whether the design changed after draft 10. The document is a living draft.
- The date of draft 10. The file name carries 2026-09-14; the header gives only the draft number.
- Security and economics. The document states there is no published safety or liveness proof for its fork-choice rule; we did not review any other analysis.
- Test-network figures. We rely on our staking guide for the incentivized test network and did not re-read the forum announcements for this article.
- A mainnet timeline. None was found.
- Chapters we did not read. The book has further chapters (guides, rewards distribution, older design notes).
Sources
Shielded Labs: Crosslink, Crosslink design overview (draft 10), crosslink_monolith repository and the ZIP index.