Why Liquidity Pools?
Or why did Tapio Finance choose stable pools between ETH and LSTs?
Last updated
Or why did Tapio Finance choose stable pools between ETH and LSTs?
Last updated
Stable pools between 2 correlated assets have existed for as long as DeFi has in one form or another and are quite simple to understand, not to mention have been stress tested through countless events within the ecosystem. As a result, each of the individual pools is siloed and while making a portion of the overall tapETH pool, are fundamentally separate which means that the underlying assets are not directly exposed to one another.
Pools with multiple assets (3 or more) however haven't been as prominent with the only meaningful examples of usecases with traction and market testing being stablecoins, such as the 3Pool on Curve Finance between USDC, USDT and DAI. However continuing from this of course was the 4Pool which included UST, and as we saw - led to huge losses and pain for LPers.
In Tapio Finance's pools - issues are local to the specific stable pool, and in times of great strife - governance or the team can detach the stablepool from the protocol (and tapETH) temporarily should it be necessary. This of course is a worst-case scenario failsafe, however simply isn't possible if all the underlying assets are within the same pool.
As time goes on, more and more LST protocols will become live and rise to prominence, with tapETH containing more and more of these individual assets where this architecture will truly showcase its effectiveness in protecting users and limiting exposure.
The most significant benefit to having various stable pools is the pricing stability of not only tapETH, but also the underlying LSTs. Because each of the pools is between native ETH and an LST, each supported asset only has to have a pricing curve with ETH, and hence there are far fewer variables involved when it comes to the underlying composition, and what discounts/premiums must be applied.
These stable pools, while existing within the greater tapETH pool - are indeed independent and can be interacted with just like any other LP. Why this is important is that users are able to engage in arbitrage very easily, in a familiar architecture. If an asset is relatively low in a pool, users can either buy it at a discount, or receive a premium on the oversupplied asset, by being able to mint more tapETH for the same amount - without much analysis or due diligence required.
Having tapETH backed by risky assets (LSTs) is of course adding to the risk profile for users, however with a large amount of its backing being native ETH (a low-risk asset), there is adequate "cushioning" as in the worst-case scenario, the assets will only be drained from a single stable pool, and not the entire overarching pool.
For example, if stETH becomes heavily depegged, ETH will only be drained from the stETH-ETH pool, and not from the parallel rETH-ETH or frxETH-ETH pools. ETH deposits from that point on will then be swayed towards that pool (on the backend, however users can still deposit into any pool they wish), as well as incentivized with premiums on tapETH. This not only ensures tapETH maintains its peg, but also dramatically improves the LSTs' ability to recover from a mispricing event.
When it comes to arbitrage, it is very rarely done between 2 "risky assets". For example, with LST depeggings, users do not realize their gains with another LST, but instead, the fundamental asset of the ecosystem - native ETH.
As a result, having ETH being within each and every pool means bolstering swap volume and redemptions, both of which generate fees - is far easier than simply relying on the value proposition of being able to swap between LSTs (which would be the case in traditional baskets or multipools).
Another thing to keep in mind is, arbitrages can occur between each of Tapio's pools, which is not possible if opting for a basket/multipool model - and also allows users to realize arbitrages within our platform natively (i.e. without having to go to another DEX if they so wished). Of course, once we integrate our pools with other DEX's, this will be less important, but early on as we build our TVL, it'll be exceptionally meaningful.
Because the individual supported assets exist within their own independent liquidity pools, it is extremely scalable - with each additional LST simply able to be included as a brand new LST-ETH pool. With a multi-asset liquidity pool (like 3Pool), each asset is directly exposed to every other asset within the pool, which introduces considerable security and risk concerns.
This xPool (x meaning number of assets) model has been tested with stablecoins to varying degrees of success, however as we've seen with USDC's depegging, or UST's collapse - the pool itself either breaks entirely, or becomes excessively imbalanced, with no meaningful mechanism of recovering (aside from market demand). As a result, while decent as a new experiment within the niche of LSTs, it simply hasn't been stress tested in a real environment with significant amounts of TVL or demand.
The pricing curves and mathematics also become increasingly complicated as more and more LSTs are added to these pools, which will most likely result in less meaningful arbitrage or trading opportunities due to the sheer number of compromises that'll have to be made to ensure efficient and simple swaps - not to mention, once you surpass 3 or 4 assets, you're entering unexplored territory. However, when creating a new LST-ETH pool, the maths remains the same as every other pool on the platform, without any added complexity or the need to have faith in the team's ability to execute novel pricing mechanisms.
Simple dual-asset liquidity pools however, have been in use for years within DeFi - and as a result, is far less risky to introduce new assets within separate liquidity pools since the risk is compartmentalized (and is also able to be limited by placing a cap on the weighting of the pool within tapETH itself), limiting potential contagion.
