> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Shield Circuit

> How the shield proof binds a public MIP20 deposit to a private shielded note

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](https://docs.metalntwx.com/learn/mip410/roles-and-authorization.md#custodian), 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](https://docs.metalntwx.com/learn/compliance/messaging.md)
describes the offchain exchange of payment instructions and Travel Rule records.

## Witness

| Witness | Role |
| - | - |
| Diversifier, base-point root `y`, `secret` | The address derivation witness and fresh per-note randomness |
| `ak`, `nk` | The ownership pair; the circuit re-derives `ivk`, the address, and `affilID` from them |
| Shield authorization | A Schnorr signature under `ak` over the shield's public inputs |
| Sanctions path | The non-membership path showing `affilID` is absent from the sanctioned set |

The witness remains with the prover. Its preparation can be delegated through
[outsourced proving](https://docs.metalntwx.com/reference/privacy/key-derivation.md#outsourced-proving), but
the key holder must produce the shield authorization.

## Public inputs

| Public input | How the pool constrains it |
| - | - |
| `chain_id`, `pool_address` | Supplied by the pool to bind the proof to this deployment |
| `commitment` | Becomes the note's leaf in the commitment tree |
| `amount` | Must equal the MIP20 value transferred into the pool |
| `asset` | Identifies the MIP20 token transferred into the pool |
| `depositor` | The EVM address that signed the MIP20 deposit authorization |
| `shield_timestamp` | Must not be in the future or more than 3,600 seconds older than the block timestamp |
| `sanctions_root` | Must be the current sanctions root |

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](https://docs.metalntwx.com/reference/privacy/shielded-note.md#the-commitment) 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.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/shield-circuit.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=67b2560c9978a35e5091d9e68d0d0314)

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.