ZK NonFungibleDomains (ZKNFD)

Privacy-preserving credential NFTs for domain ownership on Aleo.

Comment

Inspiration

The rise of decentralized identity has always clashed with one major concern: privacy. While ENS and similar systems prove ownership on-chain, they also expose sensitive associations — domain-to-wallet links, metadata, and more.

This project was inspired by the question:
"Can we prove domain ownership without revealing the domain name itself?"
That idea led to zkDomain Credentials — a fully private, zk-native solution.

What it does

zkDomain Credentials is a privacy-preserving identity credentialing system built on the Aleo blockchain. It allows users to mint verifiable NFTs that prove they own a domain name — all without revealing the domain publicly. These Credential NFTs are issued as ZKPasses, representing proof of domain ownership using zero-knowledge proofs.

The project combines:

  • Aleo Name Service (ANS) for decentralized domain name registration,
  • ZKPass for issuing private, Merkle-based identity credentials,

“We wanted to bridge digital identity, privacy, and ownership — and domain names were the perfect anchor. This project proves you own something, without showing the world what that thing is.”

How we built it

This project was built using the Leo programming language and deployed on Aleo's zero-knowledge blockchain.

🔗 Components Integrated:

  • aleo_name_service_registry.aleo: For secure domain registration and metadata.
  • zpass_merkle_8.aleo: To construct a Merkle tree representing identity traits, and issue ZPass records. With your use of the ZPass SDK, the Merkle root calculation and signature generation off-chain, letting the Leo contract focus only on verifying the inputs and minting the ZPass record.

Challenges we ran into

  • Mapping multiple zk systems into a single transition required complex reasoning around hashes, Merkle trees, and data types.
  • Debugging with Leo's evolving toolchain meant we had to manually simulate some logic before testing on-chain.
  • Ensuring cross-contract compatibility and matching data structures took detailed planning.
  • Constructing verifiable but private proofs without leaking metadata took careful Merkle root construction.

Accomplishments that we're proud of

We wrote a custom Leo program called zknonfungibledomains.aleo that:

  1. Verifies the caller’s domain ownership.
  2. Generates a ZKPass using the Merkle root of identity + domain data.
  3. Mints a Credential NFT that’s private by default but verifiable.

What we learned

  • How to build modular zkApps using Leo and deploy to Aleo.
  • Advanced concepts in zero-knowledge Merkle proofs, commitment schemes, and record management in Aleo.
  • How to write interoperable zk programs that link NFTs, names, and identity in a seamless UX.

What's next for ZK NonFungibleDomains (ZKNFD)

This is more than a hackathon project. The same mechanism can be used to:

  • Prove ownership of domains in anonymous DAOs.
  • Provide credentials for Web3 onboarding or gated access.
  • Issue privacy-first soulbound identity badges — all powered by Aleo.

We’re excited to keep building and invite collaborators to join in.

Built With

  • leo
Share this project:

Updates

posted an update —

Final Project Update: ZK NonFungibleDomains (ZKNFD)

We’re excited to announce that ZKNFD has been deployed live on Aleo mainnet this was following tests made locally using CLI and fully aligned with the Aleo NFT Standard (ARC-721). The program supports privacy-preserving, soulbound credential NFTs for domain ownership, and integrates with the ZPass signature system.

Deployment Details

  • Program Name: zknonfungibledomains_v1.aleo
  • Program ID: zknonfungibledomains_v1.aleo
  • Program Address: aleo1le9uklfd948egtdjuyra8afh85gu5n7xx3g7k7tpwe3gyhcc6cqsdjzgky
  • Deployment TX: at1tt4q0c0fzupe600dv5vpp44gttxl3le748mhavfnehmcp8gshq8smu9cq4
  • Program Owner: aleo14yhka0p8mxpwvzu4gmz93kxwywsdjak6df3t3xzlku73yq8qhyqq0zgere
  • Owner Signature: sign1erg3y042lp2y0cvgv0lqx25az52pmux9hzaxqyfqfl98nwsrrvp5am83gmmmyckpal3ttyhals3lu8wneu3hqufdylh4tjsp0fuduqw4ww5x2hv6544dlvujjz3xqjfaxl7yaampwhqcw0agqjfh36zhpaq4wvjn56faq7gyz5uya8v5k0eszu0wevldxgaf34m2k0ukmj6qgnmyxty

Features & Functional Coverage

Privacy-Preserving NFT Credentialing

  • Mints a private CredentialNFT to the domain owner.
  • Credential metadata (like domain hash) and ownership are entirely private.

