[Grant Proposal] Zcash Name Service

[craftsoldier]

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

[Shawn]

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.

[Michae2xl]

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.

[0xkivous]

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.

[craftsoldier]

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.

[craftsoldier]

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!

[artkor]

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?

[craftsoldier]

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.

[artkor]

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?

[emersonian]

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.

[ZCG]

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.

[palmar]

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:

@craftsoldier

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.

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:

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.