• Overview
• Technical Stack
• Architecture
• User Flow
• Installation
• Deployed Contracts
• E2E Script Scenario
• References

ZK ID Policy Layer is a privacy-preserving modular on-chain policy layer.

In this repo, this ZK ID Policy Layer would be applied for RWA (Real World Asset) product's token issuance as one of use case.

Since the ZK ID Policy Layer is the modular on-chain policy layer, custom ZK Proof Verifier contracts (i.e. Accredition Proof Verifier, Age Proof Verifier, Residency Proof Verifier, etc) can be registered to the ZK Proof Verifier Registry contract. Those registered-custom ZK Proof Verifier contracts can be reused by RWA issuers to configure the eligibility and compliance rules as a policy for RWA buyers (RWA investors) - when the RWA issueres would create/issue a new RWA Product in the form of RWA Product token.

And then, it allow RWA issures to check whether RWA buyers is eligible for buying a RWA prodct and they are compliant or not without touching any sensitive data of RWA buyers by using Zero-Knowledge Proof.

• RWA buyer (RWA investor) prove their identity attributes with Zero-Knowledge Proofs - without revealing the sensitive personal (raw) data of RWA buyer on-chain.
• RWA issuer can mint only to the eligible and compliant buyers — without touching the underlying personal data of RWA buyer on-chain. For RWA issuer, they do not need to store any sensitive personal (raw) data of RWA buyer, which enable to bring the benefit of data minimization as well.

Key capabilities

                 +------------------------------+
                 |      Data Sources            |
                 | KYC / Bank / Workday / CEX   |
                 +-------------+----------------+
                               | zkTLS / API / Attestors (⚠️Limitation: This part has not been implemented yet)
                               v
                 +------------------------------+
                 |     ZK Circuit Library       |
                 |  accreditation / age /       |
                 |  credit-score / kyc-tier /   |
                 |  nationality / residency     |
                 +-------------+----------------+
                               | Noir -> UltraHonk proof
                               v
                 +------------------------------+
                 |        ZKIDRegistry          |
                 |  - nullifier storage         |
                 |  - per-user proof records    |
                 |  - on-chain verification     |
                 +-------------+----------------+
                               |
        +----------------------+----------------------+
        v                      v                     v
 +-------------+   +--------------------+   +--------------+
 |ZKProofVerif-|   |  RWAProductFactory |   |  RWAProduct  |
 |ierRegistry  |   |  - issuer approval |   |  - policy    |
 |(pluggable)  |   |  - product creation|   |    config    |
 +-------------+   +--------------------+   |  - mint()    |
                                            +--------------+

NOTE:

• ⚠️Limitation: The "Data Sources" part above has not been implemented yet. In the e2e script and frontend, the mock source data has been used instead of the actual source data. This part will be implemented using zkTLS protocols (i.e. Primus, NexaID, etc) in the future to retrieve the actual source data.

Each circuit follows the same pattern:

• private inputs hold the real credential values (Source data, which will be retrieved via zkTLS protocol, etc in the future. Currently, the mock source data is assigned to here)
• public inputs carry thresholds and the Poseidon nullifier hash.
  The on-chain verifier checks the proof and the registry prevents the same nullifier from being reused.

In this repo, the ZK Proof Layer is applied to the RWA product's token issurance.

• RWA issuer can choose the preferrable ZK Proof Verifier contracts (i.e. AccreditationVerifier.sol), which are registered by the Admin user.
• By choosing the 6 ZK circuits based ZK Proof Verifier contracts above, RWA issuer can check the following eligibility and compliance for RWA buyer (Investor).

        +------------------------------+
        |        Identity Layer        |
        |  - KYC verified              |
        |  - Human (not Sybil)         |
        +-------------+----------------+
                      |
        +-------------v----------------+
        |     Compliance Layer         |
        |  - Jurisdiction              |
        |  - Sanctions / AML           |
        +-------------+----------------+
                      |
        +-------------v----------------+
        |   Financial Eligibility      |
        |  - Balance / inflow          |
        |  - Portfolio size            |
        +-------------+----------------+
                      |
        +-------------v----------------+
        |   Investor Qualification     |
        |  - Accredited investor       |
        |  - Risk profile              |
        +------------------------------+

