[Grant Proposal] Zcash Name Service

Community Grants Applications
1

We’re seeking support to take ZcashNames from a working beta to a more trust-minimized system before production.

We launched the ZcashNames waitlist about 50 days ago, and more than 1300 people have already joined. Since then, we completed a public beta test of our infrastructure, collected feedback, and addressed the main issues users and developers raised.

https://x.com/ZcashNames/status/2052521176841494552?s=20

Wallets are already adopting our SDK, and users have been happy with the experience of using names like alice.zcashinstead of long Zcash addresses.

https://x.com/ZcashNames/status/2054668394369265831?s=20

We are now preparing our next beta, which will feature our non-custodial solution for selling names.

The remaining concern is trust. Some community members have pointed out that users should not have to rely on our servers when resolving names. This grant funds the work to reduce those trust assumptions.

Our technical approach is to make name bindings verifiable on-chain. Instead of asking users to trust our resolver database, ZNS will create special Orchard notes that commit to the name, address, operation, and history of each binding. Wallets and apps can then use zns-verify to check those proofs directly.

This is made possible by the rcm field in every Orchard note. It is a 32-byte scalar that randomizes the note’s commitment. ZIP 212 says wallets sample this randomly, but ZNS will replace that randomness with a structured hash of the registration itself:

\rcmσ=ToScalar(BLAKE2b-512(T‖“rcm”‖σ)),ψσ=ToBase(BLAKE2b-512(T‖“psi”‖σ))

where

σ=(α,n,u,p) encodes the operation α, the name n, the target address u, and the predecessor reference p.p is zero for a fresh CLAIM.

For any mutation, p is the prior Name Note’s rcm so that the name’s history can be sequenced. T = "ZcashName/v1" is the domain tag, and ToScalar/ToBase are the standard Pallas field reductions.

The Orchard note commitment that lands on chain is therefore:

cmx=SinsemillaCommit\rcmσ(gd,R∗‖pkd,R∗‖vR‖ρ‖ψσ).

We call this a Name Note. It is a chain-anchored cryptographic photograph of σ itself.

These Name Notes are fully consensus-valid Orchard outputs that full nodes can mine like any other.

Because their (\rcm,ψ) are not sampled per ZIP 212, a regular wallet’s trial decryption rejects them as malformed. Only the Registry’s minter and Resolvers running the published ZNS scanner see Name Notes for what they are.

Finally, we will host the Mint in a Trusted Execution Environment and provide attestations. With our improved Resolver, we will publish verification tools, ship SDKs, run an audit and bug bounty, and support partners through mainnet launch.

We want to make Zcash easier to use while giving users cryptographic proof of name bindings instead of asking them to trust our database.

For more details, please visit our Grant Application on Github: https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/298

Thank you for your consideration,

Julian
Engineer at ZcashMe

6 Likes
Zcash Community Grants Meeting Minutes 05/25/2026
Zcash Community Grants Meeting Minutes 6/8/2026
ZCashNames — human-readable names for Unified Addresses, live on mainnet (fair launch, no pre-registration)
Zcash Community Grants Meeting Minutes 6/22/2026
ZCashNames — human-readable names for Unified Addresses, live on mainnet (fair launch, no pre-registration)
2

What is the plan for the proceeds of the initial sale of the names? I assume your team will setting initial pricing for names and also be taking a fee of peer to peer sales on your platform?

It seems that may be a better source of income (and beyond) to support this $92,000 integration rather than have the community bootstrap a for profit enterprise.

7 Likes
3

Hi Julian!

While the proposed trustless infrastructure is technically promising, there is a stark disconnect with your commercial referral campaign, which has already led two Brazilian community members to collect over 65 names based on promotional promises.

To protect their effort from bearing the brunt of your commercial risk, the community needs concrete answers beyond standard defenses.

First, if you argue that referral payouts will be funded entirely by future revenue share rather than ZCG funds, what specific guarantees do these early adopters have if initial sales underperform?

Second, if the grant is denied, simply delaying the project via “bootstrapping” freezes their unpaid work indefinitely; what is your exact timeline to honor these financial expectations?

Finally, if you intend to enforce the “early access” queue by using a temporary, centralized whitelist during the genesis mint, you must clarify how injecting a trusted bottleneck at the most critical phase does not fundamentally compromise the trustless, on-chain integrity you are asking the community to fund.

6 Likes
4

Really like the idea, I also remember there was a post in 2021 that briefly touched upon this. Glad to see that this is now in the works.

