[Grant Proposal] Zcash Name Service

Community Grants Applications
15

We want to share an update on the current status of the ZNS deliverables and the remaining work toward beta and mainnet deployment.

The milestone deliverable work is progressing, with several components complete. The remaining work is concentrated around deployment and testing of the Registry / Mint service, SDK implementation, external audit, and beta/production rollout.

Part of the ZNS timeline shifted because we deferred some development while Ironwood was still evolving. ZNS relies on controlled note randomness, and Ironwood changes how rcm is derived by introducing ψ and incorporating more of the note contents. As the design evolved, we updated the transaction-building, wallet integration, and verification paths in parallel with each release. That work is now converging on the finalized design and is reflected in the SDK, testing, and audit milestones that remain.

Our current target for the broader beta and launch milestone is September 15.

Deliverable Status

D1: Whitepaper

  • What ships: Final spec, test vectors, memo grammar, and name canonicalization rules.
  • Status: In progress (90%)
  • Notes: Currently drafted. We will add relevant TEE assumptions and migration considerations.
  • Github: https://github.com/zcashme/zns-whitepaper

D2: orchard-zns fork

  • What ships: Public orchard fork with structured note randomness override, passing cargo test, and upstream PR filed.
  • Status: Implementation complete (100%)
  • Notes: The required transaction construction flow is available, including support for wallets or custom builder code supplying their own RCM and signing transactions.
  • Github: GitHub - zcashme/orchard: Implementation of the Zcash Orchard Protocol · GitHub

D3: Registry / Mint

  • What ships: TEE-hosted name-minting service with enclave-generated spending key and public attestation.
  • Status: Development largely complete; deployment/testing remaining (90%)
  • Notes: Remaining work is primarily deployment, verification, testing, and finalizing operational considerations around TEE migration/recovery scenarios.
  • **Github:**GitHub - zcashme/zns-mint · GitHub

D4: Resolver

  • What ships: HTTP service for name → address resolution and listings on testnet and mainnet.
  • Status: In-progress (90%)
  • Notes: Must be adapted for Ironwood.
  • Github: https://github.com/zcashme/zns-resolver

D5: zns-verify

  • What ships: Rust crate with verify_name(...), verify_listing(...), verify_sale(...), and test vectors.
  • Status: Complete (100%)
  • Notes: The verification crate and test vectors are complete. Once published on crates.io, wallets and other applications can use it to independently verify names, listings, and sales.
  • Github: GitHub - zcashme/zns-verify · GitHub

D6: SDKs

  • What ships: TypeScript/WASM package, native Rust bindings, and wallet integration support.
  • Status: In-progress (40%)
  • Notes: Existing SDK work provides groundwork, but a zns-verify specific SDK deliverable has not yet been implemented.

D7: External audit

  • What ships: Independent review of orchard-zns, Registry / Mint, Resolver, zns-verify, SDKs, and TEE assumptions, with findings addressed before launch.
  • Status: Not started (0%)
  • Notes: Audit work will begin after the components in scope are published.

D8: Beta and launch

  • What ships: Private testnet beta, public mainnet beta, partner SDK delivery, and production mainnet deployment.
  • Status: Not Started (0%)
  • Notes: We are currently targeting September 15 for this phase. Audit findings must be addressed before production launch.

Now, to address some of your questions:

We agree with the concern. The tradeoff is that if we want name ownership to be real, there cannot also be an administrative mechanism for reversing a registration later.

So our approach is to address these risks before a protected name is claimed.

For example, sensitive names are added to the protected list. Anyone can suggest additional names for protection, and protection decisions can be disputed with supporting evidence. A dispute triggers a review, where an admin accepts or dismisses it. All of this is public.

When someone requests access to claim a protected name, we manually verify that they are actually associated with that identity. The process is similar to how Twitter historically verified accounts before issuing checkmarks.

For example, if someone wanted to claim zooko, we would look for evidence that they control other accounts or channels publicly associated with Zooko. If that checks out, we can provide the claim access code through one of those established accounts. You can see the current claim process in our beta program. People on the waitlist will also be able to request access to protected names through our upcoming reservation process.

Once a protected name has been properly claimed, it can no longer be disputed through this process. From that point forward, ownership is determined by the protocol and the wallet that controls the name.

We agree that impersonation, typosquatting, bad-faith registrations, and similar cases need to be addressed. We think it should happen before ownership is finalized, through protected names, community suggestions, disputes, and identity verification, rather than through a long provisional period after registration.

More detail on the current model is here: Protected Names.

Check out the links. Interested in your thoughts on our approach.

Yes, all our code is currently open sourced using the MIT license. You will be able to independently verify that our code published on GitHub is the exact same code that is used in production.

In addition to the software developed as part of this grant, ZcashNames is committed to helping developers build applications on Zcash and has open-sourced tools created for internal use (crates.io: Rust Package Registry).

We will post the next update no later than September 1.

4 Likes