Skip to main content

Private Wallets

Overview of the technical UTXO based infrastructure that enables shielded transfers.

Overview​

The platform enables users to privately transfer shares with peers. Specifically, it allows participants to:

  • Shield their assets:
    1. On the user's device, generates a zero-knowledge proof that the redacted mDL is consistent with the original mDL, and that the "age>18" predicate is true.
    2. Sends it to the relayer for verification, and upon success creates a UTXO for the user.
  • Transfer their assets:
    1. On the user's device, generates a zero-knowledge proof that:
      • The redacted mDL is consistent with the original mDL, and that the "age>18" predicate is true.
      • A UTXO that carries sufficient balance belongs to the user.
    2. Sends it to the relayer for verification, and upon success undertakes the steps below.
    3. On the sender side, creates a nullifier for the original sender's UTXO, and create a new UTXO with the residual balance.
    4. On the receiver side, creates a UTXO for the transfered balance.

A closer look at the transfer​

The sender has the ability to asynchronously send payment to receiver if it knows the receiver’s master public key:

mpk=hash(publickey,nullifyingkey,vcSignature).mpk = hash(public key, nullifying key, vcSignature).

from which the npk can be generated:

npk=hash(hash(publickey,nullifyingkey,vcSignature),nonce).npk = hash(hash(public key, nullifying key, vcSignature), nonce).

The sender first checks locally whether an mpk is available, and otherwise creates one. Then for the shield, the sender stores the following in the tx_database on the relayer:

(,sendermpk,nonce1,token,amount)(, sender mpk, nonce1, token, amount)

Note commitments are saved to a database on a remote server.

  1. For every transfer, the sender takes as input the receiver’s mpk, generates an npk by picking nonce and stores it in a tx_database on the relayer:

    • (sender mpk, receiver mpk, nonce1, token, amount, success/fail)
    • (sender mpk, sender mpk, nonce2, token, balance_amount, success/fail)

    -> The relayer waits until the transaction goes through. If it goes through add success, otherwise fail.

  2. For checking the balance on some mpk, we find all rows in the table at the relayer with receiver mpk = mpk and status = success. We then recompute a note commitment by computing npk and then note commitment with npk, token, amount. We add the amounts for all note commitments that are not in the list of nullifiers obtained from the smart contract. This is the available balance.