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

# Shielded Payments

> How MIP410 represents shielded value and verifies shielding, payment initiation, resolution, and unshielding

Shielded payments transfer value within the MIP410 shielded pool without
publishing the asset, amount, sender, or recipient onchain.
Shielding public MIP20 value creates a note representing that token and
amount. The pool records note commitments in one shared, append-only Merkle tree.
The note does not explicitly identify the sender. Spending a note requires
authorization from its spending key.

Notes can be spent through shielded payments or unshielding. An accepted
payment records nullifiers identifying the spent input notes and creates a
recipient note. Spending the recipient note requires authorization from the
recipient's spending key. Unshielding spends notes and releases their
value to a public MIP20 account.

For each transaction, the pool must establish that the proposed update satisfies
the protocol's rules. Zero-knowledge proofs let the pool contract verify
spending authorization, value conservation, and the required checks without
revealing private inputs such as the amount, asset, sender, and recipient.

## Shielded payment lifecycle

A shielded payment uses two transactions: initiation and resolution. The
sender and recipient each use a participating virtual asset service provider
(VASP). The sender VASP prepares initiation, which reserves the input notes in
the pool. The recipient VASP then prepares a resolution with an `Accept` or
`Reject` decision.

```text theme={null}
Sender
  -> instructs the sender VASP
Spending key
  -> authorizes the input-note spend
Sender VASP
  -> prepares initiation with a sender proof
MIP410 shielded pool
  -> verifies initiation, creates a hold, and locks the input notes
Recipient VASP
  -> prepares resolution with a recipient proof
MIP410 shielded pool
  -> verifies resolution and spends or releases the input notes
```

### Initiation

The sender instructs the sender VASP, and the spending key authorizes
the proposed spend. The sender VASP prepares a sender proof establishing
that the input notes are controlled by the authorizing identity and cover the
payment.

Initiation reserves the input notes until the payment is resolved or
reclaimed. Once the pool verifies the submitted proofs and checks that the
inputs are available, it creates a hold and locks the notes. They remain unspent while the hold is pending.

### Resolution

The recipient VASP decides whether to accept or reject the held payment and
prepares a resolution transaction. The recipient proof connects that decision
to the held payment and its intended recipient.

#### Accept

The recipient VASP prepares a resolution proving acceptance of the held
payment. Acceptance spends the reserved input notes and creates the output
notes. After verifying the submitted proofs, the pool records the input
nullifiers and appends the recipient note commitment. The payment is complete
once the transaction executes successfully and its block is final.

#### Reject

Rejection releases the input locks without spending the notes. The
recipient VASP prepares a resolution proving rejection. Once verified, the pool marks the hold as rejected. It records no
nullifiers and creates no output notes, leaving the original notes available
for another payment or unshielding.

### Expiry and reclaim

Every initiation includes a deadline. Once it passes, the pool stops accepting
resolutions for the hold. The notes remain locked until a reclaim transaction
releases them. The pool checks the hold's state and deadline, then releases the
locks.

> [tab] Accept
>
> ![The sender VASP initiates a payment, and the pool creates a hold. The recipient VASP accepts it, so the pool records the input nullifiers, appends the recipient and any change note commitments, and keeps the spent inputs permanently locked.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/payment-accept.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=565206626d2a9b8f7f27c337646173c2)

> [tab] Reject
>
> ![The sender VASP initiates a payment, and the pool creates a hold. The recipient VASP rejects it, so the pool releases the input locks without spending the sender's notes.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/payment-reject.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=e9fadbd9ddcff3cdce6f3b3863357922)

> [tab] Reclaim
>
> ![The sender VASP initiates a payment, and the pool creates a hold. No resolution arrives before the deadline, so a reclaim transaction releases the input locks without spending the sender's notes.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/payment-reclaim.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=2329c24d52c6a62626524e96e90f26c6)

## Shielding

Shielding moves public MIP20 value into the pool and creates a note backed by
that value. The customer VASP prepares a shield proof binding the note's token
and amount to the public MIP20 deposit.

The MIP20 holder authorizes the public transfer into the pool. Successful
shielding transfers the MIP20 value and appends the note commitment as one
atomic update. The note becomes spendable after the transaction executes
successfully and its block is final.

![In a custodial shield, the customer VASP creates the note and proof, the depositor authorizes the public MIP20 transfer, and a submitter sends the prepared transaction. The pool receives the MIP20 value and appends the note commitment.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/shield-lifecycle.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=eaa9664a22ac91337d3f84220c346565)

## Unshielding

The customer VASP prepares an unshield proof for the requested public amount.
The proof establishes that the input notes are controlled by the authorizing
identity and cover that amount. Unshielding spends the input notes and transfers
the public amount to the authorized destination. The pool verifies the proof
and checks that the inputs are unlocked and unspent. It records their nullifiers,
appends any change note commitment, reduces the token's recorded backing, and transfers
the MIP20 value. These changes revert together if the transaction fails.

![In a custodial unshield, the customer VASP authorizes the note spend and prepares the proof. A submitter sends the transaction, and the pool records the nullifiers, appends any change note commitment, and transfers the MIP20 amount to the authorized destination.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/mip410/unshield-lifecycle.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=23196476fe45ffae7abc4f7e1878e18f)


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