create()on a pool factory in Balancer V2. We'll follow the process all the way from the top level call at the WeightedPoolFactory to the underlying calls that make everything work.
poolTypesoon after a pool factory has been deployed, pools can be paused. When paused, no one can join or swap with the pool, but Liquidity Providers are able to withdraw their tokens.
0. If the pause period is still active, we set the
pauseWindowDurationto be the amount of time between now and when the factory's pause period expires. For the
bufferPeriodDuration, we set this to
_BUFFER_PERIOD_DURATIONso that if a pool factory's pause period is about to end and a pause is issued, the pool can stay paused for long enough to respond to the emergency.
_BUFFER_PERIOD_DURATIONis defined as 30 days.
BaseMinimalSwapInfoPoolconstructor, as that is the WeightedPool's specialization.
_actionIdDisambiguator, where msg.sender is the pool factory address.
bufferPeriodDuration, which can be later be checked by the pool if an emergency does arise meriting a pause.
poolIdis a unique encoded identifier that refers to each pool.
poolIdencodes three elements: the pool's contract
PoolSpecialization, and a
poolIdcollisions). These are bit-packed into a single
bytes32and returned to
poolId, adds the pool to the
isPoolRegisteredmapping, and increments the
_nextPoolNonce. After emitting the PoolRegistered event, we return the
poolIdand return to the
poolTokens, which points to our
poolId's entry in
_minimalSwapInfoPoolsTokens, which is defined here. We then iterate through all of our new
tokens, and verify that they aren't already registered with the pool. As the comment notes, we do not initialize any
balancemappings since the default values are zero. We now hop back up to
TokensRegisteredevent to announce our new pool's
poolId, newly registered
tokens, and assetManagers. We now hop back up to the BasePool constructor.
tokens.lengthshould be self-explanatory. The lines for
tokensfrom the user-defined dynamic array. If the users passes fewer than 8 tokens, the
_token<i>variables are filled with the zero address.
_scalingFactor<i>lines follow a similar pattern, but for the scaling factors of the tokens. The Vault internally bookkeeps
balancesas if each token has 18 decimals, but that is not necessarily true. The scaling factors are kept to scale up/down tokens to hit this 18 decimal standard.
BasePoolconstructor, which pops us back up to the
BaseMinimalSwapInfoPoolconstructor, which is also now complete. We therefore now make our way back to the
normalizedWeightswe're about to analyze are equal to the number of
tokenswe just registered. Before looping through all the weights, we declare the following variables that we want to accumulate/keep track of:
normalizedSum, and check to see if we need to update the current
maxNormalizedWeight, doing so if necessary.
_normalizedWeight<i>might look quite similar to those for handling
scalingFactors in the
BasePoolconstructor. Just like in those cases, these variables are
immutableand therefore can't be stored in an array. Similarly, if we have fewer than 8 tokens, the
joinPoolguides -- this is because after deploying pools, you need to seed them with tokens in a separate step. In most pools, this is done with a
INIT, but in some pools (ie those with pre-minted/phantom BPT) this is done via swapping.