# \[Grant Proposal\] Zcash Name Service **URL:** \ **Category:** Applications\ **Created:** [May 19, 2026, 6:48pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737 "2026-05-19T18:48:48Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [May 19, 2026, 6:48pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/1 "2026-05-19T18:48:48Z")
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](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.zcash`instead of long Zcash addresses. [https://x.com/ZcashNames/status/2054668394369265831?s=20](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](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/298) Thank you for your consideration, Julian Engineer at ZcashMe ---
**Author:** ![Shawn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/shawn/32/187_2.png) [@Shawn](https://forum.zcashcommunity.com/u/Shawn)\ **Post date:** [May 19, 2026, 7:17pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/2 "2026-05-19T19:17:27Z")
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. ---
**Author:** ![Michae2xl](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/michae2xl/32/37337_2.png) [@Michae2xl](https://forum.zcashcommunity.com/u/Michae2xl)\ **Post date:** [May 19, 2026, 8:53pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/3 "2026-05-19T20:53:32Z")
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. ---
**Author:** ![0xkivous](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/0xkivous/32/44890_2.png) [@0xkivous](https://forum.zcashcommunity.com/u/0xkivous)\ **Post date:** [May 20, 2026, 1:04am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/4 "2026-05-20T01:04:53Z")
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. ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [May 20, 2026, 2:27am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/5 "2026-05-20T02:27:41Z")
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. ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [May 20, 2026, 2:35am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/6 "2026-05-20T02:35:00Z")
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! ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [May 22, 2026, 10:03am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/7 "2026-05-22T10:03:16Z")
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? ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [May 24, 2026, 4:53am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/8 "2026-05-24T04:53:31Z")
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. ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [June 12, 2026, 7:31am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/10 "2026-06-12T07:31:11Z")
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? ---
**Author:** ![emersonian](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/emersonian/32/42565_2.png) [@emersonian](https://forum.zcashcommunity.com/u/emersonian)\ **Post date:** [June 12, 2026, 12:47pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/11 "2026-06-12T12:47:14Z")
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. 🙂 ---
**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\ **Post date:** [June 12, 2026, 3:30pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/12 "2026-06-12T15:30:25Z")
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. ---
**Author:** ![palmar](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/palmar/32/44900_2.png) [@palmar](https://forum.zcashcommunity.com/u/palmar)\ **Post date:** [June 17, 2026, 9:06am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/14 "2026-06-17T09:06:21Z")
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](https://zips.z.cash/zip-1015) regarding open-source code and licensing: ![zip](https://global.discourse-cdn.com/zcash/original/3X/1/b/1b7fd6b4050958a5be0d9832688fc3bc15169616.png) 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. ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [August 9, 2026, 8:17am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/15 "2026-08-09T08:17:01Z")
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](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](https://github.com/zcashme/orchard) ### **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](https://github.com/zcashme/zns-mint) ### **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](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](http://crates.io/), wallets and other applications can use it to independently verify names, listings, and sales. - **Github:** [GitHub - zcashme/zns-verify · GitHub](https://github.com/zcashme/zns-verify) ### **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: > [@artkor](#): > > If name ownership becomes more durable and independently verifiable, then bad initial registrations may also become harder to correct later. 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](https://www.zcashnames.com/protected). Anyone can [suggest additional names for protection](https://www.zcashnames.com/protected/suggest), and protection decisions can be [disputed with supporting evidence](https://www.zcashnames.com/protected/dispute). 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](https://zcashnames.com/beta/apply). People on the waitlist will also be able to request access to protected names through our upcoming [reservation process](https://zcashnames.com/reserve). 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](https://www.zcashnames.com/docs/use/protected-names). Check out the links. Interested in your thoughts on our approach. > [@palmar](#): > > 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](https://zips.z.cash/zip-1015) regarding open-source code and licensing: 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](https://crates.io/users/craftsoldier)). We will post the next update no later than September 1. ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [August 25, 2026, 4:30pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/16 "2026-08-25T16:30:56Z")
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! > **[GitHub - zcashme/zns-whitepaper](https://github.com/zcashme/zns-whitepaper)** > > Contribute to zcashme/zns-whitepaper development by creating an account on GitHub. ---
**Author:** ![radbro](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/radbro/32/41148_2.png) [@radbro](https://forum.zcashcommunity.com/u/radbro)\ **Post date:** [August 25, 2026, 9:43pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/17 "2026-08-25T21:43:21Z")
I don’t know how to use email will you kindly consider me for radbro ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [October 1, 2026, 5:53pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/18 "2026-10-01T17:53:41Z")
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](http://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](https://github.com/zcashme/zns-whitepaper) ### **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](https://github.com/zcashme/orchard) ### **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](https://testnet.zecblock.com/name/zorgtest). **Status:** Complete on testnet. **GitHub:** [GitHub - zcashme/zns-mint · GitHub](https://github.com/zcashme/zns-mint) ### **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** - Resolver: [testnet.zecblock.com](https://testnet.zecblock.com/) - Explorer: [zcashnames.com/explorer](https://zcashnames.com/explorer) - Registration example: [`zorgtest`](https://testnet.zecblock.com/name/zorgtest) **Status:** Complete on testnet. **GitHub:** [GitHub - zcashme/zns-resolver: ZNS resolver: verifies name bindings and maintains a name → UA index. · GitHub](https://github.com/zcashme/zns-resolver) ### **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](http://crates.io/). **Status:** Deliverable is to publish the crate with passing tests and test vectors. **GitHub:** [GitHub - zcashme/zns-verify · GitHub](https://github.com/zcashme/zns-verify) ### **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](https://github.com/zcashme/zns-resolver) **Grant reference:** [Zcash Community Grants application #298](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/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. * * * ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [October 4, 2026, 10:44am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/19 "2026-10-04T10:44:04Z")
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](http://zcashnames.com/security) This is part of our security audit and bug bounty work under the ZCG grant. More updates soon! ---
**Author:** ![craftsoldier](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/craftsoldier/32/43096_2.png) [@craftsoldier](https://forum.zcashcommunity.com/u/craftsoldier)\ **Post date:** [October 8, 2026, 8:43am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/20 "2026-10-08T08:43:47Z")
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](https://www.zcashnames.com/security) ends on October 13th. ---
**Author:** ![radbro](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/radbro/32/41148_2.png) [@radbro](https://forum.zcashcommunity.com/u/radbro)\ **Post date:** [October 8, 2026, 9:43pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/21 "2026-10-08T21:43:01Z")
running radbro ---
**Author:** ![usezigs](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/usezigs/32/49380_2.png) [@usezigs](https://forum.zcashcommunity.com/u/usezigs)\ **Post date:** [October 12, 2026, 6:33pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737/22 "2026-10-12T18:33:17Z")
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 [Next page](https://forum.zcashcommunity.com/t/grant-proposal-zcash-name-service/55737.md?page=2)