Private Preconfs
TLDR; Let’s kick off discussions on what properties we want a preconf protocol on Zcash to have. Disclaimer: I am not a consensus researcher, just an engineer, and the majority of this post is just thoughts off the dome; please forgive any mistakes or inaccuracies.
Credit cards and traditional finance offer a certain immediacy that we currently do not offer. This turns out to be a huge blocker for adoption, as not only is it a necessity for merchants, but has become an expectation of users when transacting online.
Despite the mindboggling speedups Zcash engineering teams have recently achieved, the upcoming Tachyon upgrade, and 25s blocks coming in NU7, Zcash transactions will still take too long to be confirmed to be practical for some real-world use cases.
However, “confirmed” in this context doesn’t necessarily have to mean the same thing as finality.
An important assumption to question is the idea that what merchants need is a super quick, irreversible transaction. Credit card processors don’t even offer this! What they generally need is:
- Fast assurance that a transaction is likely to be included.
- A sufficiently low probability that a conflicting transaction becomes canonical instead.
- Potentially, an economic guarantee against the residual risk if #1 and #2 cannot be made sufficiently strong at the protocol layer.
With this post I want to kick off discussions around creating a protocol for preconfirmations on Zcash, and navigate the tradeoff space together.
What is a preconf?
A preconf (short for preconfirmation) is an early assurance about a transaction’s future inclusion in the blockchain before the block containing it is actually finalized or even produced.
For example, normally you submit a transaction and wait for a miner to put it into a block. With preconfs, some party can make a commitment about its future inclusion much earlier. There are many different flavors of such protocols, some being enshrined in consensus, some relying on predictable proposers, some using external providers or committees, and with very different security assumptions.
One complication for Zcash is that PoW does not have predictable proposers. A mining pool with hash fraction h cannot promise that it will produce a block at some particular future height; block production is stochastic. Ignoring other failure modes for a moment, if participating miners collectively control fraction h of hashpower, the probability that none of them mines any of the next n blocks is approximately:
So I think we should be careful about what exactly we mean by a “preconfirmation” on Zcash. An external protocol may be able to provide a very strong probabilistic inclusion/conflict-resistance guarantee without being able to provide the same guarantee as a protocol with known future proposers.
The “proposal” I will start these discussions with is based on an external preconfirmation service, preventing any changes to consensus. From my understanding this fits best with Zcash directionally: such a preconf service is really something built on top of Zcash, can bring extra revenue to miners, and potentially even sustain itself.
NOTE: While “Without changing consensus” here means that the service would not require changes to Zcash’s transaction-validity, block-validity, or fork-choice rules, it still leaves open that incentives underlying consensus wouldnt change. Carlsten et al. demonstrate that transaction-fee rewards can incentivize miners to fork previously mined blocks in a fee-only regime.¹ Daian et al. show that sufficiently valuable MEV can motivate “time-bandit” attacks, which rewrite earlier blocks.² Other recent work by Bahrani, Neuder, and Weinberg analyzes profitability of selfish mining under variable and stochastic rewards.³ These mechanisms could change mining behavior without necessarily requiring changes to the underlying consensus rules.
Essentially, a sufficiently valuable preconf market could itself influence the reward landscape for miners.
What guarantees can we provide?
Even when every participating miner behaves honestly, non-participating miners could find the next block and include conflicting transactions.
So the guarantee to merchants should probably ultimately be expressed in terms of something along the lines of:
under explicit assumptions about participating/adversarial hashpower, miner behavior, network propagation, reorg depth, and whatever the enforcement mechanism is.
I wont attempt to derive such bounds in this post.
Preconf Service
The idea behind preconfirmations, again, is to let a merchant accept a Zcash payment before it is mined. In this protocol, the merchant receives a signed promise from a preconfirmation service.
Alice creates one ordinary Zcash transaction, T, containing two intended shielded outputs:
- Merchant output: the purchase payment, addressed to the merchant.
- Service output: a preconfirmation fee, addressed to the service.
The service validates T and signs a commitment identifying T to disperse to miners.
For preconfs to take hold without modifying consensus, there needs to be an incentive for miners to participate. One incentive would be to have the preconf service pay the majority of fees associated with a bundle to the miner who includes it.
Note that this still doesn’t prevent a malicious user from submitting a conflicting transaction (spending the same note) directly to the mempool, where it may be picked up by a non-participant.
Also, “higher fee wins” should not be assumed to be the mechanism here. Zcash transaction selection and fee policy are their own thing. The more general problem is simply that non-participating miners remain free to construct valid blocks containing a conflicting transaction.
This leaves us with two separate problems:
- How do we incentivize participating miners to honor a preconf?
- How much security do participating miners actually provide as a function of their share of total hashpower?
Miner commitments and accountability
One approach to #1 would be to “jail” miners who violate a commitment after explicitly accepting a bundle, which just means excluding them from participating in future preconf revenue-sharing until the behavior is addressed.
But this only means something if participation is attributable.
At minimum, we would need to define:
- what constitutes objectively provable misbehavior;
- how the miner is identified across commitments;
- how identity rotation/Sybil behavior is prevented from making exclusion meaningless;
- how long exclusion lasts; and
- whether penalties are purely foregone future revenue or backed by some stronger economic mechanism.
This is, of course, not cryptoeconomically guaranteed if the only punishment is exclusion from future revenue, and it is only effective if preconfs have enough adoption to be a useful revenue stream for miners.
That creates a cold-start problem: to get users, miners need to adopt it, but to get miners to adopt it, we need users.
Default propagation / block-building policy
An idea to break out of such network effects could be to have full nodes prioritize preconf transactions by default.
What this could potentially look like in practice would be a secondary mempool for Zakura nodes that only accepts transactions signed by the service. There are probably better ways to go about this, though.
The main idea is that we can make participation easy/default for miners, so opt-out instead of opt-in. My assumption is that this would likely be the fastest path to adoption if miners don’t need to operate significant additional infrastructure and can earn incremental revenue by leaving the default enabled.
Crucially, Zakura already provides the ability to easily run additional/custom p2p services on your node. Nodes who run the protocol could participate in propagating commitments, while miners who actually contribute scarce block-production capacity would be entitled to revenue sharing according to whatever mechanism we settle on.
(simply “running a miner” cannot be the basis for revenue sharing, as it creates a Sybil problem especially with shielded coinbase.)
I’ve vibecoded a demo you can poke around with at preconfs.deltadevs.xyz. It has a minimal diff to Zakura and the service can be found at deltadevsde/zcash-preconfs. Again, just vibecoded, likely there is nothing there that usable outside of a hypothetical demostration of the general shape it could take.
Again, this is just vibecoded and likely there is nothing there that is usable outside of a hypothetical demonstration of the general shape this could take.
Is this actually a preconfirmation, or insurance?
A merchant doesn’t necessarily care why accepting a transaction immediately is safe. They care about the expected loss.
If an external service cannot make the probability of a conflicting canonical transaction negligible through miner commitments alone, it could potentially absorb some of the residual risk:
“If we preconfirm T, and a conflicting spend becomes canonical under the conditions specified by the commitment, we compensate the merchant.”
At that point the service starts looking less like a pure consensus mechanism and more like a combination of a preconfirmation market and transaction insurance.
That might actually be fine.
In fact, it may map more closely to the original product requirement: merchants don’t necessarily need instant irreversible settlement; they need a sufficiently reliable authorization that lets them safely hand over goods or services.
But this introduces a different set of questions around collateral, solvency, correlated failures, maximum transaction values, fee/risk pricing, and what exactly constitutes a compensable failure.
It may turn out that the useful design is somewhere on a spectrum:
pure probabilistic preconf ← miner-backed commitment ← economically insured preconf
rather than one mechanism providing every guarantee.
Security model
I think any serious version of this needs to explicitly model at least:
- h: honest participating hashpower;
- a: adversarial or strategically deviating hashpower;
- u: non-participating hashpower;
- the preconf fee/reward;
- the value of a conflicting spend;
- the value of violating a commitment;
- the value of future preconf revenue lost through exclusion;
- network propagation assumptions;
- reorg depth / confirmation horizon; and
- any collateral or insurance provided by the service.
Some obvious questions follow.
- At what participation threshold does a preconf become useful to a merchant?
- How does the failure probability decay with time?
- When is it individually rational for a miner to honor a commitment?
- When does the value of violating a commitment exceed the discounted value of future preconf revenue?
- Can an attacker bribe miners to violate commitments?
- Does the preconf market create sufficiently large or sufficiently variable rewards that miners have new incentives to reorg ancestors?
- Does concentrating preconf revenue in a subset of miners create centralization pressure?
- What happens when the service equivocates and signs incompatible commitments?
- Can equivocation be objectively proven without compromising Zcash privacy?
- And, perhaps most importantly: what exact statement can a merchant safely infer from a valid preconf certificate?
Open questions
There are obviously a lot of edge cases that need to be dealt with here, and various questions to be addressed.
The biggest questions that immediately come to mind are:
-
What guarantee do we actually want? Probabilistic inclusion, conflict resistance, economic insurance, or some combination?
-
What security can we provide as a function of participating hashpower? In particular, what failure probability should a merchant associate with a preconf at h=20\%, 50\%, 80\%, etc.?
-
What exactly does a miner commit to? Inclusion if it mines a block? Refusal to mine known conflicts? Both? For how long?
-
How do we make miner violations objectively attributable? What constitutes evidence, and how do we prevent miners from cheaply rotating identities?
-
How should revenue be distributed? In particular, what scarce/verifiable contribution determines a participant’s share, without creating a Sybil problem?
-
What happens when a conflicting transaction enters the canonical chain? What is the tolerance for this happening, and does the service compensate the merchant?
-
What happens if the preconf service equivocates? Can conflicting promises be detected and punished?
-
How much information does the service learn? Can the protocol preserve Zcash’s privacy properties while still allowing the service and merchant to verify the information they need?
-
Does enough MEV or preconf revenue arise that it could change the economic incentive for miners to build on ancestors?
-
Does this create centralization pressure? In particular, does a dominant preconf service become a de facto coordinator of transaction ordering or miner policy?
-
Is enshrining something like Dash InstantSend aligned with the ethos, counter to my intuition? Maybe only enshrine if an external protocol demonstrates demand? Or never?
-
Once developed, if kept as an external service, which party should be responsible for hosting, maintenance, and governance of the service?
-
Do any teams currently have the bandwidth to dedicate to this? Or is there a need for a new team?
-
What are sensible defaults for fee capture of such a service?
I’m particularly interested in people poking holes in the security model here. If the external-service direction turns out to be not useful enough under Zcash’s PoW model, that’s also a useful outcome of the discussion.
References and Related Reading
- Carlsten, Kalodner, Weinberg, and Narayanan (2016), On the Instability of Bitcoin Without the Block Reward
- Daian et al., Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges
- Bahrani, Neuder, and Weinberg (2025), Selfish Mining Under General Stochastic Rewards
No normal people are fine with sitting at a POS for 25 seconds waiting for a transaction to go through. Have you recently done a zcash transaction at a POS? I have, at common s3nse… it was a terrible experience!