zk-Matchbook

Trivia: Matchbook FX (1999-2002) was the world's first ECN for forex markets on the internet.

There are 3 design goals for zk-Matchbook:

1. Relayer must NOT learn the original value in a locked account.

2. Relayer should NOT have the custody of tokens.

3. Relayer can NOT spend a transaction maliciously.

For the first property to hold true, it is very important that the client runs a prover locally. This way the client can prove some spending condition on an amount that is separate from the total amount in the account.

There are two types of transactions that are accepted as an input to the matching engine, LendTx and OrderTx. Both of these txs are generated in the browser of the client and hides the amount in the account with an inequality check. For detailed VM stack, please refer to:

pageOrder/LendTx

Building Twilight Pool

Every LendTx locked at the relayer changes the state of TLV and TPS by locking some wBTC in a LendState. PoolShare calculated for every transaction is pushed to the stack as a commitment and is not revealed to the user.

$$PoolShare=\frac{TPS*Deposit}{TLV}$$

where TPS is the sum of all the PoolShare values calculated for every LendTx. These values are appended to the txlog of the transaction to keep an on-chain record for auditability purposes.

Similarly the withdrawal values are calculated using the same PoolShare commitment from the txlog.

$$Withdraw=\frac{TLV*PoolShare}{TPS}$$

To make sure the client is synced with the most recent state of TLV and TPS, the client send the lendTx along with TLV and TPS commitments. The relayer then checks whether commitment received is the current state and locks the transaction accordingly.