Grant Application - ZPAD-20 — Open Asset Indexing & Discovery Infrastructure for Zcash

Community Grants
1

Hello Zcash community,

I’ve submitted a grant application to ZCG: ZPAD-20 — Open Asset Indexing & Discovery Infrastructure for Zcash ($24,000, ~4.5 months, solo developer). Posting it here for community input, and happy to answer any questions — including the hard ones.

Full application: Grant Application - ZPAD-20 — Open Asset Indexing & Discovery Infrastructure for Zcash · Issue #319 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

One-liner: an open-source, deterministic indexer + conformance suite + public explorer/API that reconstructs application-asset state directly from the Zcash chain — same chain → same state, no trusted oracle — designed to carry over to native assets when ZSA (ZIP-226/227) ships.

Why this matters

Zcash has growing asset activity — ZRC-20 inscriptions (Zecscriptions, Zinc, Zerdinals) already exist — but there is no shared, conformance-tested indexing standard. Each project runs its own bespoke indexer, and no third party can independently prove any of them computed state correctly. Bitcoin has mature open indexer/explorer tooling for its meta-protocols; Zcash doesn’t yet have a verifiable equivalent. This gap widens with ZSA: native assets will need exactly the same indexing and discovery layer when NU7 lands.

What already exists (before any grant money)

The spec and a tested reference implementation are public and MIT-licensed — you can verify everything in five minutes:

  • Operation codec, pure deterministic ledger, replay tooling
  • Passing test suite including a reproducibility test (same op log → identical state)
  • Zero-infrastructure demo: npm test && npm run demo
  • A ZSA-compatibility document mapping every operation onto ZIP-226/227
  • A backend already connected to a real Zcash testnet lightwalletd over gRPC

Repo: GitHub - tufanaydinn/zpad-20: ZPAD-20 — open bonding-curve token standard for Zcash (meta-protocol spec + reference) · GitHub

What the grant delivers (3 milestones, $7k each + $3k startup)

  • M1 (Jul 2026): on-chain indexer streaming testnet blocks via zebrad/lightwalletd, transparent-carrier decoding, deterministic reorg handling, green CI.
  • M2 (Sep 2026): published conformance test vectors so independent indexers can prove agreement; shielded-memo detection via viewing key; spec advanced to v1.0.
  • M3 (Oct 2026): documented public read API + minimal hosted explorer (aggregates only — counts/concentration, never addresses); ZSA adapter (or tested stub + migration plan if NU7 isn’t on a test network); stretch: a ZRC-20 read adapter so existing inscription activity flows into the same verifiable op log.

Full transparency: ZecPad

I’m separately building ZecPad, a self-funded application that will use this standard — that’s where ZPAD-20 was extracted from. The boundary is explicit in the application: this grant funds only the open layer (spec, indexer, conformance vectors, API/explorer), all MIT and usable by anyone, including projects that compete with ZecPad. No grant funds flow to ZecPad, and application-level fees belong to the application layer, not the protocol or these deliverables. I’d rather over-disclose this relationship up front than have anyone discover it — ask me anything about it.

Relationship to existing inscription work

Not a competitor to ZRC-20/Zecscriptions/Zinc/Zerdinals. The engine is carrier-agnostic by design — it consumes an abstract op log — so reading ZRC-20 operations into the same verifiable state is a planned adapter. If anyone from those projects is reading: I’d genuinely welcome comparing notes on conformance vectors that cover both standards.

What I’d value feedback on

  1. Would existing indexer operators actually adopt or test against a shared conformance-vector suite?
  2. Reorg handling for meta-protocol state on Zcash — any patterns or war stories?
  3. Anything in the ZSA mapping (deploy → ZIP-227 issuance; buy/sell/transfer → ZIP-226 transfer/burn) that looks off to people closer to the NU7 work?

If approved, I’ll post monthly status updates in this thread. Thank you for your time.

Zcash Community Grants Meeting Minutes 6/22/2026
2

Progress update — ZPAD-20

Quick update on where things stand. While building a reference implementation on top of ZPAD-20, I’ve been feeding the lessons learned back into the open spec — so the standard is now both more complete and more clearly scoped as neutral infrastructure.

What changed in the spec (v0.2):

  • Identity & authorization (4.6, new). The spec now defines how a sell/transfer is authorized. Since Zcash addresses can’t sign messages pre-ZSA, authorization uses a claim-key (cpk) — a signature public key. The signature must bind every field of the operation (tick, amount, destination, nonce), and each cpk enforces a strictly-increasing nonce for replay protection. Importantly, the spec fixes which fields the signature binds and how the nonce behaves — not a specific signing scheme — so any indexer can reproduce verification independently.

  • Indexer determinism strengthened (6). Operations now apply atomically — all of an op’s ledger effects commit together or not at all, so there’s no partial-apply or replay window. Confirmation/reorg handling is now explicit too.

  • Settlement clarified (4.2). A buy carries no signature: the on-chain payment is the authorization (you can’t pay on someone else’s behalf). And settlement is always against the actual on-chain value received — never the memo’s claim. This is the core defense against spoofed-payment attacks.

On scope — keeping the core neutral:

The core protocol stays deliberately minimal: deploy / buy / sell / transfer + identity/auth. Reward and lottery mechanics (the ticket op, monthly draw) are now explicitly optional and non-normative — a conforming indexer can ignore them entirely, and core asset state never depends on them. The goal is for ZPAD-20 to be neutral asset-indexing infrastructure that any wallet, explorer, or application can build on — not something tied to one app’s mechanics.

This is the pattern I hope to continue if the grant moves forward: a real implementation surfacing real questions, and the answers going back into an open, conformance-checkable standard that the whole ecosystem can use.

Spec + reference implementation (MIT): GitHub - tufanaydinn/zpad-20: ZPAD-20 — open bonding-curve token standard for Zcash (meta-protocol spec + reference) · GitHub

3

Thank you for your submission. After careful consideration by ZCG and allowing sufficient time for community feedback on the forum, the committee has decided to reject this proposal. Please see the meeting minutes for further information.