V2 #38

Kayanski · 2024-03-22T17:59:25Z

This PR aims at implementing savings app V2.
The base branch is changed to be able to merge changes without touching on v1

Changes

Actually using Abstract

All authz calls have been replaced by calls through the proxy contract as intended by Abstract. This allows to remove hacks and to use the Abstract SDK much more deeply than in the previous version. This felt good and rationalizes the code

Adding multiple strategies

This Savings App V2 now uses a Balance Strategy to direct funds to one investment or the other. This balance strategy consists of multiple yield sources. This balance strategy is saved in the application config. When doing deposits, withdrawals and auto-compounding, this app tries to make the investments match the strategy as much as possible.

Autocompound rewards

Autocompound rewards are now a perentage of the rewards withdrawn during auto-compounding. This allows simpler and more fluid interactions !

Status

Withdraw only withdraws an equal share from all investments. This tends to keep the same balance between all yield sources.
Autocompound has the target behavior --> Withdraw all rewards and then re-deposit all rewards.
Rebalance is a function that allows users to change the hard-coded balance strategy. It withdraws removed strategies and deposits withdrawn funds and additional funds into the app

Zoom on the deposit strategy.

In this proposed V2, each strategy needs to be handled separately. When a deposit is made, the following steps apply :

A share for each investment is computed. This is computed using the target strategy as well as the current deposit share of the source compared to the whole deposit. (Not implemented, for now, we only use the config strategy)
This balance strategy is used to split the deposit into the different available yield sources. Each source is assigned a value and the process to swap assets from the deposited assets into each underlying assets is devised
The strategy is splitted into yield sources.They are all handled separately (swapping and depositing assets) to ensure separation of variables and concerns.

Swap strategy

We want to get most efficiently from the deposited coins into the target coins to enter the yield sources. We have created an algorithm that tries to minimise swaps. This is not optimal but allows to avoid un-necessary swaps:

Take all the deposited coins and try to fit as much as possible in the strategies without swaps (optimized)
Swap the remaining coins to the remaining assets (no optimization)

Remarks on the osmosis CL case

In the Savings app previous version, there was a complicated algorithm to swap assets correctly from the deposited amounts to the expected amounts for the liquidity pool. This algorithm is not used in v2. Instead, for a first deposit, the front-end needs to input the correct share ratio for the investment. The more general value distribution algorithm takes care of choosing the necessary swaps to enter the pool correctly.
TODO : The strategies share need to be computed dynamically from the underlying investments. This would allow pool positions to completely change without the users need of rebalancing everytime they want to do additional deposits

Remaining TODO

Withdraw should target the strategy (It is very dumb right now)
Maybe add a different endpoint that only tweaks the investments shares instead of overwriting the strategy completely
Have a separate structure for valid Balance Strategies (handling valid and non-valid objects is a bit of a mess right now)
Adding queries to simulate deposits, withdraw and rebalance

CyberHoward · 2024-03-27T10:45:15Z

Have a separate structure for valid Balance Strategies (handling valid and non-valoid objects is a bit of a mess right now)

You can use Addresslike generic for the struct and create type aliases for the checked and non-checked variant. We do that in a few places in the framework.

CyberHoward · 2024-03-27T10:54:49Z

contracts/carrot-app/src/yield_sources/yield_type.rs

+            }
+            YieldType::Mars(denom) => mars::user_liquidity(deps, denom.clone(), app),
+        }
+    }


So this is where we would need to add a query like deposited_value that returns how much is deposited in the yield source and its breakdown?

There is already that function !

CyberHoward · 2024-03-27T10:58:10Z

contracts/carrot-app/src/yield_sources/yield_type.rs

