[Grant Proposal] ZecBit - NFT infrastructure for Zcash Shielded Assets

Community Grants Applications
1

We’re seeking support to publish the metadata standard, indexer, and shielded payment tooling that ZSA-based applications will need, and that the ecosystem does not currently provide.

Some context on where we are today.

On August 29, we issued ten unique finalized ZSAs in a single transaction on the public ZSA test network: ten IssueActions, each with its own assetDescHash, reference note, value-1 note, and finalize = 1, all under a single issueAuthSig.

The transaction confirmed at height 251, and proof generation took roughly 3 seconds on a consumer CPU. It is public and independently checkable against a node we do not operate:

txid    611ddfd4459e813b86b935fc05217f929e29c37cdc96ba8f23fc647e30c26317
height  251
node    https://dev.zebra.zsa-test.net

Since then, we’ve built the marketplace layer around it: catalog, collection and item pages, a minting studio, signature-based wallet authentication, and a verifier that hashes an asset description locally in the browser and finds the corresponding hash in the issuance transaction. Noir Wallet integration is working end to end.

The core problem this grant addresses, however, is not our marketplace.

It is that there is currently no standard way for a wallet to display a ZSA meaningfully, and that gap is structural.

ZIP 227 commits only a 32-byte hash of the asset description on chain and explicitly warns wallets not to display the raw description as a trusted asset name. The reason is straightforward: any issuer could put something like “Official Wrapped ZEC” into that field.

The ZIP anticipates petname systems and trusted registries as possible solutions, but does not define either. At the time of writing, there is no ecosystem-wide metadata standard for ZSAs.

Without one, every wallet adding ZSA support is likely to invent its own convention, creating fragmentation and leaving room for asset-name phishing in the meantime.

Our approach is to make the binding between an asset and its metadata independently verifiable through hashing, with no registry users are required to trust, including ours.

ZMD-1 defines two forms.

The minimal form is:

zmd1|<collection>|<index>

This is the form used by the ten assets we issued on testnet.

The full form appends the manifest CID and content hash:

zmd1|<collection>|<index>|<cid>|<contentHash>

For collectible issuance, this is the preferred form because it cryptographically binds the metadata document to the asset identity.

The asset identity is already derived from the issuer key and BLAKE2b-256(asset_desc) using the ZSA-AssetDescCRH personalization. In the full form, placing both the CID and content hash inside the description means the resulting on-chain identity transitively commits to the artwork, traits, and other metadata.

The minimal form exists for cases where metadata legitimately cannot be finalized at issuance, such as reveal mechanics. In that case, metadata is authenticated by the issuer’s ongoing signature rather than committed directly by the asset identity, and clients should surface that distinction clearly.

Manifests are canonicalized using JCS (RFC 8785) before hashing, so the same logical document produces the same hash regardless of serializer.

For the full form, verification is straightforward and can be performed entirely without relying on a ZecBit service:

  1. recompute the hash of the asset description;
  2. find that hash in the issuance bundle;
  3. fetch the manifest by CID;
  4. verify the content hash.

If any step fails, the metadata is not the metadata committed to at issuance.

The indexer follows the same principle. It walks issuance bundles and derives asset identities without viewing keys or privileged access, meaning two independent operators indexing the same chain should produce the same catalog.

A catalog that only one party can reproduce is ultimately a catalog users have to trust. We want to avoid that dependency.

The grant would fund three pieces of infrastructure:

  • ZMD-1, published as a standalone, versioned specification with a reference resolver library designed for wallet integration and with no dependency on ZecBit services. We want it reviewed by the community before treating it as stable.
  • The indexer, open-sourced so anyone can independently reproduce the public ZSA catalog.
  • Shielded payment intake: block scanning through lightwalletd, trial decryption using an incoming viewing key, memo-tag matching, confirmation and reorg handling, plus a review queue so unmatched payments are surfaced rather than silently discarded. We also want this path externally security-reviewed, because payment handling and transaction signing are the parts of the system where implementation mistakes can directly cost users money.

All three components remain useful even if nobody uses the ZecBit marketplace, and all three will be permissively licensed.

If ZMD-1 eventually becomes a common way for wallets to display NFTs or other metadata-rich ZSAs, that is a better outcome for the ecosystem than keeping it proprietary to us. If another standard wins on merit, that is also fine. Filling the gap matters more than owning the standard.

