Key Derivation

MIP410 derives each wallet’s keys from one wallet seed through one-way derivations. The resulting hierarchy separates the capabilities to recognize incoming notes, detect spends, build proofs, and authorize spends. A key holder can share a derived key with a scanner, proving service, or the MIP410 authority without revealing its ancestors.

Notation

The formulas on this page use four objects.

Notation	Meaning
$\mathrm{Poseidon2}(\ldots)$	The hash function used throughout MIP410. Its inputs and output are field elements in the proof system’s native arithmetic.
Grumpkin	The elliptic curve shielded keys live on. Its point arithmetic uses the proof system’s native field, which keeps key operations cheap to verify inside a proof.
$G$	Grumpkin’s fixed generator point.
$\mathrm{DOMAIN\_NK}$ , $\mathrm{DOMAIN\_VIEW}$ , …	Domain tags that separate otherwise similar derivations.

Lower-case symbols (

zsk

nk

ivk

d

) are field elements;

G

ak

g_d

, and

pk_d

are Grumpkin points. A field element written against a point, as in

zsk \cdot G

, means scalar multiplication.

The hierarchy

seed sk                     wallet seed
 └─ zsk                     spending key
     ├─ ak                  spend-verification key
     ├─ nk                  nullifier key
     ├─ ivk                 incoming viewing key
     │   └─ (d, pk_d)       diversifier and diversified address
     └─ ovk                 outgoing viewing key

Key	Full name	Derivation	Role
`sk`	wallet seed	—	Root secret. Every other key derives from it.
`zsk`	spending key	$\mathrm{Poseidon2}(\mathrm{DOMAIN\_ZSK}, seed_{lo}, seed_{hi})$	Authorizes spends. It does not leave the key holder.
`ak`	spend-verification key	$ak = zsk \cdot G$	Verifies spend signatures inside a proof.
`nk`	nullifier key	$nk = \mathrm{Poseidon2}(zsk, \mathrm{DOMAIN\_NK})$	Derives a note’s nullifier, which records when the note is spent.
`ivk`	incoming viewing key	$ivk = \mathrm{Poseidon2}(ak_x, ak_y, nk, \mathrm{DOMAIN\_VIEW})$	Recognizes incoming notes and generates addresses.
`ovk`	outgoing viewing key	$\mathrm{Poseidon2}(\mathrm{DOMAIN\_OVK}, zsk)$	Derived separately from the incoming viewing key.
`pk_d`	diversified address point	$pk_d = ivk \cdot g_d$ — see Addresses	Forms a diversified address with `d`. One `ivk` can generate multiple addresses.

The seed is 32 bytes. seed_lo is bytes 0–15 and seed_hi is bytes 16–31, each interpreted as a big-endian unsigned integer. Their order is significant. Recovering

zsk

from

ak

requires solving a discrete logarithm on Grumpkin. Recovering

ak

nk

from

ivk

requires inverting Poseidon2 over

ak_x

ak_y

, and

nk

. A derived key therefore does not reveal its ancestors.

Addresses

A diversified address is the pair

(d, pk_d)

. The wallet chooses a fresh diversifier

d

and derives the address point

pk_d

x_d = \mathrm{Poseidon2}(\mathrm{DOMAIN\_GD}, d), \qquad g_d = (x_d, y_d), \qquad pk_d = ivk \cdot g_d

The wallet solves

y_d^2 = x_d^3 - 17

in the Grumpkin base field and chooses the smaller of the two roots in canonical integer order. If there is no root, it chooses another diversifier. This exact derivation matters: a generic hash-to-curve function will produce different addresses. Three properties follow:

Unlinkable. Without the ivk behind them, two addresses with different diversifiers do not disclose a shared owner cryptographically. Reuse or offchain disclosure can still link them.
One scanner. A single ivk recognizes notes sent to every address it generates. Generating more addresses does not require more viewing keys.
Change ownership. The proof enforces that change belongs to the sender. Wallets should choose a fresh diversifier; the circuit does not check whether that diversifier has been used before.

Nullifiers are independent of diversified addresses. Publishing one does not reveal which address held the note.

Derived identifiers

The hierarchy also yields one stable identifier for the identity:

affilID = \mathrm{Poseidon2}(\mathrm{DOMAIN\_AFFIL}, ivk)

. Every address generated from the same ivk shares this affilID. An ivk holder can compute affilID and the address alone does not reveal it. Linking

pk_d

affilID

requires the ivk that produced both. Sanctions screening binds to affilID, so generating a fresh address does not change the sanctions result. Customer-to-VASP affiliation is maintained offchain; affilID is not a customer registration in the pool’s VASP tree.

The capability lattice

Each key bundle grants a specific set of capabilities.