1 Like
5

Hi Shawn,

Thank you very much for the questions!

I think a few points are worth clarifying:

First, $50,000 of the funding request is specifically reserved for an external audit and bug bounty program. That portion does not go to our team at all. It’s there to make sure the integration is secure before anything goes live.

Second, to protect users and secure the namespace, we believe that the integration and audits should happen before the official launch and before people are asked to buy names at full price.

Also, it is not unusual to see ecosystem grants funding work involving for-profit companies. We do reserve the right to donate portions of proceeds from name sales back to the community. It could be an alternative form of ecosystem funding over time.

A big part of why we shared this proposal publicly was also transparency. We want to share our roadmap, our thinking, and how we’re approaching the rollout so the community can evaluate it, question it, and give feedback early instead of after decisions have already been made.

Appreciate you raising the concern and starting the discussion.

1 Like
6

Hi Michael, thanks for the questions!

Do you mean that someone has convinced 65 other people to join the waitlist. This is good!

About their referral rewards, payouts are only generated after the referred users completes a purchase during the early access period. If a referred user does not purchase a name, no payout is owed. If they do purchase, the payout is funded by that purchase. Therefore, referral rewards do not create an unfunded liability. The full terms are listed on our website.

Basically, the early access waitlist is just a distribution mechanism for names.
But this grant has a different focus: minimizing trust assumptions in the resolver infrastructure that applications use to map names to addresses. If the grant is denied, the project would simply move more slowly. But the referral terms still remain the same!

Still, we want to make name distribution as fair as possible so we are certainly open to any suggestions. We really believe that the waitlist program helps avoid a bot-dominated launch where squatters capture the namespace. Perhaps futher discussion about early access waitlist warrants a separate thread so this discussion can stay focused on the grant’s actual scope and technical objectives.

I appreciate you pushing for clarity. Does this answer your questions? Thank you for your support!

1 Like
7

Since I follow a number of Zcash-related repositories, I have already noticed that Edge, Zingo!, and Unstoppable have announced or started adding support for ZNS. What is not fully clear to me is how this support is being achieved today. Is the current integration based on the existing trusted infrastructure?

If I understand the new proposal correctly, the next phase is intended to reduce that trust assumption, but it also seems to involve a much more protocol-adjacent design, including non-standard Orchard notes. That makes the main question for me whether this direction is likely to be supported by the Zodl-wallet team.

@joshs, could you please share your thoughts on this? Do you see ZNS as something Zodl would realistically want to support?

2 Likes
8

You’re understanding the current integration correctly. Right now, the name service is running on trusted infrastructure. That’s why the names being registered today are temporary as part of beta testing.

Before we officially launch, we will minimize the trust assumptions as much as we possibly can.

Whether Zodl ultimately supports us will depend on Josh and the wallet team. Our goal is to meet the standards they expect for integration.

Hoping to get a chance to speak about ZcashNames design and perform a demo at ZODL summit.

1 Like
10

The Committee is still reviewing this proposal. We had originally expected to wait for the retroactive grants voting results before making a final decision, in order to avoid cross-subsidization or related complications. Since that vote has been moved to a later date, we now need to move toward a decision on this proposal directly.

There is one remaining issue that I think deserves more discussion. If ZNS becomes part of Zcash payment infrastructure, the whole community has an interest in making sure the initial name allocation is not abused.

One important protection to consider is a staged transition from the current beta model to the trust-minimized registry.

If name ownership becomes more durable and independently verifiable, then bad initial registrations may also become harder to correct later. A reasonable approach could be to keep newly registered names in a provisional state for a meaningful challenge period before they become finalized in the trust-minimized registry. For sensitive or high-risk names, this period could be long. Potentially up to 36 months (my personal opinion).

During that period, clear cases of impersonation, squatting, typosquatting, or bad-faith registrations could be reported and reviewed. Only names with no valid dispute would then move into the finalized, independently verifiable state.

This would preserve the benefit of the trust-minimized design while reducing the risk of permanently locking in abusive registrations too early.

If ZCG funds this work, I think it would be important to include some protection of this kind for the community.

What do you think about this approach?

1 Like
11

Though I really like the people behind this project, I firmly oppose the use of community funds for this. It is a centralized tech startup and should seek venture capital.

I also believe that a fully decentralized approach to usernames should be the default on Zcash.

Having multiple usernames/“TLDs” on Zcash is an inevitability, like with Ethereum’s ENS and Unstoppable Domains having healthy competition.

