> ## 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 Guarantees > What MIP410 hides from public observers and where shielded activity can still be linked MIP410 keeps the asset, amount, sender, recipient, and policy details of shielded payments private from public observers. The chain publishes enough information to verify updates to the pool and follow a payment's outcome. Shielding and unshielding also reveal the value entering or leaving the pool. ## Zero-knowledge proofs in MIP410 Every transaction must be checked onchain by validators to ensure it follows the applicable rules. For example, shielded payments must conserve value, have valid authorization, and pass the required compliance checks. Zero-knowledge proofs allow those checks without publishing the private payment details onchain. Zero-knowledge proof involves: * A circuit expresses the rules to be proven as mathematical constraints. MIP410 uses different circuits for different transaction types, with each circuit defining the checks its proof must establish. * Public inputs bind the proof to the particular transaction and the pool state it references. These values are available to both the prover and the verifier. * Private inputs, collectively called the witness, supply the hidden data needed to satisfy the circuit's constraints. They include information such as note contents and signed authorization, which the prover uses without publishing it onchain. * The prover uses the circuit and both sets of inputs to generate a proof, represented as bytes that can be displayed as a hexadecimal string. The proof establishes that the prover knows private inputs that satisfy the circuit's constraints for the supplied public inputs. * Validators check the proof against the public inputs using the circuit's verification key. This key contains public numerical parameters that let the verifier check proofs for that circuit. The proofs are verified without using the private inputs or running the circuit on those inputs again. If verification fails, the pool rejects the transaction. Using payment initiation as an example, the private inputs include note contents and the signed authorization. The public inputs include the payment effect hash, which commits to the proposed input and output notes, and the note tree's Merkle root. The proof establishes that the private notes belong to that tree and that the proposed payment matches the payment effect hash, as well as satisfying the authorization and value-conservation rules. Zero knowledge protects the private inputs from disclosure through the proof. The transaction still publishes the proof, public inputs, and other information needed to execute and record the transaction. The disclosures vary by transaction type, as described below. ## Transaction disclosures Shielding and unshielding disclose the token, amount, and public account at the pool boundary. Shielding directly associates the deposit with its new note commitment. Unshielding publishes a destination and the spent notes' nullifiers, while keeping their openings private. The table summarizes what each transaction publishes and keeps private. | Transaction | Public | Private | | - | - | - | | Shielding | MIP20 token, amount, depositor onchain identity, deposit authorization, new note commitment, and proof | Recipient diversified address, note secret, and shield authorization | | Initiation | Hold ID, input lock IDs, payment effect hash, recipient VASP binding commitment, deadline, and proofs | Asset, amount, sender, recipient, nullifiers, output note commitments, and private policy inputs | | `Accept` | Hold ID, resolution outcome, nullifiers, output note commitments, and proofs | Note openings, asset, amount, sender, recipient, and private policy inputs | | `Reject` | Hold ID, resolution outcome, release of the input locks, and proofs | The payment effect and private payment details | | Reclaim | Hold ID, deadline, and `Reclaimed` hold state | The payment effect and private payment details | | Unshielding | MIP20 token, amount, destination, input lock IDs, nullifiers, any change note commitment, and proof | Input note openings and their direct connection to earlier commitments | | Every transaction | Submitter identity, gas token, fee, block, and calldata | Spending keys and private inputs to proofs | ## Encrypted message transfer during initiation As part of initiation, the sender virtual asset service provider (VASP) sends the recipient VASP the note opening and payment details needed to review and resolve the payment. These details travel offchain in an encrypted payment envelope. The onchain initiation transaction reserves the input notes without publishing those private details. ## Public hold IDs after initiation Once initiation succeeds, the pool records a hold with a public hold ID. That ID connects initiation to acceptance, rejection, or reclaim, allowing observers to follow the payment's timing and outcome. Acceptance also connects the hold to the published input nullifiers and output note commitments. Rejection or reclaim releases the input locks without spending the notes or changing their input lock IDs. Expiry alone does not release the locks. The hold ID identifies the payment. The input lock ID identifies a note reserved by that payment. A new payment has a new hold ID, but reusing a note publishes the same input lock ID. Unshielding and bridge withdrawal also publish input lock IDs, allowing observers to connect them to earlier holds that reserved and released the same notes. An input lock ID does not reveal the note's nullifier. The two identifiers use different labels in their hash calculations, so an observer cannot calculate one from the other. However, the recipient VASP that opened the payment memo already knows the sender's input nullifiers. After rejection or expiry and reclaim, it can watch the unchanged input lock IDs for reuse and recognize the nullifiers when those notes are spent, even if it has no role in the later transaction. Zero padding also reveals whether the transaction uses one or two real inputs. ## Participants' visibility A sender VASP receives information from its customer, and a recipient VASP receives private payment details to review. Participants can see information supplied to them or accessible through their keys. Validators do not gain this access merely by validating transactions. Zero-knowledge proofs keep the private inputs hidden during verification. | Party | Additional visibility | | - | - | | Customer or custodian | Available note and payment data accessible through the spending key and its derived keys | | Sender VASP | Information supplied by its customer and used to prepare initiation | | Recipient VASP | The institutional payload encrypted to its messaging key, the note memo when it holds the incoming viewing key, and its own customer records | | MIP410 authority | Incoming notes through delegated viewing keys, and whether those notes were spent through delegated nullifier keys and known note positions. | | Proving service | Private inputs supplied for delegated proving and viewing access granted by its delegated keys, without authority to spend notes | Viewing private payment details does not itself grant authority to spend notes. MIP410's key hierarchy allows different parties to receive different viewing and proving capabilities while spending authority remains separate. [Keys and Addresses](https://docs.metalntwx.com/learn/mip410/key-and-addresses.md#key-hierarchy) explains how that separation works. ## Linkability through metadata Public transaction metadata can reveal who is involved in a shielded payment. The submitter, gas token, and fee remain visible for every transaction. A VASP submitting from a recognizable identity may therefore reveal its participation. Using a relayer changes the visible submitter, but timing and amounts disclosed during shielding and unshielding can still help observers connect the payment to earlier activity. Those connections can become stronger with fixed payment addresses. If a merchant uses the same payment address with every customer, anyone who sees multiple requests containing that address can link them to the same recipient. Repeated use of the same payment address can help observers infer who the recipient is, especially for widely recognized merchants. Using a fresh diversified address for each payment request avoids exposing a shared address across requests. [Keys and Addresses](https://docs.metalntwx.com/learn/mip410/key-and-addresses.md#diversified-addresses) explains how a recipient can use different addresses while retaining access to all its incoming payments. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.