Skip to main content
Shielded payments transfer value within the MIP410 shielded pool without publishing the asset, amount, sender, or recipient onchain. Shielding public MIP20 value creates a note representing that token and amount. The pool records note commitments in one shared, append-only Merkle tree. The note does not explicitly identify the sender. Spending a note requires authorization from its spending key. Notes can be spent through shielded payments or unshielding. An accepted payment records nullifiers identifying the spent input notes and creates a recipient note. Spending the recipient note requires authorization from the recipient’s spending key. Unshielding spends notes and releases their value to a public MIP20 account. For each transaction, the pool must establish that the proposed update satisfies the protocol’s rules. Zero-knowledge proofs let the pool contract verify spending authorization, value conservation, and the required checks without revealing private inputs such as the amount, asset, sender, and recipient.

​
Shielded payment lifecycle

A shielded payment uses two transactions: initiation and resolution. The sender and recipient each use a participating virtual asset service provider (VASP). The sender VASP prepares initiation, which reserves the input notes in the pool. The recipient VASP then prepares a resolution with an Accept or Reject decision.

​
Initiation

The sender instructs the sender VASP, and the spending key authorizes the proposed spend. The sender VASP prepares a sender proof establishing that the input notes are controlled by the authorizing identity and cover the payment. Initiation reserves the input notes until the payment is resolved or reclaimed. Once the pool verifies the submitted proofs and checks that the inputs are available, it creates a hold and locks the notes. They remain unspent while the hold is pending.

​
Resolution

The recipient VASP decides whether to accept or reject the held payment and prepares a resolution transaction. The recipient proof connects that decision to the held payment and its intended recipient.

​
Accept

The recipient VASP prepares a resolution proving acceptance of the held payment. Acceptance spends the reserved input notes and creates the output notes. After verifying the submitted proofs, the pool records the input nullifiers and appends the recipient note commitment. The payment is complete once the transaction executes successfully and its block is final.

​
Reject

Rejection releases the input locks without spending the notes. The recipient VASP prepares a resolution proving rejection. Once verified, the pool marks the hold as rejected. It records no nullifiers and creates no output notes, leaving the original notes available for another payment or unshielding.

​
Expiry and reclaim

Every initiation includes a deadline. Once it passes, the pool stops accepting resolutions for the hold. The notes remain locked until a reclaim transaction releases them. The pool checks the hold’s state and deadline, then releases the locks.
The sender VASP initiates a payment, and the pool creates a hold. The recipient VASP accepts it, so the pool records the input nullifiers, appends the recipient and any change note commitments, and keeps the spent inputs permanently locked.The sender VASP initiates a payment, and the pool creates a hold. The recipient VASP accepts it, so the pool records the input nullifiers, appends the recipient and any change note commitments, and keeps the spent inputs permanently locked.

​
Shielding

Shielding moves public MIP20 value into the pool and creates a note backed by that value. The customer VASP prepares a shield proof binding the note’s token and amount to the public MIP20 deposit. The MIP20 holder authorizes the public transfer into the pool. Successful shielding transfers the MIP20 value and appends the note commitment as one atomic update. The note becomes spendable after the transaction executes successfully and its block is final.
In a custodial shield, the customer VASP creates the note and proof, the depositor authorizes the public MIP20 transfer, and a submitter sends the prepared transaction. The pool receives the MIP20 value and appends the note commitment.In a custodial shield, the customer VASP creates the note and proof, the depositor authorizes the public MIP20 transfer, and a submitter sends the prepared transaction. The pool receives the MIP20 value and appends the note commitment.

​
Unshielding

The customer VASP prepares an unshield proof for the requested public amount. The proof establishes that the input notes are controlled by the authorizing identity and cover that amount. Unshielding spends the input notes and transfers the public amount to the authorized destination. The pool verifies the proof and checks that the inputs are unlocked and unspent. It records their nullifiers, appends any change note commitment, reduces the token’s recorded backing, and transfers the MIP20 value. These changes revert together if the transaction fails.
In a custodial unshield, the customer VASP authorizes the note spend and prepares the proof. A submitter sends the transaction, and the pool records the nullifiers, appends any change note commitment, and transfers the MIP20 amount to the authorized destination.In a custodial unshield, the customer VASP authorizes the note spend and prepares the proof. A submitter sends the transaction, and the pool records the nullifiers, appends any change note commitment, and transfers the MIP20 amount to the authorized destination.