> ## 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. # Privacy > Choose between transparent and shielded payments on Metal Metal supports transparent and shielded payments. Each exposes different information about accounts, assets, and amounts. ## Privacy levels | Level | Public observers can see | Application pattern | | - | - | - | | Transparent (MIP20) | Asset, accounts, amount, transaction, and events | Ordinary MIP20 payment | | Shielded (MIP410) | Shielding and unshielding details, plus cryptographic transaction data | Shielded payment | ## How shielded payments work MIP410 uses one shielded pool contract for all supported MIP20 assets. The pool accounts for each asset's backing separately, while note commitments from all assets share one commitment tree. Each note keeps its asset private, so notes across assets contribute to the same anonymity set. Shielding transfers MIP20 backing into the pool and appends the new note commitment to the tree. Shielding moves MIP20 assets into the MIP410 shielded pool. In the pool, shielded notes are represented by note commitments in the commitment tree. Every sender and recipient of a shielded payment works through a virtual asset service provider (VASP). The VASP may custody its customer's spending keys, or serve a customer who self-custodies them — the two [custody models](https://docs.metalntwx.com/learn/mip410/roles-and-authorization.md#custodian). In both, the VASPs apply policy and prepare MIP410 transactions, and [any account can submit](https://docs.metalntwx.com/learn/mip410/roles-and-authorization.md#submitter) a finished transaction and pay its gas. Zero-knowledge proofs verify ownership, value conservation, and the applicable policy results without publishing the asset, amount, sender, or recipient. ### What payment information is visible for each party | Information | Sender / recipient | Their VASPs | Public observers | | - | - | - | - | | Payment asset and amount | Visible to both | Available when preparing or reviewing the payment | Hidden | | Sender and recipient identities | Information supplied offchain | Their own customer, plus supplied counterparty information | Hidden | | Shielded balance | Own known notes | Depends on custody, delegated keys, and available note data | Hidden | | Submitter accounts | Visible to both | Visible to both | Visible | | Transaction occurrence and timing | Visible | Visible | Visible | The VASP column includes custodial and self-custodial arrangements. A VASP custodying a customer's keys can derive that customer's viewing keys. A VASP receiving a delegated proving key can also derive viewing access while the customer retains spending authority. The account that submits a transaction is public, so when a VASP submits its own transactions, that account may identify it. Routing through a relayer changes what the transaction layer reveals, and it changes nothing about the shielded payment underneath. Public transaction data and timing may also support inferences when the anonymity set is small. They do not directly reveal the payment asset, amount, sender, or recipient. A wallet can delegate viewing access to the MIP410 authority for regulatory purposes. The pool does not automatically provide or enforce this access. ### Shielding your balances Shielding is a public MIP20 transfer into MIP410. It reveals the depositor account, asset, amount, submitter account, and note commitment. Observers can therefore link that note commitment to its public entry into the pool. After shielding, a later spend does not publish its input commitment. ### Shielded payment A shielded payment starts with the recipient, who shares a payment address with the sender. Wallets deliver it as a payment request over whatever channel the two parties already use, such as a link, a QR code, or an email. The address tells the sender where the value should arrive and which VASP serves the recipient. The sender instructs the sender VASP to initiate a payment. The sender VASP applies its policy and prepares the initiation. The spending-key holder authorizes the note spend: the sender VASP under custodial service, or the sender's wallet under self-custody. The recipient VASP applies its policy and resolves the payment with `Accept` or `Reject`. Any account may submit the resulting transactions. The recipient VASP can resolve with `Accept` only when its recipient proof and the pool's current-state checks pass. The payment is complete after it is successfully resolved with `Accept` and the containing block is final. A `Reject` resolution releases the input locks, leaving the sender's notes unspent. Public observers can see that MIP410 activity occurred. The asset, amount, sender, and recipient are not directly published, although timing may support inferences. A rejected or reclaimed payment stays linkable to the sender's input notes: observers see the same input lock IDs when those notes are next used, and the recipient FI, which learned their nullifiers, sees the spend that consumes them. ### Unshielding your balances Unshielding makes the value public again. It reveals the unshield destination, asset, amount, and submitter account. It does not directly reveal which shielding transaction or shielded payments produced that value. ## Policy enforcement for shielded payments The sender VASP and recipient VASP each register a private policy. Initiation requires the sender VASP's policy-wrapper proof, while acceptance or rejection requires the recipient VASP's. The main proofs enforce the protocol's sanctions and payment checks. The chain verifies the required policy results without receiving customer records, policy rules, thresholds, screening evidence, or Travel Rule records. Each VASP decides what its policies require and retains the supporting records offchain. ## Choose a path | Need | Start with | | - | - | | Public payment and simple wallet support | MIP20 | | Hidden asset, amount, and customer identities from public observers | MIP410 | > [card] [Send a shielded payment](https://docs.metalntwx.com/build/payments/shielded-payment.md) > > Follow the complete shielded payment workflow. > [card] [MIP410 shielding](https://docs.metalntwx.com/learn/mip410/shielded-payments.md#shielding) > > Understand the MIP410 shielded pool, proofs, and public boundary. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.