ZPass Integration

  • Signature-based credential issuance with off-chain Merkle root signing using the ZPass SDK.
  • Includes Merkle proof verification logic via verify_domain_credential.

ARC-721 Standard Alignment

  • Structs and transitions follow the standard for NFT privacy and uniqueness:
    • CredentialNFT: private record
    • nft_commits: ensures uniqueness of minted credentials
    • nft_owners: optional public tracking
  • Fully compliant with Aleo NFT bounty criteria.

Designed for the Following Use Cases

Use Case Supported
Prove domain ownership in anonymous DAOs
Provide credentials for Web3 onboarding or gated access
Mint soulbound ZK identity badges based on domain control

Planned Post-Submission Features

  • Add transfer_private_to_public + NFTView for DAO visibility.
  • Add publish_nft_content for marketplaces needing readable metadata.
  • Add public registry and event hooks.

ZKNFD is not just a hackathon project — it’s a framework for ZK identity and domain-linked reputation in Aleo’s privacy-first ecosystem.

See you on-chain

Log in or sign up for Devpost to join the conversation.

posted an update —

ZKNFD Update: Aleo NFT Standard Integration

We’ve officially aligned our contract with the Aleo NFT Standard (ARC-721) to qualify for the $5,000 NFT Bounty sponsored by Capncrunch (zSociety).

What’s New in ZKNFD

NFT Standard Compliance

Our CredentialNFT now follows the ARC-721 structure:

  • Private ownership (private owner)
  • Private metadata (private data)
  • Unique edition commitment (scalar edition)
  • Public identifier via commit_nft(data, edition)

This ensures:

  • Privacy of NFT ownership
  • Privacy of domain metadata
  • Uniqueness enforcement using nft_commits

ARC-721 Functional Highlights

  • commit_nft(...): hashes the data struct, then commits it using edition
  • nft_owners: tracks public owners of private credentials
  • nft_commits: prevents duplicate credentials (ensures 1-of-1 issuance)

Transition Breakdown

issue_domain_credential(...) (async)

  • Accepts a domain, its parent, a signed Merkle root, and an issuer
  • Verifies the root and signature using Aleo's signature::verify
  • Creates a private NFT conforming to ARC-721
  • Writes public mappings for future transfer, verification, and registry

verify_domain_credential(...)

  • Verifies any Merkle leaf against the domain credential’s root
  • Zero-knowledge proof verification for domain-linked identity claims

Why This Matters for the NFT Bounty

  • Private ownership and private data are first-class citizens
  • Fully compatible with ARC-721’s marketplace, registry, and transfer extensions
  • Prepares the path for future features like transfer_private_to_public, approve_public, and publish_nft_content

Next Steps

  • Add NFTView for optional public visibility of NFT data
  • Support transfer_public_to_private and approval flow
  • Deploy a verifier or registry UI connected to the minted credentials

This update locks ZKNFD in as a strong contender for the NFT Bounty by integrating native Leo privacy features into domain credentials — a real, usable NFT use case that couldn't be built anywhere but Aleo.

Log in or sign up for Devpost to join the conversation.

posted an update —

Project Update: ZK NonFungibleDomains (ZKNFD)

After several iterations, we’ve streamlined the ZKNFD Leo program to be fully self-contained, efficient, and SDK-compatible. Here's what's new in the final version:

Final Design Highlights

Self-Contained Leo Contract

Our program no longer relies on external Aleo Name Service contracts. Instead:

  • We inline the TokenId struct and use it to reconstruct the domain hash.
  • We verify domain ownership using a public nft_owners mapping.
  • We keep the CredentialNFT and DomainZPass issuance logic lean and readable.

Simplified On-Chain Logic

The Leo program now expects:

  • A valid signature from the issuer (signed off-chain with the ZPass SDK),
  • The Merkle root representing the credential,
  • The domain name split into 4 u128 parts + parent,
  • An issuer address.

All ZK processing — including leaf hashing and Merkle tree construction — is done off-chain via the SDK.

ZKPass SDK Integration

We’ve confirmed compatibility with the ZPass SDK:

  • Signature generation with signMerkleRoot()
  • Merkle tree leaf hashing with getLeavesHashes()
  • Credential issuance via issueZPass() using the contract’s issue_domain_credential transition

This enables smooth frontend-to-chain interaction.

Final Verification Function

The contract includes a native Merkle path verifier:

transition verify_domain_credential(
    zpass: DomainZPass,
    leaf_hash: field,
    proof: [field; 3]
) -> bool

Log in or sign up for Devpost to join the conversation.