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.
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
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
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.Make a shielded payment
Follow the complete shielded payment flow.
How private payments work
Understand payment requests, holds, resolution, and recovery.