I think this team can crush it by seeking private equity instead of using community funds. Again, they’re awesome. :slight_smile:

12

ZCG has voted to approve this proposal. Congratulations!

ZCG requests that you provide monthly updates via the forum in this thread.

Please lookout for a Forum DM from FPF with important grant information. Thanks.

1 Like
14

ZNS is a very valuable tool that could play an important role in Zcash’s adoption. I participated in the beta test and I find the team to be professional and highly committed, so I wish them every success.

However, I wonder whether the comments from Shaw and emersonian in this thread were taken into account, as they raise some points that would be good to highlight:

I have a question for craftsoldier regarding the paragraph quoted above:

Since ZNS is a private for-profit initiative developing a product that will be sold to the Zcash community, I wonder whether the project is following the guidelines specified in ZIP-1015 regarding open-source code and licensing:

zip
zip1422×252 32.3 KB

I’m asking because craftsoldier’s comment about giving back to the community refers to donating a portion of the profits from name sales, but I didn’t see anything about releasing all the tools developed with ZCG funds so that they are available to the community and can be used to implement other projects. It’s probably the case, so I’m just requesting clarification.

1 Like
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
16

Zcash Name Service whitepaper is released.

It covers the protocol spec, test vectors, memo grammar, name canonicalization, and the assumptions behind the attested registry design.

This completes Deliverable 1 of our ZCG grant. More updates soon!

1 Like
17

I don’t know how to use email will you kindly consider me for radbro

1 Like
18

We are getting close to launching ZNS. Early access is planned for October 15.

The ZNS SDK is already integrated with Zingo, Edge, Cake, Noir, Zucchini, ZecBlock, ZDEX, Cyze, and others. These wallets and applications will not need another update to keep name resolution working.

We’re sharing our completed ZNS milestones and requesting payment under our Zcash Community Grants agreement.

Reserve your name at zcashnames.com/reserve to join the early access period!

Milestone 1: Whitepaper

The ZNS whitepaper defines how a name becomes a chain-anchored proof, including the transition tuple σ = (α, n, u, p), tagged BLAKE2b derivations of rcm_σ and ψ_σ, the Name Note construction, and the trust model for the attested Mint.

What’s in the repo

  • Full ZNS protocol specification covering requests, Name Notes, the Mint, authorization, resolution, trust assumptions, and privacy.
  • Name Note test vectors and request memo grammar for the request, relay, and response flow.
  • Access-code restrictions for protected names.
  • Canonical name rules: alphanumeric names only, with hyphens disallowed to avoid ambiguity.

Status: Complete. Published August 25, with later updates for consistency fixes, access-code wording, and security review findings.

GitHub: GitHub - zcashme/zns-whitepaper · GitHub

Milestone 2: Orchard ZNS fork

Ironwood introduces ψ and changes how rcm is derived for Name Notes.

What’s in the repo

  • Public Orchard fork with structured note randomness behind the unsafe-zns feature flag.
  • Builder::add_zns_spend and Builder::add_zns_output accept registration-derived (rcm_σ, ψ_σ) values instead of ZIP 212-sampled values.
  • Note::zns_cmx and Note::zns_nullifier let wallets and resolvers recompute a Name Note’s commitment and nullifier.
  • ZnsIronwoodDomain detects Name Notes through full, compact, and batched decryption paths. Regular wallets continue to reject them.

Status: Complete and used in ZNS applications. Releases: zns-orchard-v0.15.5 on August 8 and zns-orchard-v0.15.5.2 on September 4.

GitHub: GitHub - zcashme/orchard: Implementation of the Zcash Orchard Protocol · GitHub

Milestone 3: Registry / Mint

A Name Note proves that a name is bound to an address. The Mint validates claims, confirms controller ownership, enforces canonicalization, and mints Name Notes.

Regular wallets cannot construct or decrypt Name Notes because (rcm_σ, ψ_σ) come from registration rather than ZIP 212 sampling.

What’s available

  • The Mint runs in an AMD SEV-SNP confidential VM with measured boot.
  • Its spending key is generated inside the enclave and can only be decrypted by an attested Mint binary.
  • Zebra runs in the same guest, so chain traffic and key material stay inside the enclave boundary.
  • The Mint has been live on testnet since September 30 and scans blocks for Name Note requests.
  • The zorgtest registration shows the full flow: testnet.zecblock.com/name/zorgtest.

Status: Complete on testnet.

GitHub: GitHub - zcashme/zns-mint · GitHub

Milestone 4: Resolver

