Skip to main content

​
Roles

​
Customer

  • Gives a payment instruction: who to pay, how much, and when
  • Holds the spending key in their own wallet for self-custody, or entrusts it to a custodian
  • Instructs their VASP to prepare the transaction

​
Custodian

  • Safeguards the customer’s spending key and signs authorizations with it
  • Cryptographically authorizes the transaction by signing with the key
  • May be the customer’s VASP. Under self-custody, the customer’s wallet performs this signing role

​
VASP

  • Prepares transactions for its customers and applies the required policies
  • Obtains signed authorizations from the customer’s wallet or custodian and arranges proof construction
  • May serve both sender and recipient. It holds spending keys only if it also provides custody

​
Proving service

  • Builds proofs that a transaction satisfies the circuit’s checks, including any required signed authorization. The VASP can do this itself or delegate it to a separate service.
  • Receives the keys, authorizations, and private inputs needed for the proof. For proofs that check spending-key signatures, these include the spend-verification key and nullifier key. It does not need the spending key.
  • Can read the private inputs it receives, and identify spends of known notes via the nullifier key
  • Cannot create a new spending authorization without the spending key.

​
Submitter

  • Broadcasts the prepared transaction and pays gas in a MIP20 gas token
  • Can be the customer’s EVM account, the VASP’s account, or a relayer acting on their behalf
  • The submitting account, gas token, and fee are public
  • Needs the prepared transaction and proofs, but not the customer’s spending or viewing keys
  • Cannot change values bound by a proof or authorization, such as the amount, destination, or resolution decision, without invalidating it.

​
MIP410 authority

  • Administers the pool’s shared compliance rules and participation requirements.
  • Uses an EVM administrator address configured at deployment or network genesis.
  • Admits and revokes VASPs and shielding assets, updates the sanctioned set, and controls the maximum hold duration, circuit IDs, bridge gateway, and pause.
  • Can transfer administration through a two-step authority transfer.
  • Has a regulatory viewing role in the design. This requires access to the relevant wallet’s incoming viewing key, nullifier key, and payment data.
  • With that access, can read payments received by the wallet and identify spends of known notes.
These administrative powers do not give the authority access to private payment data or permission to spend customers’ notes. The MIP410 reference describes how the pool’s administrative controls work.

​
MIP410 shielded pool

  • Verifies submitted proofs and checks the transaction against its current state.
  • Records note commitments, holds, input locks, and spent-note nullifiers.
  • Holds the public MIP20 value backing the notes and transfers it during shielding and unshielding.
  • Executes the verified transaction without holding customers’ spending or viewing keys.

​
Authorization flow

The flows below separate customer instructions, signatures, proof construction, and onchain execution. One provider may perform several roles: a VASP can also act as custodian, prover, and submitter.

​
Shielding

Shielding needs two authorizations: one from the MIP20 account holding the public value and one from the spending key that will control the note. The same provider may manage both keys. The shield proof binds the note to the public deposit and checks the shielded identity against the sanctions root. The deposit and note creation succeed or revert together.

​
Payment initiation

The signature fixes the notes to be spent and created if the recipient VASP accepts. It also binds the payment to the intended recipient VASP, deadline, and the chain ID, pool contract address, and state used by the proof. Initiation reserves the input notes. They are spent only if the payment is accepted.

​
Acceptance

Acceptance completes the spend already authorized by the sender. It requires neither a new sender signature nor the recipient’s spending-key signature. The recipient proof uses the incoming viewing key and private payment data to match the recipient note to the authorized payment. It uses registry evidence to check that the recipient’s registered VASP matches the VASP bound to the hold.

​
Rejection

Rejection requires the recipient proof and policy-wrapper proof, constructed using the private payment data needed to establish the right to resolve the hold. Neither party needs to supply a new spending-key signature. The input notes remain unspent and under the same spending key. For both acceptance and rejection, the recipient VASP is responsible for its decision. Privacy-Preserving Policy explains how the policy-wrapper proof is tied to that decision.

​
Reclaim

Expiry does not release the locks automatically. It requires a reclaim transaction. Reclaim needs no spending authorization, viewing key, or proof. Any EVM account can submit it. The notes remain under the original spending key. It does not transfer them to the submitter.

​
Unshielding

The signature fixes the token, amount, destination, input notes, and any change note. It also binds the transaction to the chain ID, pool contract address, and state used by the proof. The note updates and public transfer succeed or revert together.