Retroactive Grant Application - Can I Shield?

Community Grants Retroactive Grants
1

Hi everyone,

I’ve submitted a retroactive grant application for Can I Shield?, a live, open-source board that answers “can I send shielded ZEC to this service, and will a shielded deposit be credited?” for 40 exchanges, wallets, hardware wallets and swaps. Every answer is labelled by the strength of its evidence, from on-chain verified tests down to unverified listings.

Full application: Retroactive Grant Application - Can I Shield? · Issue #104 · Financial-Privacy-Foundation/ZcashCoinholderGrantsProgram · GitHub

Work completed (30 Sep to 7 Nov 2026):

  • The board and evidence model: 40 mainnet services, Ironwood readiness verdicts, a page per service and an open JSON feed (CC BY 4.0)
  • NU7 readiness page and the NU7 Stopwatch, which measured block gaps from the chain: 75.4 s average before NU7, 25.7 s since
  • Shielded deposit checks, which Squirrel asked for on ZecHub’s 28 Oct community call. They opened on mainnet on 7 Nov
  • The first verified result: a shielded deposit from Zodl to Binance’s TEX address, verified on-chain and credited about 8 minutes after it landed

Thanks to orb for the wallet and exchange research credited on the board.

Requested: $4,817 (about 160 hours of work, plus $17 for hosting and test payments).

The code is MIT and the site is at https://canishield.vercel.app

I’d really value your feedback, and if you’ve used the board or run a check, a comment on the issue or here would mean a lot. Thank you!

4 Likes
2

Nice, ZecHub is interested in adding a version of your shielded deposit check as one of our available tools.

2 Likes
3

Useful board. We measured the same activation from our own header client, so here is a cross check of your stopwatch.

You report an average gap of 75.4 s before NU7 and 25.7 s after. We counted medians, 51.0 s before over 1,150 intervals and 17.0 s after over 10,195 intervals.

Block intervals are close to exponential, so the median is about 0.693 of the mean, computed. Your 75.4 s implies a median near 52.3 s against our 51.0 s counted, which is a good match. Your 25.7 s implies a median near 17.8 s against our 17.0 s counted, and our 95 % interval there is 16 to 17 s, so that one sits slightly apart.

The likely reason is the window. Ours runs from the activation block to 72 hours after it. If you tell me yours, we can line the two up block by block. Our raw data, the scripts and the sha256 are at GitHub - pulsehawk/methods: Methods and scripts behind PulseHawk reports. Reproduce our numbers in three commands. · GitHub.

1 Like
4

nice, this is way superior to the check i have on zec-os! very glad i could contribute in some small way.

since it’s MIT licensed, I would be happy to get a version going within zec-os with its own slug as well (and link back to you with full credit of course).

this kind of tooling will become more and more relevant as more folks come onboard. great stuff David!

5

Thank you, squirrel! I’d be glad to see it on ZecHub. It’s MIT, and I’m happy to help adapt it, especially to keep the privacy rules: no stored addresses, details deleted after review, rounded times.

1 Like
6

Thanks for the cross-check, Ben! The window explains it: my 25.7 s was taken on Nov 7, about 41 hours after activation, and the first blocks were slow. The live figure is now 25.3 s over 16,065 gaps (median about 17.5 s), close to your 17.0 s. “Before” runs from block 3,520,000 to 3,543,404.

7

Thank you, orb, your research was a real part of it! Please go ahead, it’s MIT. Happy to help with the zec-os version, especially the privacy parts.

8

thanks david, that closes the question. your 25.3 s mean implies a median near 17.5 s, computed, which is what your board shows, so the exponential rule holds for both of us. our 17.0 s counted covers only the 72 hours after block 3,543,405, a shorter window than yours.

we will count your exact ranges from our own header client, 3,520,000 to 3,543,404 before and the same 16,065 gaps after, and post both medians here with the block range so anyone can recount them.

9

as promised, counted from our own header client:

before, blocks 3,520,000 to 3,543,404, 16 oct 16:40 utc to 6 nov 02:33 utc. 23,404 gaps, median 52 s.

after, the first 16,065 gaps from block 3,543,405 to 3,559,470, 6 nov 02:34 utc to 10 nov 19:15 utc. median 17 s.

our means times ln 2 give 52.2 s and 17.5 s, which matches the medians above and the 17.5 s on your board. the block ranges are here for anyone who wants to recount.

10

Thank you, Ben! Great to have the numbers recounted independently, with the block ranges for anyone to check.