Twilight Pool

When do you call a pool, a "pool"?

Since the base layer supports a stateless VM, there is no contract address that allows deposit/withdrawal while maintaining a global state. Hence, the "pool" in Twilight pool is not a contract address with custody of tokens but a list of independently locked transactions that are treated as a pool. The transactions are locked to a relayer, as a promise to participate in the pool, with a timelock in case of a dispute. The poolshare is calculated over encrypted state, made available in the txlog , by the relayer and is auditable in zero knowledge.

The contract design follows the principal of N parties cooperating over pre-defined scripts, first introduced by Gregory Maxwell in his Taproot Proposal. Twilight does not achieve scripts privacy though, as the scripts are later revealed to the verifier in the bytecode of the transaction.

How it works?

Twilight pool is the sum of all the independently locked LendTx , where the value locked is hidden by a pedersen commitment. Since Twilight is a single token pool, the TLV is determined by adding all the available pedersen commitments from individually locked LendTx s.t:

TotalLockedValue=com(LendState)iTotalLockedValue=\sum{com(LendState)_i}

Every lock/unlock for LendTx changes the state of TLV and the most recent state is published in txlog . Since the value is committed, TLV remains private and is only revealed in case of a dispute. Please refer to zk-Matchbook for construction details:

pagezk-Matchbook

Last updated