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

# Private Payments

> How Metal hides payment details while proving authorization, value conservation, and policy compliance

MIP20 transfers are public. Anyone observing the chain can see the asset,
amount, sender, recipient, and emitted events.

MIP410 provides a private payment path for supported MIP20 assets. Payments
inside its shielded pool hide the asset, amount, sender, and recipient from
public observers.

## How private transfers work

Supported MIP20 value moves into the MIP410 shielded pool. The pool holds the
MIP20 backing while private notes represent who can spend the value inside it.

A zero-knowledge proof shows that the sender is authorized to spend the input
notes and that the transfer conserves value. The proof also binds the new
private notes created for the recipient and any sender change. Metal verifies
the proof and checks that the input notes have not been spent before updating
the pool.

![Initiation reserves notes; recipient VASP acceptance creates new notes, while rejection makes the inputs available again.](https://mintcdn.com/nexus-ed339086/CdWwGT0bcT9zD-Uw/images/start/private-payment-flow.svg?fit=max\&auto=format\&n=CdWwGT0bcT9zD-Uw\&q=85\&s=dfea6078ff0f33e6942108883971726d)

## Programmable policy

Policy checks can be combined with the proof of authorization and value
conservation. An institution defines the requirements for its payments, and
the proof shows that those requirements passed without revealing the policy
rules or their private inputs.

The policy result is bound to the transfer, so it cannot be reused for another
payment. If a required statement fails, Metal rejects that transaction and
leaves the pool's state unchanged.

## What each party can see

| Information | Payment participants | Authorized institutions | Public observers |
| - | - | - | - |
| Asset and amount | Visible | Available when required by their role and policy | Hidden |
| Customer identities | Information supplied offchain | Their own customer and supplied counterparty information | Hidden |
| Shielded balance | Each holder sees their own known notes | Depends on custody, delegated keys, and note data | Hidden |
| Transaction occurrence and timing | Visible | Visible | Visible |

Transaction timing and the public submitter may still support inferences,
especially when activity is low. Shielded payments reduce public disclosure, but
do not make network activity invisible.

Shielding and unshielding reveal their public MIP20 account, asset, and amount.
Holds, input lock IDs, and acceptance disclosures also create public links
between transactions. [Privacy Guarantees](https://docs.metalntwx.com/learn/mip410/privacy-guarantees.md)
explains these boundaries.

## Regulatory access

Participants can delegate viewing access for regulatory oversight.
This access can reveal known notes and their spends when the required payment
data is available, but it cannot authorize a spend. The pool does not
automatically grant this access to its administrator or enforce its delivery.

> [card] [Make a shielded payment](https://docs.metalntwx.com/build/payments/shielded-payment.md)
>
> Follow the complete shielded payment flow.

> [card] [How private payments work](https://docs.metalntwx.com/learn/mip410/shielded-payments.md)
>
> Understand payment requests, holds, resolution, and recovery.


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