Bundle	Typical holder	See arrivals	See spends	Build shield or spend proofs	Authorize spends
$\{ivk\}$	a watch-only scanner	✓	—	—	—
$\{ivk, nk\}$	an authorized viewer	✓	✓	—	—
$\{ak, nk\}$	a proving service	✓	✓	✓	—
$zsk$	key holder: the customer wallet or VASP custodial system	✓	✓	✓	✓

\{ak, nk\}

sees arrivals because

ivk

derives from it. The reverse does not hold:

\{ivk, nk\}

cannot reconstruct

(ak, nk)

. A proving service still needs the key holder’s signature for each shield or spend. Recipient proofs are different: ivk is sufficient for their ownership check, but resolution also requires the recipient VASP’s policy-wrapper proof. Seeing arrivals requires access to the encrypted note memos or note openings. Detecting spends also requires each known note’s leaf index. The MIP410 authority has this visibility only if the relevant keys and data are shared with it; contract administration does not grant them. The institutional payload uses the recipient VASP’s separate messaging key.

Key custody

With custodial keys, the VASP’s custodial system holds the customer’s zsk and can generate addresses, scan notes, build proofs, and authorize spends. With self-custodied keys, the customer’s wallet holds zsk and may share

\{ak, nk\}

with its VASP for proving. Both arrangements produce the same onchain proofs. A customer using custodial keys may also receive

\{ivk\}

for watch-only access.

Spend authorization

Spending a note requires two checks inside the proof:

Ownership. The prover witnesses $(ak, nk)$ and re-derives the note’s diversified address.
Authorization. The circuit verifies a Schnorr signature under $ak$ over a Poseidon2 digest of the action’s public values.

For payment initiation, the digest binds the payment effect hash, input lock IDs, nonce, and deadline. An unshield authorization binds its destination, amount, inputs, and change note. These bindings prevent a proving service or submitter from redirecting the action. Recording a note’s nullifier in the spent set prevents the note from being spent again.

Outsourced proving

Proof generation can be delegated without sharing the spending key. The following flow applies to self-custodied keys. With custodial keys, the VASP can sign and prove directly. Delegation hands the proving service

\{ak, nk\}

and runs one round trip:

The wallet builds the payment intent and output note commitments.
The service prepares the witness, including tree paths and policy inputs, computes the nullifiers and input lock IDs, and returns the digest.
The wallet checks the digest against its intent and signs with $zsk$ .
The service completes the proof and a submitter submits the finished transaction.

The service can build or withhold a proof. It cannot authorize or redirect a spend because each action requires a signature derived from zsk over the wallet-approved digest. A wallet may isolate proving services by deriving a separate

zsk_i

and sharing only its

\{ak_i, nk_i\}

bundle.

The institution’s messaging key

One key on this page belongs to no wallet. Each VASP in the pool’s institution registry holds a messaging key: an independent Grumpkin Schnorr key pair, generated by the institution and not derived from any customer seed. Its verification key sits in the institution’s leaf of the pool’s VASP tree beside the hash of its policy verification key, so the leaf is the one place the chain learns which key speaks for the institution:

\mathrm{leaf} = \mathrm{Poseidon2}(\mathrm{DOMAIN\_FI\_LEAF},\ fi\_id,\ vk\_hash,\ mpk_x,\ mpk_y)

The key signs payment requests, institutional payload commitments, payment contexts inside policy wrappers, and the institution’s own leaf updates. Wallets verify requests offchain. The receiving VASP verifies the institutional payload signature offchain. The wrapper verifies its context signature inside the proof under the key opened from the VASP tree. updateFi replaces the policy verification-key hash and messaging key under a signature by the old messaging key, verified through the Grumpkin precompiles. The VASP can rotate its own key without an authority transaction. The pool accepts the previous registration root after an admission. A key rotation or revocation clears that previous root, so proofs using the old leaf must be rebuilt against the updated registry. Request validation must use an accepted registry snapshot and check the request’s expiry.

What the chain sees

Wallet keys remain private. Diversified addresses travel in payment requests and encrypted note memos, and wallet signatures are verified inside proofs. VASP messaging public keys are public in registry updates. The chain also carries note commitments, input lock IDs, payment and payload commitments, nullifiers when notes are spent, and proofs. Accepted payments retain their input lock IDs permanently; rejected or reclaimed holds release them.

Network fundamentals

Assets and payments

Privacy

Compliance

Contracts and automation

Data and signatures

Interoperability

Notation

The hierarchy

Addresses

Derived identifiers

The capability lattice

Key custody

Spend authorization

Outsourced proving

The institution’s messaging key

What the chain sees

​Notation

​The hierarchy

​Addresses

​Derived identifiers

​The capability lattice

​Key custody

​Spend authorization

​Outsourced proving

​The institution’s messaging key

​What the chain sees

Notation

The hierarchy

Addresses

Derived identifiers

The capability lattice

Key custody

Spend authorization

Outsourced proving

The institution’s messaging key

What the chain sees