Conditional Note consumption on Miden via soulbound NFTs

[Dominik1999]

Conditional Note Consumption via Private Identity Attestations on Miden

Summary

We want to enable conditional note consumption on Miden based on real-world identity claims (e.g. citizenship), while preserving privacy, unlinkability, and good UX. Most important, good UX.

Example:

Alice wants to consume a note, but the note may only be consumed if Alice can prove that she is a US citizen.

This discussion explores a proof of concept (PoC) that integrates external identity providers (Privado or zkPassport) with Miden’s private state model, enabling claims to be proven once and then reused privately in subsequent transactions.

Problem Statement

On Miden, assets move via notes, and notes can impose consumption conditions.

A common class of conditions is identity-based:

• Citizenship (e.g. US citizen)
• Residency
• Age thresholds
• Accreditation / eligibility

The challenge:

a) Identity data must remain private
b) Identity proofs should not be repeated for every interaction (No runtime dependency on the identity provider during consumption)
c) The check should happen inside the Miden transaction (Miden tx kernel should be able to check)

Why Existing Approaches Are Not Sufficient Out of the Box

Public-chain identity NFTs

• Leak metadata
• Are linkable across apps
• Break privacy guarantees

Proof-per-interaction identity systems

• Require Alice to re-prove the same claim repeatedly
• Create UX friction
• Implicitly depend on external verifiers at runtime
• Miden cannot verify Groth16, Barettenberg, ...

Key Observation: Private State Changes the Design Space

Miden supports private accounts and private state. This enables a hybrid model:

• Identity claims are materialized once into a private attestation
• The attestation is stored only in Alice’s private account
• Subsequent transactions reuse this private state
• Claims are proven locally, inside the transaction

This model is not possible on transparent blockchains, but is feasible on Miden. Actually also on Aztec, maybe Aleo.

Proposed Solution (High Level)

1. Alice proves her passport to an identity provider (Privado or zkPassport)
2. The provider issues a non-transferable attestation artifact (Souldbound NFT)
3. The artifact is bridged to Miden
4. Alice stores it in her private Miden account
5. When consuming a conditional note, Alice proves, inside the Miden transaction: “I own a valid attestation containing claim C”
6. The Miden transaction kernel verifies the claim and authorizes consumption

No identity data is revealed, and no external system is contacted at runtime.

Attestation / “Soulbound NFT” Structure (Proposed)

“NFT” is used as a mental model. The essential object is a signed attestation payload stored in private state.

Attestation Header (signed by issuer)

• schema_id (e.g. passport_v1)
• issuer_id
• issuer_pubkey_id
• subject_commitment (bound to Alice, unlinkable)
• claims_root (Merkle root over claims)
• expiry
• revocation_id
• nonce

Issuer Signature

• Signature over the full header by the issuer

Claims Tree (private)

Merkle tree with individual claim leaves, e.g.:

• citizenship == US
• date_of_birth == 1989-12-12
• document_type == passport

Only the leaf required by a note’s predicate is opened during a transaction.

Conditional Note Consumption on Miden

First Alice needs to obtain the attestation artifact. She needs to register with an identity provider. Then she can use the artifact to consume notes.

Registration Flow: Privado-Based PoC (With a Tweak)

Privado’s native model is stateless proof-per-interaction. This PoC explores materializing a credential once into private state.

The idea is to use Privado's off-chain verifier as bridge and issuing entity of the Miden NFT.

sequenceDiagram
   autonumber
   participant Alice
   participant Issuer
   participant Billions
   participant Bridge as Privado_Off-chain_Verifier
   participant Miden as Miden Network
   participant Account as Alice Miden Account (Private)


   Alice->>Issuer: Submit passport + liveness proof (off-chain)
   Issuer->>Issuer: Verify passport & identity
   Issuer->>Alice: Send Verifiable Credential (VC)
   Issuer->>Billions: Store commitments Alice
   Alice ->> Bridge: Submits Verifiable Credential (VC)
   Bridge ->> Billions: Checks VC against Commitments
   Bridge->>Bridge: Derive claims (citizenship, DOB, expiry)
   Bridge->>Bridge: Build claims Merkle tree → claims_root
   Bridge->>Bridge: Compute subject_commitment (bound to Alice)
   Bridge->>Bridge: Sign attestation header
   Bridge->>Bridge: Mint Attestation NFT / SBT (payload + signature)
   Bridge->>Miden: Mint NFT (attestation token)
   Miden ->> Account: Store NFT in private account

Loading

Registration Flow: zkPassport-Based PoC

sequenceDiagram
    autonumber
    participant Alice
    participant Issuer as zkPassport (Issuer)
    participant L1 as Aztec / Ethereum
    participant Bridge as Bridge / AggLayer / Trusted single sig bridge
    participant Miden as Miden Network
    participant Account as Alice Miden Account (Private)

    Alice->>Issuer: Submit passport + liveness proof (off-chain)
    Issuer->>Issuer: Verify passport & identity
    Issuer->>Issuer: Derive claims (citizenship, DOB, expiry)
    Issuer->>Issuer: Build claims Merkle tree → claims_root
    Issuer->>Issuer: Compute subject_commitment (bound to Alice)
    Issuer->>Issuer: Sign attestation header

    Issuer->>L1: Mint Attestation NFT / SBT (payload + signature)
    L1-->>Alice: Attestation token minted

    Alice->>Bridge: Bridge attestation payload to Miden
    Bridge->>Miden: Create note carrying attestation object
    Miden->>Account: Store attestation in private account state

Loading

Note consumption flow

During transaction execution, Alice proves:

1. The attestation exists in her private account state
2. The issuer signature is valid
3. The attestation is not expired
4. The revealed claim satisfies the note predicate
5. (Optional) The attestation is not revoked

If all checks pass, the note is consumed.

sequenceDiagram
    autonumber
    participant Alice
    participant Account as Alice Miden Account (Private)
    participant Kernel as Miden Transaction Kernel
    participant CondNote as Conditional NC
    participant IssuerKeys as Issuer Key Registry (on Miden)
    participant Revocation as Revocation Root (optional)

    Alice->>Account: Select attestation object
    Alice->>Kernel: Build tx witness (attestation, claim leaf, Merkle path) in advice provideer

    Kernel->>Account: Check attestation exists in private state
    Kernel->>IssuerKeys: Fetch issuer public key via FPI
    Kernel->>Kernel: Verify issuer signature
    Kernel->>Kernel: Check expiry

    Kernel->>Kernel: Verify Merkle opening -> claims_root
    Kernel->>Kernel: Check claim satisfies NC predicate

    opt Revocation enabled
        Kernel->>Revocation: Check revocation_id not revoked
    end

    Kernel->>CondNote: Authorize NC consumption
    CondNote-->>Kernel: Release assets
    Kernel-->>Account: Credit assets to account

Loading

Open Questions

• How should revocation be handled (expiry vs revocation roots)?
• Should the attestation be an NFT or an opaque payload?
• What claim granularity is practical for selective disclosure?
• What issuer key management is required on Miden?

---

Goal of This Discussion

This discussion is not to finalize a protocol, but to:

• Align on feasibility
• Identify required protocol tweaks
• Define a minimal PoC for conditional note consumption on Miden

Feedback from both identity provider teams is highly appreciated.

[PhilippGackstatter]

Looks great! This is how I imagined a name service to work too. You consume a P2N note targeted at alice.miden and it will check that you have a name NFT alice.miden in your account. This should work without protocol changes, and the identity checks should similarly work without any protocol/tx kernel changes. All of this should be doable in user space, iiuc.