There are also two limitations we want to state clearly.

First, ZSA is not on mainnet today. NU7 does not include it. Everything described above currently runs on the public ZSA test network, and testnet assets remain testnet assets.

We are building ahead of activation because the current ZIP 226/227 design derives asset identity deterministically from the issuer key and description hash. If that derivation remains unchanged through activation, the same inputs should reproduce the same identity on mainnet without requiring a bridge, wrapped asset, or trusted snapshot migration.

ZIP 226 and ZIP 227 are still Draft, though, so we treat that as the expected migration path rather than a guarantee. If the derivation changes before activation, we will adapt the convention accordingly.

Second, settlement is currently escrow-based.

ZIP 228 remains a draft and has no activation date, so atomic swaps are not yet available. Until that changes, the venue briefly takes custody during a purchase. We disclose that directly in the purchase flow, on a dedicated custody page, and in the technical specification.

We would rather describe that limitation accurately than call the system non-custodial before the protocol makes that true.

Technical specification, approximately 3,200 lines covering the asset model, ZMD-1, registry, indexer, wallet layer, and trading architecture:

Full grant application, including milestones and budget:

We’d especially appreciate feedback on ZMD-1 from wallet teams and protocol contributors. A metadata standard that reaches adoption before being seriously reviewed would not be much of a standard

Thank you for your consideration

39 Likes
2

All the best and hopefully all falls in place by 3rd.

3

Any previous projects you can share that you’ve been a part of? How did you get into NFTs?

5 Likes
4

I think you made an announcement when you created the forum topic. All the accounts are joining now and seem to like the proposal. :rofl:

6 Likes
5

Awesome proposal. Addressing the metadata problem before every wallet invents its own convention makes a ton of sense to me. Also appreciate that the tooling is useful beyond ZecBit. That’s my founder.

6

I know the Foundation will definitely approve this. Nice work Team

8

Fair push. The grant is not fund our marketplace.The useful pieces are the spec, an independently reproducible indexer, and payment intake that wallets can review. If ZMD-1 is published standalone, permissively licensed, and wallets can verify a manifest without talking to ZecBit, it can still be useful even if the venue dies. The escrow limitation is also worth keeping in the thread: until ZIP 228 lands, calling this non-custodial would be sloppy. Review the spec first, then decide if it should become a ZIP.

9

yeah, most of our NFT background came from trading and spending a lot of time around Ordinals. we’ve always liked the Bitcoin-native approach and the culture around artists, collectors and onchain ownership

we came to Zcash because we saw a real opportunity to build something different around privacy and shielded ownership

that’s what pushed us to start ZecBit. we want to build proper NFT infrastructure for artists, collections and communities on Zcash, and help grow the ecosystem around it

we’re genuinely bullish on ZEC and believe there’s a lot of room for this side of the ecosystem to develop

2 Likes
10

Which projects? I’d love to see your work

11

Strong proposal, well thought out and clearly explained.

The verification flow for ZMD-1 sounds like a clean design

All the best on this.

1 Like
12

we’re always happy to see new faces joining, that’s literally how an ecosystem grows

the more people we can bring into Zcash, the better it is for everyone building here. that’s also a big reason we chose NFTs as the entry point, they’re one of the easiest ways to turn attention into actual participation through collectibles, PFPs and community

if people genuinely want to collect ZecBit pieces, use them as their PFPs and rep the project publicly, they’re naturally helping push ZecBit and Zcash at the same time

4 Likes
13

What is going on with all these new accounts @Zecbit?

Mod Note for @ZCG committee:@paulbrigner @artkor this new user has a suspicious amounts of new accounts signing up.

10 Likes
14

Good job bro
Keep building

1 Like
17

I’ve read it, but I just want to ask: since ZIP 227 only commits to a 32-byte hash and forbids the wallet from trusting the raw description—at which layer does ZMD-1 prevent asset name phishing if the issuer can still choose the collection string themselves? I really love this project, so I hope the whitelist spots go to those who are truly here for the long haul

18

The team need to see this

19

One practical gap: wallets need a default for failed verification, not only for successful ZMD-1 checks.

