# ZK Ownership Proof

The ZK ownership proof allows a user to prove they own a vaulted asset without revealing which specific asset they own. This is implemented as a Noir circuit verified by a Solidity contract.

## What It Proves

> "I own a coin in this vault set" -- without revealing which coin.

The proof demonstrates:

1. The prover knows a `user_secret` and `asset_commitment` that produce a valid leaf.
2. That leaf is included in the ownership Merkle tree (whose root is public).
3. The `nullifier` is correctly derived from the prover's secret, preventing proof reuse.

## Circuit Design

```
Public inputs:
  ownership_root (Field)  -- Merkle root of all ownership commitments
  nullifier (Field)       -- prevents double-use of proof

Private inputs (witness):
  user_secret (Field)          -- user's private key/secret
  asset_commitment (Field)     -- hash of the owned asset details
  merkle_path (Field[16])      -- sibling hashes in the Merkle path
  merkle_indices (Field[16])   -- left(0)/right(1) indicators
```

### Constraints

```
1. leaf = pedersen_hash(user_secret, asset_commitment)
2. assert nullifier == pedersen_hash(user_secret, ownership_root)
3. Walk Merkle path from leaf to root using pedersen_hash
4. assert computed_root == ownership_root
5. assert all merkle_indices are binary (0 or 1)
```

### Tree Depth

The Merkle tree has depth 16, supporting up to 65,536 asset commitments.

## Hash Function

The circuit uses **Pedersen hash** (native to the Barretenberg proving backend). Pedersen is chosen because:

* It has very low constraint count in arithmetic circuits.
* It is native to the BN254 curve used by Barretenberg.
* It is deterministic and collision-resistant.

Note: Pedersen hash is different from keccak256. The ownership root stored on-chain is a Pedersen Merkle root, stored as an opaque `bytes32`. See [Hash Conventions](/numex-docs/technology/hash-conventions.md) for the full hash boundary map.

## Verification Flow

```mermaid
sequenceDiagram
  participant User
  participant Prover as Prover (client/backend)
  participant Contract as NumexRegistryV3
  participant Verifier as ZK Verifier

  User->>Prover: Request proof (user_secret, asset_commitment)
  Prover->>Prover: Build Pedersen Merkle tree of ownership set
  Prover->>Prover: Compute leaf, nullifier, Merkle path
  Prover->>Prover: Generate ZK proof (Barretenberg)
  Prover->>Contract: verifyOwnership(root, nullifier, proof)
  Contract->>Contract: Check root == ownershipRoot
  Contract->>Verifier: verifyProof(root, nullifier, proof)
  Verifier->>Verifier: Pairing check (BN254)
  Verifier-->>Contract: true/false
  Contract-->>User: Ownership verified
```

## Implementation

| Component                    | Location                                       | Status                       |
| ---------------------------- | ---------------------------------------------- | ---------------------------- |
| Noir circuit                 | `contracts/zk/ownership/src/main.nr`           | Implemented, 5 tests passing |
| Compiled artifact            | `contracts/zk/ownership/target/ownership.json` | Generated                    |
| TypeScript proof test        | `scripts/verify/check-zk-ownership-proof.ts`   | 6 tests passing              |
| Solidity verifier interface  | `IOwnershipVerifier`                           | Defined                      |
| Verifier stub                | For testing without full verifier              | Available                    |
| Registry integration         | `verifyOwnership` on registry                  | Implemented                  |
| Production Solidity verifier | UltraPlonk verifier from Noir circuit          | Deployed                     |

## Use Cases

* **Private portfolio attestations:** "I hold at least N coins worth X" without revealing which coins.
* **Gated access:** Prove ownership of a premium coin to access collector features.
* **Privacy-preserving insurance:** Prove ownership for coverage without revealing specific holdings.
* **Anti-front-running:** Prove you own a coin before revealing which one in a trade.

## Trusted Setup Caveats

The Noir/Barretenberg backend uses UltraPlonk, which requires a Structured Reference String (SRS). The development SRS is suitable for testing but a production deployment should verify:

1. The SRS was generated through a trusted ceremony.
2. The SRS is large enough for the circuit size.
3. No single party knows the toxic waste.

Barretenberg uses an SRS derived from the Aztec Connect ceremony, which is suitable for production use.

## What Is Live vs. Development

| Feature                         | Status                       |
| ------------------------------- | ---------------------------- |
| ZK circuit (Noir)               | Implemented, tested          |
| Proof generation (JS backend)   | Working                      |
| Proof verification (JS backend) | Working                      |
| Solidity verifier (stub)        | Deployed in tests            |
| Solidity verifier (real)        | Blocked on toolchain         |
| On-chain verification           | Integration tested with stub |
| Production deployment           | Not deployed                 |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://numex-greenfield.gitbook.io/numex-docs/zero-knowledge-proofs/zk-ownership-proof.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.