Three roles interact with the system: Admin, RWA Issuer, and RWA Buyer.

[ Admin ]                  [ RWA Buyer ]                [ RWA Issuer ]
     |                             |                          |
     | 1. Register ZKProofVerifier |                          |
     |    contracts to             |                          |
     |    ZKProofVerifierRegistry  |                          |
     |                             |                          |
     | 2. Approve issuer in        |                          |
     |    RWAProductFactory        |                          |
     |                             |                          |
     |                             | 3. Generate ZK proofs    |
     |                             |    (locally in browser / |
     |                             |     script)              |
     |                             |                          |
     |                             |           4. Create new RWAProduct
     |                             |              with required verifier
     |                             |              IDs + thresholds
     |                             |                          |
     |                             | 5. Submit proof batch    |
     |                             |    to ZKIDRegistry       |
     |                             |                          |
     |                             |<---------------------- 6. mint()
     |                             |    RWA token received    |
     |                             |    (only if all proofs   |
     |                             |     pass policy check)   |

Step details

1. Admin registers verifiers — Calls ZKProofVerifierRegistry.registerNewZkVerifier() for each auto-generated Verifier.sol, associating it with a sequential uint8 ID and human-readable threshold labels. (NOTE: Admin can add more new ZKProofVerifer contracts besides the 6 ZK circuits based ZK Proof Verifier contracts above by calling the ZKProofVerifierRegistry.registerNewZkVerifier().)

2. Admin approves issuer — Calls RWAProductFactory.approveIssuer() to whitelist the issuer address.

3. Buyer generates proofs — For each required credential (age, KYC tier, accreditation, etc.), the buyer runs the corresponding Noir circuit locally using @aztec/bb.js. Private inputs never leave the device.

4. Issuer creates product — Calls RWAProductFactory.createNewRWAProduct(), specifying required zkProofVerifierIds and threshold values. A new RWAProduct contract is deployed.

5. Buyer submits proofs — Calls ZKIDRegistry.submitProof() (or submitProofBatch()) for each proof. Each proof is verified on-chain; nullifier hashes are stored to prevent replay.

6. Issuer mints tokens — Calls RWAProduct.mint(buyerAddress, amount). The contract re-reads the buyer's stored proofs from ZKIDRegistry contract and checks every configured verifier's threshold before minting.

DEMO Video link: https://www.loom.com/share/d325a34398aa4ac48b917988f6b198b0

NOTE:

• ⚠️Limitation: The "Data Sources" part above has not been implemented yet.
  • Therefore, in the RWA buyer page (localhost:3000/buyer), the randomly generated mock source data has been used by clicking the "Generate Random Input Values" button in the ZK Proof Status panel - instead of the actual source data.
  • This part will be implemented using zkTLS protocols (i.e. Primus, NexaID, etc) in the future to retrieve the actual source data.

• Noir / Nargo (nargo CLI)
• Foundry (forge, cast)
• Bun (script runner)
• Node.js >= 20 (for the frontend)

git clone <repo-url>
cd ZK-ID-policy-layer

Compile each circuit and generate the on-chain verifier. Run the convenience script inside each circuit folder:

cd circuits

# Compile and build all circuits
sh compile-and-build-all-circuits.sh

Compiled artefacts are written to circuits/<name>/target/.
The auto-generated Verifier.sol files are written to circuits/<name>/target/Verifier.sol.

NOTE: Fancet for the HashKey Chain Testnet: https://faucet.hashkeychain.net/faucet

cd contracts

# Install Foundry dependencies
forge install

# Compile
sh compile-contracts.sh

# Deploy to HashKey Chain Testnet
sh scripts/deployments/hashkey-chain-testnet/deploy.sh

Copy the deployed contract addresses into contracts/.env:

cd contracts
cp .env.example .env

