Grant Application - Shielded Compliance Bridge

Community Grants Applications
1

Hello Zcash community, Deborah Olaboye here. I’ve filed a ZCG grant application and wanted to bring it here for community review.

GitHub application: Grant Application - Shielded Compliance Bridge · Issue #379 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

Repository (proof-of-concept, already built): GitHub - DeborahOlaboye/shielded-compliance · GitHub

Technical spec: [SPEC.md]( shielded-compliance/SPEC.md at master · DeborahOlaboye/shielded-compliance · GitHub )

The problem: Zcash’s shielded pool has reached a record adoption of 86.5% of transaction activity and over 31% of circulating supply shielded as of early 2026, but the on/off-ramps that connect it to the regulated economy have not kept pace. Gemini remains the only major regulated exchange offering shielded withdrawals and even there, custodied funds are held on transparent addresses internally for AML monitoring. No exchange currently supports shielded deposits, every other major CEX is transparent-only for ZEC.

No reusable, audited reference implementation exists that lets a VASP’s compliance team ingest a viewing key, reconcile shielded activity against a KYC’d account and produce the beneficiary data required under FATF’s Travel Rule without ever gaining spend authority over user funds.

The absence of this tooling has real, measured consequences, for instance, 73 exchanges delisted at least one privacy coin in 2025 (a 43% increase over 2023), Binance removed ZEC from EU/US markets citing Travel Rule compliance and regulators in Japan and South Korea drove exchanges to drop privacy-coin support entirely. Each of these decisions was made in the absence of any standard compliance path for shielded assets, with VASPs defaulting to delisting or transparent-only support because building compliant shielded infrastructure in-house is prohibitively expensive and unproven.

What I’m proposing: A compact Compliance Reference format, carried in a Zcash memo, that lets a VASP correlate an on-chain shielded transfer with the full IVMS101 Travel Rule record exchanged off-chain through networks it already uses without ever putting PII on-chain and without the VASP ever gaining spend authority over a customer’s funds.

Before filing, I built and verified a working proof-of-concept, UFVK ingestion, live compact-block scanning against a real testnet indexer, the Compliance Reference encode/decode format, a full offline cryptographic round trip and live full-transaction wiring against a real chain. All of it is in the linked repo.

The application requests $17,500 across 4 milestones to take this from proof-of-concept to a production-grade Rust library and TypeScript SDK, extending decryption to Orchard/Ironwood (the proof-of-concept only proved Sapling), checkpointed scanning, a pluggable sanctions-screening interface, IVMS101 record helpers and packaging as a versioned, tested, audited crate plus SDK.

Request for feedback:

- Does the Compliance Reference approach (correlation pointer, not on-chain PII) match what Travel Rule practitioners or exchange compliance teams would actually find usable?

- Is there a cleaner precedent than IVMS101 I should be targeting?

Thank you as I look forward to the community feedback on this proposal.

Zcash Community Grants Meeting Minutes 8/3/2026
2

I’ve worked with compliance teams in large companies in general (most notably implementations of E Travel Rule, not FATF Travel Rule, which is arguably stricter), and I can tell you: the entire point of them pandering to the Travel Rule is because the law requires them to. They shit their pants when a government tells them “do this or we will arrest your CEO when they land at Newark”. A majority of their effort is in fulfilling what exactly the rule says they have to do, to the letter, not one bit less or one bit more.

Unless a global authority formally attests this as something that they recognise works, or at least a law firm does it (you can ask Coinbase, their teams can attest it), they won’t touch it with a ten foot pole. The stakes are too high.

However, this would be an ideal project to be undertaken with a Horizon Europe grant. They LOVE this shit, and you will also get bureaucratic approval (and who knows, someone may take your project to the EU Parliament as something to be replicated for other coins)

But you must understand: do not build the full prototype or take grants from ANYWHERE ELSE if you intend to apply to Horizon Europe. “This was funded as a trojan horse by [entity]” is politically radioactive and the basic due diligence will catch it, and you will never get the grant.

3

Reading your proposal spec (which apparently happens to be completely written by AI without copyediting, which I generally find distasteful), but I have some concerns.

  • Why not just use an IVK? Zcash has IVK and general transaction VK, as well as FVK support, one can simply use them to attest to transactions. Regulatory bodies are already familiar with it, which is why they permit Gemini to send out shielded Zcash in the first place.
  • Accepting transparent Zcash when it is trivial to use a proxy address to send shielded ZEC to transparent addresses means all exchanges already consider the fact that they are receiving obfuscated ZEC. What makes you think that they will accept a “proof of identity” for a transaction at the end node when it could just be a proxy end node, with the person who sent you the ZEC being… yourself? It brings no real benefit.

To illustrate: I use your spec to generate a “Compliance Reference” that my address transacted shielded ZEC that I received on address A from address Z, and I am sending to address e_B (the exchange deposit address). Who’s to say that I didn’t send the ZEC from C to Z, then sent it to A, and generated a compliance reference of receiving it on A from Z?

2 Likes