zkBob Pool Contract
Main transaction processor
The main purpose of the zkBobPool contract is to process user transactions. It receives transactions from operators (relayers) or users directly, checks the proofs, and updates the current contract state.
zkBob Pool Initialization
Each pool serves a single token. To support multi-pool solutions every pool has it's own identifier (pool_id
). Currently the pool_id is an unsigned 24-bit arbitrary integer.
All linked contracts (verifiers, operator manager, token, and voucher token) should be provided prior to Pool contract deployment. The Pool contract is initialized by the following constructor method:
Denominators
There are two denominators used in the Pool and applied to the token (TOKEN_DENOMINATOR
) and native coin (NATIVE_DENOMINATOR
). They are initially defined as 1 gwei constants.
Example usage: When a user wants to withdraw 5 tokens from the pool, they specify '5' as the value in the corresponding transaction field. The pool will multiply this value by the TOKEN_DENOMINATOR and send the resulting token value to the receiver address (in wei). Denominators are also used to calculate limits.
Root Parameter
The initial Merkle tree root value should be provided for the _root
parameter. For a Merkle tree with a desired total height 48 without any leaves (all leaves are zero) the root is a fixed value:
Limits
The ability to set limits is introduced with the setLimits
method.
Making a transaction
The Pool contract processes incoming transactions via the transact()
method. All required data for the transaction passes through the calldata.
Before the transaction is processed the proofs are checked by the verifier contracts.
Note the onlyOperator
modifier. It checks the transaction sender address via the Operator Manager and reverts a transaction when the origin sender is not currently allowed to interact with the Pool contract.
Source and Deployment data
The contract source code: zkBobPool.sol
Last updated