Then, adding your own private keys to the following 4 variables:

DEPLOYER_PRIVATE_KEY=<0x...>
ADMIN_PRIVATE_KEY=<0x...>
RWA_ISSUER_PRIVATE_KEY=<0x...>
RWA_BUYER_PRIVATE_KEY=<0x...>

NOTE: ADMIN_PRIVATE_KEY must be same private key with the DEPLOYER_PRIVATE_KEY in the ./contracts/.env file.

cd scripts
bun install

cd app
cp .env.example .env

Then fill in the required values in app/.env:

# Reown / WalletConnect Project ID (https://dashboard.reown.com/)
NEXT_PUBLIC_PROJECT_ID=""

# Salt values for ZK proof generation (required)
NEXT_PUBLIC_COMMITMENT_SALT="Your commitment salt here"
NEXT_PUBLIC_NULLIFIER_SALT="Your nullifier salt here"

The contract addresses and network configuration are pre-filled from .env.example. Then run:

npm install
npm run dev

Open http://localhost:3000.

Each script generates a ZK proof for a single circuit.
Script location: scripts/unit/circuits/<circuit-name>/generate-proof.ts

cd scripts

# Accreditation
bun run generate-proof:accreditation

# Age
bun run generate-proof:age

# Credit Score
bun run generate-proof:credit-score

# KYC Tier
bun run generate-proof:kyc-tier

# Nationality
bun run generate-proof:nationality

# Residency
bun run generate-proof:residency

Script location: scripts/e2e/e2e_zkp-generation-and-onchain-verification.ts
Run command:

cd scripts
bun run e2e:zkp-generation-and-onchain-verification

Script location: scripts/e2e/e2e_rwa-workflow.ts
Run command:

cd scripts
bun run e2e:rwa-workflow

The script exercises the full primary issuance lifecycle across three actor accounts (ADMIN, RWA_ISSUER, RWA_BUYER) read from contracts/.env.

The buyer account generates six proofs locally (using @aztec/bb.js UltraHonk backend) and submits each to ZKIDRegistry via submitProof():

For every proof, a Poseidon-based nullifier hash is computed from the credential values and a random salt, then included as the last public input. ZKIDRegistry stores the nullifier and rejects any duplicate submission.

The admin account calls ZKProofVerifierRegistry.registerNewZkVerifier() for each of the six auto-generated Verifier.sol contracts, associating them with sequential IDs (0-5) and threshold label metadata:

RWAProductFactory.approveIssuer(RWA_ISSUER_ADDRESS)

The issuer calls RWAProductFactory.createNewRWAProduct() with:

• name / symbol — token metadata
• zkProofVerifierIds — the subset of verifier IDs the product requires
  (e.g. [0, 2, 3, 4, 5] = Accreditation, Credit Score, KYC Tier, Nationality, Residency)
• zkProofVerifierThresholds — parallel array of threshold values per verifier

A new RWAProduct contract is deployed and its address is emitted in the event log.

RWAProduct.mint(RWA_BUYER_ADDRESS, amount)

mint() internally calls ZKIDRegistry contract to retrieve the buyer's stored proof for each configured verifier ID, re-runs the policy threshold check, and reverts if any check fails. On success, the buyer's balance is increased.

NOTE: ADMIN_PRIVATE_KEY must be same private key with the DEPLOYER_PRIVATE_KEY in the ./contracts/.env file.

All contracts are deployed on HashKey Chain Testnet (Chain ID 133).

• Click any address to view it on the HashKey Chain Testnet Explorer.
• Fancet of the HashKey Chain Testnet is here

ZK circuit:

• Noir Language Docs
• Aztec bb.js (UltraHonk backend)

Smart Contract:

• Foundry Book

HashKey Chain:

• Website
• Developer Docs
• Network info
• Fancet for the HashKey Chain Testnet: https://faucet.hashkeychain.net/faucet

Frontend:

• Reown AppKit (formerly WalletConnect)
• wagmi v2 Docs
• viem Docs