Tetu protocol proposes to use pools with enabled asset manager to be able to use the capital in a more efficient way
Motivation:
Usually, only a fraction of capital is needed to handle swap operations, the rest just idle in the vault. For example, Balancer Polygon Base Pool (B-POLYBASE) pool has around 2.7 mil TVL but average swap size is around 300$ which is around 0.01%. We propose to use the Relayer + Asset Manager combination to deposit part of the capital to 3rd party platforms and earn yield.
Can any member of the Balancer team chime in?
Also, I curious to know if this proposal needs to go to a vote for the above actions to be granted.
Maybe Gerg can give some guidance?
Yes, because permissions must be granted by the governance multisig.
IIUC this is a request to approve a new relayer, specific to Tetu’s new pools, that calls into the asset manager every time there’s a join/exit.
@belbix what are the your plans/expectations regarding interactions with this new pool type? Will you host a liquidity provision UI that supports this relayer? Will you maintain arb bots that trade against these pools? Do you expect organic volume to be routed through them?
The best option - include this pool in the Balancer subgraph and implement UI with a caption about all 3rd party risks.
We already have a similar solution - TetuSwap, UniV2 pools connected to our vaults, works pretty well but we want to focus on Asset Management, not building DEX.
Will be pretty cool to have some kind of collab - Balancer provides everything related DEX part, and we are taking care about maximize profit for assets inside pools.
What we will do if something will not so smoothly:
if no UI on Balancer we will implement UI on our side
arbitraging is not a problem, arb guys pretty fast grab any opportunity
About the difference with boosted pool - totally different systems.
Not sure why you suppose to think that boosted pools are better, they have low flexibility and utilization. Use only AAVE and only for 50% of available assets. It leads to some dust instead of normal profit.
as I explained in TG, boosted pools are not limited to Aave and not only available to 50% of assets. You have some misunderstandings about how boosted pools work ser.
yeah about utilization you are right, I forgot that linear pools could have different proportions.
I guess better to back to this discussion when @OlegN will have a good doc with procs and cons.
However, is it stopping the Balancer community from opening a proposal for whitelisting join/exit?
I prefer to proceed without a battle, I know that both solutions are not perfect.
You are correct that in most cases Boosted pools can do the same as Pools with Asset Managers.
But I think AM pools can handle big join and exit operations more efficiently (less fee compared with Boosted pools).
Also from the architectural standpoint AM pools are simpler because the Boosted pool is essentially ComposablePool + LinearPool + AssetManager (rebalanced) vs AM pool is just RelayedPool + AM.
In general, what is your concern related to AM pools?
I think we can have both options and will see which is more efficient.
have they been audited?
has balancer devs reviewed them?
how are rebalances handled?
what use cases does this unlock that boosted pools doesn’t cover? if there are none, can Tetu simply work within the framework of boosted pools?
I tire a little bit of this argument. If boosted pools are better than everything else, then why not let other things be tried. You very often make somewhat qualitative arguments (or at least not fully quantitatively sound ones) about how boosted pools are the most efficient way forward and use them as an excuse to argue against other things being tried.
Isn’t the point of decentralization, and more specifically the goal of the Balancer Decentralization and “Fernando’s Vision” to spur innovation and try new things that might come from outside the “councils” of the past?
Your points about clear specifications about how how things will be operated, audits to ensure that what the spec says is what will happen and to outline risks, and reviews by balancer devs or other external devs with deep understanding of the balancer ecosystem are valid. Arguing that no one else can build something unless they can prove it’s better than your idea, and putting the burdon of proof that this may be the case entirely on new developers trying to build in the space, weakens your otherwise good arguments.
If core pools are such a good idea, there are surly other approaches that work around the same concepts that could work very well, maybe even better. I’d even expect that as time goes on and there is more data to analysis, the likelihood of these innovations being discovered increases.
@OlegN@belbix I for one am looking forward to much more detailed documentation, and am also interested on how to deal with trust issues surrounding the asset manager, rebalancing and potential permissioned attack vectors that could be opened up.
why use a circle for a wheel when you can use a square? fair point ser. Apologies for even asking the question in the first place. Consider me in full support of this proposal moving forward.
I honestly think the questions asked by @solarcurve here were valid, including the one referencing boosted pools. I don’t think in this instance he was necessarily saying boosted pools are the greatest thing ever or “you must assimilate”. I think it is a legitimate question to ask, what new use cases does Tetu’s implementation cover that boosted pools can’t?
I for one like seeing new things, but at the same time I wouldn’t want to sacrifice safety, so it is also important to know/hear about steps being taken to reduce risk.
Waiting to hear about why AM’s are better. The original vision for Balancer v2 was to use AM’s exactly as Tetu describes. During the course of that development it was realized there were some very hard to solve problems with that, one of which being a clean way to keep the pool’s assets balanced between wrapped and unwrapped tokens. This led to the creation of linear pools which enabled boosted pools as we have them today, a replacement for the originally envisioned AM solution.
I am not here to attack honest builders in the ecosystem, I apologize if my comments come off that way. I greatly appreciate Tetu taking the time to build this AM solution. The reality is even if they spend money for an audit, Balancer devs review it, it is approved, there is still work to be done to integrate this into our UI and allow pools to be easily made to utilize it. This will be an uphill battle as Balancer team must be convinced of the merits to dedicate developer resources towards it. I say this not to be a gatekeeper, it is simply the reality in my opinion. I want to help get this done if it is truly a better mouse trap, all I care about is Balancer has the best technology. Makes zero difference to me who makes it.
Again, sorry for the tone and wording. I only want to understand why this is better than boosted pools or what it addresses that boosted pools do not.
Aren’t the proposed asset managers just as (in)flexible? All they do is deposit the tokens in the corresponding Tetu vault, isn’t it?
Can you please elaborate on this point? What fees are you referring to? What we do on the linear pools for large joins/exits is enter/exit the pool with the wrapped aToken instead of the main token. The frontend handles all the deposit/wrap/withdraw/unwrap complexity for the user and they pay 0 fees to the linear pool.
Simpler for whom? Keep in mind that:
Shrimp or whale, traders and LPs of linear pools never interact with the linear pool’s asset manager (rebalancer).
Linear pool keepers never interact with the composable pool and profit from the baked in incentives to rebalance the pool.
The complexity of dealing with composable and linear pools has already been abstracted by the SDK and the app and integrations. Traders, LPs and most aggregators have no idea how this works under the hood because we’ve put in the time to make it simple for them. And it will be even simpler for LPs with the upcoming generalized boosted pool support on the app.
In addition to all the concerns raised by solarcurve, in particular the above, another problem with a simple asset manager that does nothing other than what can be done by a linear pool is that it fragments liquidity at the base layer. With linear pools, anyone can create a pool with bb-a-DAI in it and share the DAI buffer with bb-a-USD. In the AM setup, a DAI/WETH pool needs its own DAI buffer in parallel to the DAI/USDC/USDT pool’s, thus reducing capital efficiency.
I appreciate all the effort you put into this, but because I want to see liquidity on Balancer be put to use on Tetu vaults I suggest you consider the boosted pool’s model, with a linear pool that replaces Aave with Tetu. Our engineers have been working with other teams on similar designs and I’m sure they’d be happy to assist you too with this.
For example, we have a linear pool with the following composition DAI (10) - aDAI(90). A user what to withdraw (swap BPT to DAI) more than DAI in a pool e.g 20.
Per my understanding of how Linear pool works. Such a case is either impossible in a single transaction (lack of DAI in a pool) or (if the amount is close to available DAI in a pool e.g 9.9) will lead to Linear pool imbalance → big fee.
From an architectural standpoint. More moving parts → hard to maintain, audit, etc. Higher probability of bugs. But I understand it is a weak argument The complexity is not much higher in this case.
I think in most cases protocols will create their own linear pools connected to their vaults instead of using AAVE backed version. But in general I agree that statement.
I didn’t get this point. For pools with AM we don’t need to have wrapped tokens in the pool.
I’d like to thank you guys @markus and @solarcurve I really enjoyed our discussion here because now I understand Boosted pool mechanics much better. We decided to build Boosted pool connected to the Tetu Vault in addition to AM version. I count upon your code review once it is done.
Metrics - Boosted pool easy to count.
AM holds assets outside of Balancer Vault, from the technical side it doesn’t matter, but it will probably not include in Balancer TVL on different platforms.
I guess it is a pretty important point in the current discussion.
Interest Bearing tokens (like xUSDC) still will be in the Balancer contract, but it will be hard to include them in counting (like DefiLlama).
Complexity - AM easier to use.
Balancer is complex.
But if you need to interact with boosted pool, the complexity becomes to new higher.
You can argue that Balancer has SDK, but the fact is any interaction with this kind of pool require more dev resources, more time, more testing and etc.
1inch on Poly doesn’t include Boosted pool in the route. Not sure about other networks/aggregators (you can check it).
Any boosted pool will require a manual handle on a ton of different places.
It is hard to scale.
AM is able to work as a regular pool, with no additional actions required.
Risks - same.
They are the same - pool holders have the same risk as underlying assets in both solutions.
Boosted pool will require Liner pool implementation, it is not a universal solution (yet). Same for AM.
AM solution was reviewed by the Balancer team, we put a lot of effort into it, and it is well-tested.
Maintenance - AM easier to maintain.
Maintenance is pretty similar in both solutions - you need to periodically rebalance assets inside.
However, for the rebalance caller AM will be simpler and cheaper (just call 1 function instead of wrap tokens, calc price and make a swap).
AM can self-rebalance on join/exit. Boosted pool not.
Flexibility - same.
Under the hood, both solutions can be pretty flexible. Nobody stops you to implement a pretty complex Linear pool. Or make it universal for ERC4626. The same for AM.
