Liquidity Pool Data Issues

[BlockBoy32]

HeyI am running into an issue that might make it impossible to leverage the liquidity pool data to calculate rewards for the revenue sharing unless there is a way to access all of the substep data that I am not aware of.

In a past, if I had a reward policy that required a specific LP interaction data, I put the policy exactly after the interaction with the liquidity pool to use that data before it got refreshed in the following LP interaction. This current policy's rewards requires two of the LP interactions data so I am not sure how to access both unless we store them differently in the data model or if there is a way to access specific state update block data that I am not aware of, let me know if this makes sense. @achimstruve let me know what you think

[achimstruve]

radCad is limited in the sense that we can only access substep data of the previous timestep. It is stored in the state_history variable. Unfortunately there is no clean way of how we can access substep data of the current timestep.

One way would be to define a new state variable. In the liquidity_pool.py I faced a similar issue where I needed to get access to information from previous substeps within the same timestep. There I introduced two new state_variables lp_token_price_max and lp_token_price_min to solve it (see the update_liquidity_pool_after_transaction function within ./ecosystem/liquidity_pool.py

Let me know if this helps.

[BlockBoy32]

Yes this does, this was the approach I was looking to take. Would it be okay if I created s state variable for just there two actions I need? Or should I create all of them for every transaction

[achimstruve]

Yes this does, this was the approach I was looking to take. Would it be okay if I created s state variable for just there two actions I need? Or should I create all of them for every transaction

Not entirely sure what you mean by this. If we don't want to access the additional data elsewhere, keep it as slim as possible.

[BlockBoy32]

For each transaction with the liquidity pool it gets stored into the same state variables, for the reward logic for this policy I technically only need two of the variables from different steps. Should I create just the two variables I need or for the sake of consistency and potentially needing the future variables should I just create them all?

[achimstruve]

I would just create the ones you would need at the moment as long as there is no strong case for doing it otherwise.