+        deps: Deps,
+        amount: Option<Uint128>,
+        app: &App,
+    ) -> AppResult<Vec<CosmosMsg>> {


Would be great to have a list of tokens returned there as well, i.e. how many and which tokens the dev can expect to receive after executing this msg.

The dev can

Query all the values of the enabled yield strategies

Calculate how much to withdraw from each, construct msgs

Prepare swap messages if needed

Deposit into other strategy with (potentially swapped) funds.
And all without the need of replies

Would that be possible to implement?

Yes. I have planned a SimulateRebalance query endpoint. I will also do a SimulateDeposit endpoint for those purposes

The replies were here to avoid simulations and have the exact swapped funds deposited instead of relying on estimates that may change during execution.

We'll have to sync on this, I'm not sure what the idea is behind that

The replies were here to avoid simulations and have the exact swapped funds deposited instead of relying on estimates that may change during execution.

Simulations during execution are accurate as long as you don't do any action on the pool before you use a result of that simulation.

That's the thing. As we're doing potentially multiple swaps, we're not able to trust those simulations. We can try if you prefer. You don't like replies ?

Yeah makes sense! But in general our rebalance approach should probably be

Withdraw

Swap (Optional)

Deposit

If we add a simulation we can prevent reply 1 -> 2, independent of wether we need to swap or not

Replies just makes reading the code a bit messier imo and requires state caching

contracts/carrot-app/src/msg.rs

contracts/carrot-app/src/handlers/instantiate.rs

CyberHoward · 2024-04-02T11:19:48Z

Should we change namespace to be seperate from abstract?

Kayanski · 2024-04-02T11:39:02Z

Should we change namespace to be seperate from abstract?

Why ? Seems like abstract did that app no ?

CyberHoward · 2024-04-04T14:19:58Z

This balance strategy is used to split the deposit into the different available yield sources. Each source is assigned a value and the process to swap assets from the deposited assets into each underlying assets is devised
The strategy is splitted into yield sources.They are all handled separately (swapping and depositing assets) to ensure separation of variables and concerns.

Can we unify the swaps for these? I.e. we know how much we want to allocate to each source and we know which assets they expect. We can then compute the swaps globally and execute them at once, instead of letting each strategy figure out how much to swap individually and possibly having multiple swaps for the same pair.

CyberHoward · 2024-04-04T14:22:05Z

algorithmically this is kind of a "set" computation.

You have a set of coins that are provided, you compute the set that is required, you remove the union of those two sets and compute the swaps for the difference in the sets.

CyberHoward · 2024-04-04T14:26:13Z

Have a separate structure for valid Balance Strategies (handling valid and non-valid objects is a bit of a mess right now)

You can use signal generics for this.

struct Checked; 
struct Unchecked;

struct MyValueBase<T> {
  _phantom: PhantomData<T>
}

type MyValue = MyValueBase<Checked>;
type MyValueUnchecked = MyValueBase<Unchecked>;

impl MyValueUnchecked {
  fn check(self) -> MyValue {
  // ...
  }
}

Kayanski · 2024-04-04T22:43:01Z

struct Checked; 
struct Unchecked;

This syntax is now applied on all the structures with a check functionality

Kayanski · 2024-04-05T08:28:10Z

This balance strategy is used to split the deposit into the different available yield sources. Each source is assigned a value and the process to swap assets from the deposited assets into each underlying assets is devised
The strategy is splitted into yield sources.They are all handled separately (swapping and depositing assets) to ensure separation of variables and concerns.

Can we unify the swaps for these? I.e. we know how much we want to allocate to each source and we know which assets they expect. We can then compute the swaps globally and execute them at once, instead of letting each strategy figure out how much to swap individually and possibly having multiple swaps for the same pair.

What would a unification bring ? I only see less gas usage, because fees are a percentage of swap values.
With this change, we would :

Compute the different allocations per strategy
Unify all the swaps that do the same thing
Dispatch the remaining swap results to the corresponding strategies.

Is that right ?

Buckram123

Very nice progress! Would like to see some gas optimizations.

Not sure how many strategies are we expecting to be used at the same time, but wonder if we can make rebalancing/autocompounding a little bit smarter by not doing everything at once?

Buckram123 · 2024-04-05T11:41:39Z

contracts/carrot-app/src/msg.rs

+        /// We might not use a vector but use a (usize, Vec<AssetShare>) instead to avoid having to pass a full vector everytime
+        yield_sources_params: Option<Vec<Option<Vec<AssetShare>>>>,


I don't think Option<Vec<>> is a good thing to use, as empty vector mean technically same as None

It's a Vec because if it's specified, one element needs to exists for each element in the underlying strategy. I'm not proud of the way params are passed to this function but I don't have identifiers for the strategy elements !

contracts/carrot-app/src/msg.rs

Buckram123 · 2024-04-05T11:50:08Z

contracts/carrot-app/src/msg.rs

 }

 #[cw_serde]
 pub struct PositionResponse {
-    pub position: Option<Position>,
+    pub ty: YieldTypeUnchecked,


nit: Yield type is much more complex object, than just reporting it's "type", maybe something like YieldSource?

YieldSource is already used somewhere else to encompass the shares of each token inside the Yield Source

But agree Type is a bit misleading here

But agree Type is a bit misleading here

and ty as well

This is renamed to params is that ok ?

contracts/carrot-app/src/handlers/instantiate.rs

contracts/carrot-app/src/handlers/execute.rs

contracts/carrot-app/src/helpers.rs

contracts/carrot-app/src/state.rs

contracts/carrot-app/src/yield_sources/mod.rs

Buckram123 · 2024-04-08T10:43:53Z

contracts/carrot-app/src/handlers/query.rs


-    let balances = try_proto_to_cosmwasm_coins(vec![pool.asset0.unwrap(), pool.asset1.unwrap()])?;
-    let liquidity = pool.position.unwrap().liquidity.replace('.', "");
+pub fn query_balance(deps: Deps, app: &App) -> AppResult<AssetsBalanceResponse> {


Would be nice to add pagination here

Are we there yet @CyberHoward, especially the balance query would be misleading with pagination (but could still run out of gas)

Buckram123 · 2024-04-08T10:44:11Z

contracts/carrot-app/src/handlers/query.rs

    })
 }

