3.6 Settlement Now that the traders wallet has been matched and encumbered, they need to settle this match in order to update their balances and un-encumber the wallet. Finally, after generating , the trader is now ready to interact with the smart contract. The trader sends four different proofs 1, 2, , to the contract (i.e. two proofs of VALID COMMITMENTS, one proof of VALID MATCH MPC, and one proof of VALID MATCH ENCRYPTION), alongside the union of public variables for all four proofs. The contract checks that all four zero-knowledge proofs are valid under the given public inputs. If all checks pass, the contract then marks the two nullifiers wallet-match (1) and wallet-match(2) as being seen, an inserts all of the encrypted notes into the commitment tree. To do this, the trader first obtains a note = (cid:16) ( 1, 1, 1), ( 2, 2, 2), ( 3, 3, 3), , (cid:17) .

The trader can find the note by either remembering the match they just performed, or if the note was generated from an internal transfer from a different user inside the pool, by scanning through the commitment history to find the most recent encrypted note and decrypt it under their secret key sksettle. Now, the trader constructs a new wallet Note that this nullification is different from how revealcommit schemes work in VALID WALLET UPDATE as in 10In our instantiation of the protocol, we use ElGamal to encrypt all notes. In addition to being a SNARK-friendly encryption scheme, ElGamal has the property of being key-private, meaning that third-parties cannot even see which public settle key of the party who is receiving the funds. = ( , , , , ) such that and are unchanged from the original wallet , and with = + 2. To construct , the trader simply adds or subtracts values from the balances list according to the note . If the trader 7

Finally, to construct , the trader finds the order = (, 1 , 2 , , , , , ) that was matched by and decreases the size by the corresponding matched value 1 or 2 depending on the direction of the match. Now, given this new wallet that was formed by directly settling the match note against the old wallet , the trader constructs a proof of the statement VALID SETTLE as defined in Section A.8. In addition to revealing the commitment to the new wallet ( ) and the wallet-spend and wallet-match nullifiers as normal, the trader also reveals a note-redeem nullifier defined as note-redeem ( ) := (cid:16)

|| pksettle(cid:17) . Note-redeem nullifiers exist in order to prevent replay-style attacks by double-settling a matched order. The trader then sends this proof to the contract, and assuming it is correctly verified, the contract will mark both the wallet-spend and note-redeem nullifiers as being seen, and insert the new commitment ( ) into the Merkle tree. Note that if = 0 (i.e., the note came from an internal transfer or fee output), then the contract also asserts that the wallet-match nullifier has not been seen, and marks it as seen. This allows the system to have a single operation (settlement) for all notes, no matter how the note was generated. Now, the trader has settled their matched orders, and all three nullifiers (wallet-match, wallet-spend, note-redeem) have been seen, making further use of either the old wallet or the used note impossible.