If CID fetch fails, content hash mismatches, or the asset is still on the minimal form, most UIs will either hide the item or still show the pretty image. Both are bad. Better to render a raw AssetId + “unverified metadata” state and let the user opt in to issuer-attested art.

That single fallback would stop a lot of confusion before ZSA hits mainnet.

20

Hoping the project gets this grant and Zec community should definitely support this project.

21

I like this path, but I think there are a few questions the community needs to answer before funding it

  1. Standardization: ZMD-1 is currently a ZecBit proposal. What is the specific process for getting independent wallet developers and other ecosystem teams to review, implement, and potentially adopt it? A standard is only an ecosystem standard if it survives outside of the team that created it.

  2. Single-maintainer risk: This proposal currently has a single aliased maintainer. For an infrastructure that is going to become a common dependency for ZSA applications, how do you plan to mitigate the risk of portability and continuity? Who will maintain the specification, resolver, and indexer if the maintainer becomes unavailable?

  3. Mainnet dependency: ZSA is not yet on the mainnet, and ZIP 226/227 are still drafts. How much of the current implementation is expected to survive protocol changes, and what is the likely plan if asset identity mining changes?

  4. Trust model: This proposal provides a solid rationale for a keyless, replicable tokenizer, which I think is valuable. But the market still needs escrow-based settlement until atomic swaps become available via ZIP 228. How should users evaluate this temporary trust assumption, especially if adoption occurs before atomic settlement?

  5. Ecosystem value: What would success look like if ZecBit itself never becomes a large market? I would like to see measurable adoption goals for standalone implementations - for example, third-party wallets or tokenizers that accept ZMD-1 without relying on the ZecBit infrastructure.

I don’t ask these questions because I think the idea is weak. Quite the opposite: if ZecBit positions itself as infrastructure and not just a marketplace, these are exactly the questions that could determine whether the project becomes a primary ecosystem or just another application built around ZSA

2 Likes
22

We apologize for the confusion. We understand why a sudden wave of newly created accounts can look suspicious or bot-like from a moderation perspective.

ZecBit has an active community of 20,000+ users, and one of our main goals is to bring that audience into the Zcash ecosystem and introduce more people to ZEC, its infrastructure, and the community around it.

As more of that audience discovers the forum, it naturally results in new accounts appearing at the same time. We appreciate the moderators looking into it, and we just wanted to provide context for where this activity is coming from.

1 Like
23

Thank you, these are the right questions. A few of them should have been clearer in the proposal from the start.

  1. Standardization

ZMD-1 will be published as a standalone, versioned spec with its own repository, reference resolver, permissive license, and no dependency on ZecBit services.

We want external wallet and tooling teams involved from Milestone 1, not after the spec is finished. Before we treat it as stable, we want public review, recorded feedback, and interoperability test vectors.

If ZMD-1 proves useful beyond ZecBit, we can then discuss whether it should move toward a ZIP.

  1. Single-maintainer risk

We agree this is a real risk.

The goal is to make every important component independently usable. The spec, resolver, indexer, and test vectors will all be open source. The indexer is built from public chain data, so anyone should be able to reproduce the catalog without relying on private ZecBit state.

If ZecBit disappeared, the infrastructure should still be usable by others.

  1. Mainnet dependency

ZIP 226/227 are still drafts, so we are not treating the current asset identity behavior as guaranteed.

ZMD-1 defines how asset_desc is constructed, not the final hashing rules of the protocol. If those rules change before mainnet, we adapt the implementation and version the spec.

The main assumption ZMD-1 needs is that asset_desc remains an issuer-controlled input committed to the asset identity.

  1. Escrow before ZIP 228

Until atomic settlement is available through ZIP 228, marketplace settlement should be treated as custodial. We will state that clearly.

The important distinction is that none of the grant-funded components require custody. ZMD-1, the indexer, and payment intake tooling work independently of whether marketplace settlement is escrowed or atomic.

  1. Ecosystem value

We would consider the grant successful even if ZecBit itself never became a large marketplace.

The metrics that matter are things like:

  • at least one external wallet or tokenizer implementing ZMD-1
  • at least two independent teams reviewing the spec
  • third-party reproduction of the indexer output
  • interoperability tests that work without ZecBit code

If other teams can use the standard and tooling without relying on us, then the infrastructure is doing what it was built to do.

1 Like