-fn query_rewards(deps: Deps, _app: &App) -> AppResult<AvailableRewardsResponse> {
-    let pool = get_osmosis_position(deps)?;
+fn query_rewards(deps: Deps, app: &App) -> AppResult<AvailableRewardsResponse> {


Would be nice to add pagination here as well

Same as above

Kayanski added 6 commits March 22, 2024 17:58

Started running tests

839cc6e

Restored

3f28a97

Handle multiple osmosis pool positions

023f3f0

Add autocompound'

fb12617

Rationalized exchange rate

d1cfce1

nits

3b8b374

Kayanski marked this pull request as draft March 26, 2024 14:42

Kayanski requested a review from CyberHoward March 26, 2024 15:18

Added params to help deposit

9c8d8f2

CyberHoward added 2 commits March 27, 2024 12:50

nits

467433d

rename expected_tokens to asset_distribution

ac021d9

CyberHoward reviewed Mar 27, 2024

View reviewed changes

Added current status

458cca4

Kayanski changed the base branch from main to mainv2 March 27, 2024 12:46

Incorporated money market

37f8772

CyberHoward reviewed Mar 28, 2024

View reviewed changes

contracts/carrot-app/src/msg.rs Outdated Show resolved Hide resolved

CyberHoward reviewed Mar 28, 2024

View reviewed changes

contracts/carrot-app/src/msg.rs Outdated Show resolved Hide resolved

CyberHoward reviewed Mar 28, 2024

View reviewed changes

contracts/carrot-app/src/handlers/instantiate.rs Outdated Show resolved Hide resolved

CyberHoward and others added 9 commits March 28, 2024 12:40

optimize strategy query

fa554c7

Added internal messages, and better strategy checks

fb38a09

Merge

39477b8

Check

97e65bc

Deposit refactor

8ff3e5e

Fix auto-compounding and test checks

54a0cb6

Added smart deposit

619e8c1

More structure

e5ff15b

Added inbalance test

a266725

Added rebalance and tests

904e0c4

Kayanski added 3 commits April 4, 2024 22:46

Added checked and unchecked features

615842e

Checks on config

1babe2f

Moved checks

a142f88

Added deposit preview

656ad28

Buckram123 requested changes Apr 8, 2024

View reviewed changes

Kayanski added 18 commits April 8, 2024 17:03

Added release profile

7fe855f

Nots

7f1f75b

error rename

eb326a3

Migrate Msg to struct

2085369

Fixed instantiate and dependencies

6903c1a

Added localnet tests

2414e21

Gas optimizations

3de860b

Simplify further yield source impls

2499025

Rename yield type

2f716d2

Extend gas tests

b21d38e

UPdated estimates

1c3a970

Added withdraw preview and removed useless deposit operation

b9b508c

Added update strategy preview

13c1c76

Removed usless import

adca153

Corrected tests

6e75065

Updated autocompound process

ea38f9c

Fix autocompound test

c300a49

Changed autocompound strartegy on bot

923d49a

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

V2 #38

V2 #38

Kayanski commented Mar 22, 2024 •

edited

Loading

CyberHoward commented Mar 27, 2024

CyberHoward Mar 27, 2024

Kayanski Mar 27, 2024

CyberHoward Mar 27, 2024

Kayanski Mar 27, 2024

Kayanski Mar 27, 2024

Kayanski Mar 27, 2024

CyberHoward Mar 27, 2024

Kayanski Mar 27, 2024

CyberHoward Mar 27, 2024

CyberHoward Mar 27, 2024

CyberHoward commented Apr 2, 2024

Kayanski commented Apr 2, 2024

CyberHoward commented Apr 4, 2024

CyberHoward commented Apr 4, 2024

CyberHoward commented Apr 4, 2024

Kayanski commented Apr 4, 2024

Kayanski commented Apr 5, 2024 •

edited

Loading

Buckram123 left a comment

Buckram123 Apr 5, 2024

Kayanski Apr 8, 2024

Buckram123 Apr 5, 2024

Kayanski Apr 8, 2024

Kayanski Apr 8, 2024

Buckram123 Apr 9, 2024

Kayanski Apr 11, 2024

Buckram123 Apr 8, 2024

Kayanski Apr 8, 2024

Buckram123 Apr 8, 2024

Kayanski Apr 8, 2024

		/// We might not use a vector but use a (usize, Vec<AssetShare>) instead to avoid having to pass a full vector everytime
		yield_sources_params: Option<Vec<Option<Vec<AssetShare>>>>,

V2 #38

Are you sure you want to change the base?

V2 #38

Conversation

Kayanski commented Mar 22, 2024 • edited Loading

Changes

Actually using Abstract

Adding multiple strategies

Autocompound rewards

Status

Zoom on the deposit strategy.

Swap strategy

Remarks on the osmosis CL case

Remaining TODO

CyberHoward commented Mar 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CyberHoward commented Apr 2, 2024

Kayanski commented Apr 2, 2024

CyberHoward commented Apr 4, 2024

CyberHoward commented Apr 4, 2024

CyberHoward commented Apr 4, 2024

Kayanski commented Apr 4, 2024

Kayanski commented Apr 5, 2024 • edited Loading

Buckram123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kayanski commented Mar 22, 2024 •

edited

Loading

Kayanski commented Apr 5, 2024 •

edited

Loading