The resolver scans the Zcash chain for ZNS Name Notes, verifies bindings, and indexes current records and event history.

JSON-RPC API

  • resolve for name lookup, registered-name listing, and address lookup.
  • list_names for paginated name listings.
  • reverse_lookup for names associated with an address.
  • status for indexed height and sync status.
  • events for claim, update, and release history.

Testnet

Status: Complete on testnet.

GitHub: GitHub - zcashme/zns-resolver: ZNS resolver: verifies name bindings and maintains a name → UA index. · GitHub

Milestone 5: Rust verification crate

The verification crate lets wallets and applications verify ZNS name bindings, listings, and sales using chain data and public test vectors.

What’s included

  • Rust APIs: verify_name(...), verify_listing(...), and verify_sale(...).
  • Protocol test vectors.
  • Tests for valid, invalid, and tampered data.
  • Publication on crates.io.

Status: Deliverable is to publish the crate with passing tests and test vectors.

GitHub: GitHub - zcashme/zns-verify · GitHub

Milestone 6: Wallet SDKs and partner integration

This milestone provides reusable ZNS integration packages for wallets and applications.

What’s included

  • TypeScript package and native Rust bindings.
  • Integration documentation and support for wallet developers.
  • SDK packages published and provided to wallet and application partners.

Status: Deliverable is to publish the TypeScript and Rust packages and provide them to partners.

GitHub: GitHub - zcashme/zns-resolver: ZNS resolver: verifies name bindings and maintains a name → UA index. · GitHub

Grant reference: Zcash Community Grants application #298

We are also requesting funding for Milestone 7 to support the external audit, bug bounty program, and review of the Mint, resolver, SDK, verification code, and trust model. Previously released code may change based on findings and recommendations during the audit period.

3 Likes
19

We have launched the ZNS Mint security competition and hunting is live! Competitors have a 10-day window to find vulnerabilities in the Mint before mainnet launch.

The main pool is 8 ZEC, unlocking based on the highest-severity valid finding, with a 2 ZEC side pool for accumulated points.

Submission rules, severity tiers, and report acceptance criteria are listed at Security Competition - Zcash Names

This is part of our security audit and bug bounty work under the ZCG grant. More updates soon!

20

ZNS Audit Update

We have engaged Strahn Cryptography(@strahncryptography) to perform an external security audit of Zcash Names.

The audit covers the ZNS mint, resolver, verification, and key generation components, with the objective of identifying security vulnerabilities across the protocol.

The audit commenced on October 7, with the final report scheduled for delivery by October 21.

We will be addressing findings in real time throughout the audit process as they are identified and communicated to us.

As part of the engagement, Strahn Cryptography will provide a security audit report covering identified vulnerabilities, severity, potential risks, edge cases, and recommended remediation. The engagement also includes re-testing following remediation.

We’ll share the results with the community once the audit and remediation process is complete.

PS: Our security competition ends on October 13th.

2 Likes
21

running radbro

1 Like
22

Hey @craftsoldier , great work overall! We’re building Zigs (@usezigs), a multisig wallet for Zcash, and we’re actually exploring building our own naming service.

Our current design is a .zig namespace with a minimal open-source registry program on Solana. Solana only acts as the canonical state/ownership layer: name -> owner/controller + resolution commitment. Registration is one-time, names don’t expire, ownership is transferable, and resolution state can be updated independently of ownership.

The important bit for us is keeping the registry dumb. It shouldn’t custody anything or be required to process Zcash payments. Zigs resolves the name client-side and the actual payment happens shielded on Zcash. We’d also want anyone to be able to index the registry and implement their own resolver rather than treating our API as authoritative.

We’d rather not create .zig if ZNS already gives us equivalent properties though.

Three things I’m still trying to understand from the docs/thread:

  1. Privacy: What exactly is observable when a name is registered/resolved/updated? In particular, can the payment receiver behind alice.zcash be rotated without creating a public graph linking the old and new receivers to the same identity?
  2. Verification: Is the complete name -> current resolution state independently derivable/verifiable from Zcash chain state? i.e. could we run our own indexer/resolver from genesis and arrive at the same state without trusting ZNS infrastructure?
  3. Wallet integration: Can we implement the full lifecycle directly inside Zigs — register, resolve, update and transfer — using the protocol/SDK, without requiring the user to interact with the ZNS frontend or a ZNS-operated service?

If the answer to these is basically yes, I’d much rather implement ZNS than ship another naming protocol. Would love to open a chat to discuss further