Is there any block with shielded coinbase?

I’m curious whether there is a block with shielded coinbase transaction?

Does anyone know?


If you are referring to mining to a shielded sapling (zs1…) address, no.

Documentation and requirements are at the following link: ZIP 213: Shielded Coinbase

1 Like

Thanks for the info.

Do you think that miners actually plan to use it?

Poolin’ mining pool (one of the biggest Zcash mining pools) has said that they support private coinbase mining:


What does that practically mean as in, being a pool, wouldn’t they be mining to a shielded coinbase? Are they a pool for solo mining? We’ve obviously had payouts from pools to shielded addresses for ages.

I’ve also been monitoring for any shielded coinbases and at this time, as noted above there seem to be none. Since Heartwood activation:

Transparent coinbases: 8313
Shielded coinbases: 0

Theres no mention of it on the pool website so perhaps its in queue or something
(I cant tell if they offer shielded payouts at all)

This is very useful, thank you. Please keep us updated :slight_smile:

Poolin announced that they would be adding shielded support. They were waiting on Heartwood to activate successfully before they could do anything. Hopefully we’ll see them move to shielded coinbase soon.


Thier post implied that they would start using mine to shielded pool, but it doesn’t look like they have yet.

If I had to guess it’s likely a matter of pools updating their pool software/workflow to accommodate for skipping the T-Z step that they’re used to.


Not sure how much of what Duko wrote here is fact or lie:

Why does miner z-addr needs to be public? Would it have been possible to just make transaction amount public?
@daira @str4d @nathan-at-least can you answer concerns we have with shielded coinbase. What are benefits & limitations?

While there is tech complexity here, I wonder if things would’ve been designed better if PMs are involved.

The mint is visible which I believe a total-supply auditability thing but allows for a miner to be completely z2z (as in no taddy reliance) if they choose, it seems about as harmful as a t2z

dontbeevil: I believe the ZIP-213 already answers your questions: ZIP 213: Shielded Coinbase

Please see the Rationale and Security and Privacy Considerations sections.


Thanks …

@zooko @nathan-at-least Is anyone from ECC reaching out to the pools to see what the technical hurdles are for using mine to Z coinbase transactions?

There has to be some part of the picture we are not seeing.

1 Like

Like JoshS said upthread, Poolin has told us they are going to do it, and they told us that they were going to wait until post-Heartwood-activation before initiating other changes.

A few times now I’ve heard Nathan talk about “follow-through” as part of the process of rolling out new improvements — tracking, supporting, and publicizing when users start using new on-chain features.


There’s no merit to DukeLeto’s contentions whatsoever. The only plausible potential weakness that can arise from revealing a z-addr is against a discrete-log-breaking adversary (that could also break Bitcoin, Monero, Hush, and practically every other cryptocurrency).


There has finally been a block mined with a shielded coinbase. This block 949496 was the first I see 5 total so far (949506, 949640, 949656 and 950050) but it’s a start :smile:


Are they all to unique coinbase destination addresses?

1 Like

As noted here I am not sure how to use the all-zero viewing key to determine this. Does anyone have any more insight?


After decrypting outCiphertext -> (pk_d, esk) with the all-zeroes ovk, followed by encCiphertext -> (leadbyte, d, v, rseed, memo) (i.e. decryption per §4.17.3, which can be done in Rust with the zcash_primitives::note_encryption::try_sapling_output_recovery function), you can reconstruct the payment address as (d, pk_d) (the Rust function does this for you, returning a PaymentAddress), and then encode that as usual with Bech32 using the HRP for the network the transaction was on (i.e. zs for mainnet) (§5.6.4).