Add query to track liquidity provider rewards

[georgemc98]

Background

To protect against the Cream exploit we need a way to only compound those rewards that come from liquidity mining rewards and not those that might be donated by an attacker. We currently don’t know how to do this and I assume it will require an upgrade in Osmosis to add this query. We’re not sure what the best way to write such a query would be and it would be great if someone from Osmosis can help with this as we are not very familiar with the liquidity mining rewards logic.

https://mudit.blog/cream-hack-analysis/

Suggested Design

Add an RPC endpoint that returns the amount of liquidity pool rewards have been sent to an address since a given timestamp or block.

[mattverse]

IMO,a query that takes in address and timestamp as response, and returns amount of rewards given during timestamp is not adequate to have it as a chain query.

First reason, we don't keep state on rewards by "timestamps", there wouldn't be a way to do this as of rn.

Second reason, we track rewards for each "lock", not each account in the incentives module.

An approach you might want to try out is using the query RewardsEst, combined with different lock queries

[georgemc98]

RewardsEst may be useful, but we need to know the historical rewards for a lockup. Is there a total amount of rewards per lock we could query?

[mattverse]

Would it be possible to store that within the contract, not the state machine? I'm not sure if storing an unused state(within state machine) is preferred

[georgemc98]

Would it be possible to store that within the contract, not the state machine? I'm not sure if storing an unused state(within state machine) is preferred

We can't store the correct amount of rewards in our contract, because we don't know the correct amount of rewards to begin with.

[mattverse]

Would it be possible to store that within the contract, not the state machine? I'm not sure if storing an unused state(within state machine) is preferred

We can't store the correct amount of rewards in our contract, because we don't know the correct amount of rewards to begin with.

Because of the difference caused by the estimate reward and the actual reward?

[georgemc98]

Would it be possible to store that within the contract, not the state machine? I'm not sure if storing an unused state(within state machine) is preferred

We can't store the correct amount of rewards in our contract, because we don't know the correct amount of rewards to begin with.

Because of the difference caused by the estimate reward and the actual reward?

Yes, exactly. What information is stored? Are the total rewards distributed saved?

[pacmanifold]

@mattverse any update on this?

[shapeshed]

I'm also looking for a similar query to get rewards distributed to an address by lock id and epoch. My use case is autocompounding rewards after a distribution.

Afaik the only way to do this now with the available apis is to use the rewards estimate endpoint before the epoch ends, store this and hope it is accurate.