Privacy

Metal supports transparent and shielded payments. Each exposes different information about accounts, assets, and amounts.

​

Privacy levels

​

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. In both, the VASPs apply policy and prepare MIP410 transactions, and any account can submit 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

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