How does tapETH maintain a peg?
Last updated
Last updated
The primary goal of tapETH is to maintain a 1:1 peg with native ETH. In an ideal scenario, each unit of tapETH would always represent the value of one unit of ETH. However, the reality of market dynamics requires a system that can adapt to fluctuations and imbalances.
At the heart of our peg maintenance system is dynamic collateralization. This mechanism ensures that the total value of assets in the pool always sufficiently backs the total supply of tapETH in circulation.
If the exchange rate between LSTs and ETH is 1:1 (fairly close to it), tapETH is 100% collateralized. In other words, each tapETH is backed by exactly one unit of ETH or its equivalent in LSTs. If the exchange rate shifts dramatically however, the system responds by overcollateralizing tapETH, meaning each tapETH is now backed by more than one unit of ETH or its equivalent.
This process of dynamic collateralization is the key to maintaining tapETH's peg to ETH. It automatically adjusts to ensure that tapETH's value stays stable relative to ETH, even when the market conditions change.
For example, let's say the pool composition becomes heavily imbalanced, or one of the underlying LST depegs heavily - our algorithm will put a discount on the oversupplied asset and a significantly larger premium on the undersupplied asset, meaning tapETH in this moment is overcollateralized (or said another way, has more value backing the amount of circulating tapETH as a result of the dynamically adjusted exchange rates between the underlying assets). This is able to be manifested in 3 separate ways:
The undersupplied asset is more expensive (and hence discouraged) to swap out of the pool. This heavily increases the collateralization ratio.
The oversupplied asset is cheaper (and hence encouraged) to swap out of the pool. This reduces the collateralization ratio of tapETH, but far less than the premium increases it - as the pool is always biased towards overcollateralization.
The undersupplied asset can be deposited to mint more tapETH in exchange. This is meaningful because of course, tapETH is meant to be pegged with ETH.
Underpinning this entire system is Tapio's StableAsset architecture. This governs how the system responds to changes in the value of the underlying assets in the liquidity pool and is determined by 2 variables (which you learn more about in the Algorithm page):
Parameter D: Represents the total value of the assets in the pool. When all assets are equally priced (i.e. fairly balanced), 1 tapETH is backed by 1 ETH worth of underlying assets.
Parameter A: Determines how quickly the system responds to changes in the underlying assets' value - this is referred to as the "wideness" of the price curves below.
For context, the Uniswap invariant (purple dotted line) is the pricing curve of their liquidity pools meaning it's quite fast to apply discounts to the undersupplied asset as the protocol is favoring a "Constant Product Model" - which means they're prioritising the ability to be able to swap the underlying assets at a fairly consistent exchange rate.
On the other hand, the "Constant Price" curve (red dotted line) has zero flexibility and instead effectively means that there is no volatility when it comes to the exchange rate of the underlying assets. This is referred to as a "Constant Sum Model" - where swapping any asset for another in the pool will always be close to a 1:1 exchange. This is also the "widest" pricing curve possible.
Where Tapio's StableSwap invariant sits however (blue line), is far wider than Uniswap's pricing model (which could be described as "thin"), with it biased towards the Constant Sum Model. How this manifests is, we also institute the same discounts and premiums that Uniswap does, however only when our pools are significantly more unbalanced, and the exchange rates applied are also far more dramatic when implemented.
The reason for this is because all the assets within tapETH are correlated to some degree (and also individually have a high amount of liquidity in the ecosystem), and hence we want to allow our pools to fluctuate quite a bit without affecting regular market activities and introducing too much volatility into the exchange rates of tapETH's underlying assets - but also maintain the ability to encourage/discourage behaviour accordingly when the pools are considerably unbalanced.
When our governance goes live, the community will eventually be able to determine how "wide" our pricing curve should be.
