search

timewave-computer / valence-services

Other
3 stars 0 forks source link

Separate rebalancer config so the config provided by the user is immutable #73

Closed Art3miX closed 4 months ago

Art3miX commented 5 months ago

Currently we have 1 config saved into storage, this config includes all data provided by the user, plus some data we require for calculations including data about last rebalance cycle that is needed for the current cycle calculation.

This is not ideal, because we have no clear separation of data provided from the user, which must be immutable unless he changes it, and the data we must change every cycle needed for the next calculation, this might (and have) result in a case where we update the config and override the user provided data with a temp data.

We already have an helper struct in our calculation that holds the data we need to modify, but we can't blindly copy from this helper into config, because of the way we have the config struct set up.

The main issue here is the targets list, the target list is given by the user, and it should never change in storage, but for the calculation there are cases where some limits might hit and we need to modify those temporarily for the current cycle calculation, but never save those changes to storage. We have 2 items in the targets that needs to be modified and saved into storage for the next calculation (last_i and last_input), currently those are saved inside the targets list, so we need to manually update only those 2 fields in the targets list.

The solution is to separate the user provided targets and other fields that are required for our calculations, this will make it easier to not override user provided targets by mistake, and keep them immutable while still holding single configs storage.

stiiifff commented 4 months ago

@Art3miX Is this issue addressed by #75 ?

Art3miX commented 4 months ago

No, just a temp fix

Art3miX commented 4 months ago

There is currently a temp solution and a test that makes it harder to get this bug again.

The best solution involves a lot of rewrites that we don't want to do now, as we want to close this contract. I would suggest to close this issue for now, and reopen if we ever gonna do a rewrite of the contract.