Skip to main content
Every shield transaction carries a shield proof. The proof binds the MIP20 value transferred into the pool to one well-formed shielded note. It establishes this statement:
I am shielding amount units of asset into the pool as the note committed to by commitment, whose opening I know. I control the spending key for the note and authorize this shield. The affilID derived from my incoming viewing key is absent from the sanctioned set.

​
What shielding checks

Shielding proves note ownership, authorization, and absence from the sanctioned set. It does not require a customer or depositor registration in the pool’s VASP tree, or a policy-wrapper proof. A shield authorization is a signature from the key holder. With custodial keys, the VASP’s custodial system signs. With self-custodied keys, the customer’s wallet signs. The MIP20 deposit authorization separately permits the public token transfer into the pool. MIP20 recovers this authorization from an ECDSA signature; it does not accept an ERC-1271 contract-wallet signature. The MIP20 transfer into the pool remains transparent and subject to the token’s programmable policy. Payment messaging describes the offchain exchange of payment instructions and Travel Rule records.

​
Witness

The witness remains with the prover. Its preparation can be delegated through outsourced proving, but the key holder must produce the shield authorization.

​
Public inputs

The table follows the circuit’s eight public inputs in order. The pool verifies the proof through CircuitRegistry and 0xF2, pulls the authorized deposit, requires its balance to increase by exactly amount, and appends commitment. Changing a public input invalidates the proof.

​
Inside the circuit

  • commitment opens according to the canonical note opening and binds its amount, asset_id, and shieldTimestamp to the public inputs. The four reserved fields are zero.
  • The note’s address is a Grumpkin point derived from ivk and the diversifier. The circuit derives ivk from the witnessed ak and nk, binding the note to one identity.
  • A Schnorr signature under ak verifies over the shield’s public inputs: the owner authorized exactly this shield.
  • affilID is absent from the sanctioned set.

​
Illustration

The shield circuit combines the private witness, shield authorization, and public inputs into a shield proof. The submitted transaction also carries a deposit authorization. The pool verifies the proof and appends the note commitment.The shield circuit combines the private witness, shield authorization, and public inputs into a shield proof. The submitted transaction also carries a deposit authorization. The pool verifies the proof and appends the note commitment.

​
Shield transaction submission

Any public account may submit the prepared shield transaction and pay gas. The customer, a relayer, or the customer VASP may act as submitter. The deposit authorization fixes the depositor, token, amount, and note commitment through its authorization nonce; the shield proof fixes the note commitment and the result of every private check. The submitter cannot change those values or authorize a different shield.