post_processing: add token_k_value and TVL to p_df

[AngelaKTE]

• various plots need token_k_value/TVL over time
• add column providing token_k_value = token_k_balance * token_k_price
• add column providing TVL = sum of all token_k_value

[AngelaKTE]

• add column "total_token_balances" = sum of all token_k_balances (=Pool Size)
• calculate "token_a_balance" + "token_b_balance" + "token_c_balance" + ...

[AngelaKTE]

• all columns added to one big dataframe "p_df"

[markusbkoch]

• add column "total_token_balances" = sum of all token_k_balances (=Pool Size)

If I understand correctly, if you're looking for a metric of the "pool size" may I suggest the invariant instead?

The sum of token balances can be misleading. Even in the 80/20 ETH/DAI pool (0x8b6e6E), it is dominated by the DAI balance. That's why TVL and total_token_balance have a ~perfect correlation: total_token_balance ~= token_dai_balance = 20% * TVL.

See how using the invariant makes things more clear. Despite the TVL growing from under 60M to over 120M, the invariant only grew from ~184k to ~188k. Meaning the growth in TVL was dominated by the price increase of the underlying tokens (namely ETH in this case), with growth of the pool itself playing a lesser role.

[mzargham]

I agree with @markusbkoch. An additional note, the invariant view also makes it relatively easy to see the impact of add/remove liquidity events as different from the the steady growth in the "invariant"

side note, we use the term "invariant" as the price regulation in the bonding surface is derived from holding this function V invariant for swaps but in practice, the fees cause the value of V to increase for swaps. This is how the LPs make money over time. On the other hand the add and remove liquidity mechanisms explicitly increase and decrease V, while preserving price. Furthermore, the awesome balancer feature "asymmetric" liquidity add/remove is actually a composition of a swap and a liquidity add.

[markusbkoch]

I really like the last plot in the notebook when you swap total_token_balances for the invariant. It highlights Z's point about <steady growth during long periods without join/exits> vs. <abrupt change upon join/exits>

[AngelaKTE]

• add column "total_token_balances" = sum of all token_k_balances (=Pool Size)

If I understand correctly, if you're looking for a metric of the "pool size" may I suggest the invariant instead?

The sum of token balances can be misleading. Even in the 80/20 ETH/DAI pool (0x8b6e6E), it is dominated by the DAI balance. That's why TVL and total_token_balance have a ~perfect correlation: total_token_balance ~= token_dai_balance = 20% * TVL.

See how using the invariant makes things more clear. Despite the TVL growing from under 60M to over 120M, the invariant only grew from ~184k to ~188k. Meaning the growth in TVL was dominated by the price increase of the underlying tokens (namely ETH in this case), with growth of the pool itself playing a lesser role.

@markusbkoch
I have a question on the correct implementation of the Invariant here.

• Invariant is the product of all (token_(symbol)balance **token(symbol)_weight)
• however, we frequently find two versions of the weight value, and I'm uncertain which one to use (and implement) in the model
  a) the weight in percent: 80 WETH / 20 DAI in our case
  b) the weight as decimal: 0.8 WETH/ 0.2 DAI (which you obviously use for the plots)

Which one is correct, and why?

[markusbkoch]

The white paper defines it in terms of the normalized weights (such that the sum of all normalized weights is 1) - so 0.8 and 0.2 in that case.

As for the why, it's not explicitly stated in the white paper, but from eq 10 in this proof we see that Wn must be a number between 0 and 1 (since 0<Vn<V by definition).

[AngelaKTE]

Update post-processing:

• remove "total_token_balances" column and post-processing

• add column "pool_size_V" = product of all (token_(symbol)balance **token(symbol)_weight) - see above

• "pool_size_V" = product of all (token_(symbol)balance **token(symbol)_weight) - see above