Features and codebase deep dive.
Outline
0. Intro
1. Passive rebalancing
2. Conditional rebalancing
3. Low gas cost
4. the Minimalism
5. Warnings for apes
6. Conclusion0. Intro
As I mentioned in Uniswap v3 Features Explained in Depth:
LP strategies and the aggregation of NFT of Uniswap v3 liquidity token are becoming the blue ocean for new DeFi startups.
Today we’re going to look at the first live Uniswap v3 LP strategy (afaik):
Charm.fi is an anonymous team that has built two DeFi products already: leverage tokens Cube Tokens and options Options.
Two days after the launch of Uniswap v3 on May 5th, Charm deployed its third product Alpha Vault, an Uniswap v3 LP strategy, and has proven to be quite successful: over two times more profitable than the v2-style LP!
No wonder many jumped in and filled up its first ETH/USDC pool, even though there’s an obvious warning banner on the website: this project is unaudited.
Now, let’s dive into Alpha Vault’s strategy and its codebase with a bit of background music!
1. Passive rebalancing
The understanding and explanation of this article come from the official announcement article, its Github repo and my chat with Charm’s developer mxwtnb.
As their article already did a great job explaining, I will try to only go through the same thing when it’s necessary.
The price of a pair changes constantly, which means the liquidity of a provider won’t always be central to the current price. Thus, a delicately designed rebalancing mechanism is the core of a strategy.
That of Alpha Vault is extremely simple but effective: when the two assets become imbalanced and cannot put all of them into the pool, the Vault first puts the max available amounts of the two into the pool and then place another range order with the surplus one.
Let’s have an example. (If the following explanations of price movement and asset exchanging rules are unclear for you, check out this article for the basic mechanisms of Uniswap v3 first.)
Originally we have assets composed of 50% ETH and 50% USDC. One day later, as the price drops, we get more ETH and less USDC.
- ETH price = 3000: (50% ETH, 50% USDC)
- ETH price = 2500: (70% ETH, 30% USDC) -> withdraw all
Now, say the max amount of the two we can put into the current range is 30% ETH and 30% USDC.
What the Vault does is to first withdraw all the liquidity, and then place a base order with 30% ETH, 30% USDC and a limit/rebalancing order with 40% ETH, 0 USDC.
- Base order: (30% ETH, 30% USDC) -> put in the current range
- Limit/rebalancing order: (40% ETH, 0 USDC) -> place in a range whose prices ≥ current price, ex: (2500, 2600), such that when the price goes up ETH can be exchanged for USDC
Allow me to shamelessly borrow one image from their article:
Similarly, if we have USDC surplus, put the extra USDC in a range whose prices ≤ current price, such that when the price goes down USDC can be exchanged for ETH.
What the limit/rebalancing order does is to avoid direct swapping (swapping 20% ETH into 20% USDC), which causes 0.1~1% of transaction fee charged, but to let the swapping occur naturally through providing liquidity, which does not take a penny but can rather earn transaction fee.
This is the reason for “passive” rebalancing.
However, there is an assumption in the above example with ETH surplus: the limit order can be fulfilled only when the price of ETH goes up, which is apparently opposed to the reason why our assets become imbalanced: the price drops from 3000 to 2500.
The assumption is, however, pretty realistic, as there’s always consolidation.
Let’s take a look at the real ETH price: we can have a time with several green bars/pump coming in a row, but red bars/consolidation always follow by.
Okay, then, what if the price keeps dropping?
2. Conditional rebalancing
If the price keeps dropping, the Vault might do nothing, which means: no rebalancing.
LPs of Uniswap v3, compared to v2, might suffer from a larger impermanent loss (IL) if adopting a wrong LP strategy.
Thus, it’s pretty reasonable that there are times when it’s better not to take any action.
In AlphaStrategy.sol, there are two conditions checks (require()) in rebalance() that judge whether a rebalancing is necessary.
- Extreme prices which should never happen
- The price moves too much -> to avoid price manipulation before rebalancing or extreme market conditions
Apart from these two, there used to be another condition (at the time when I started writing this article):
- The price does not move much -> to avoid redundant gas usage
The reason why it is not included in the current smart contract design is that this condition is now moved off-chain, according to the dev.
The choice between on-chain or off-chain depends on whether the condition should always be strictly obeyed: if yes, on-chain; else, keeping it off-chain can provide better developing flexibility, considering that this strategy is still in its early stage.
3. Low gas cost
(According to the dev, this feature is implemented recently and thus not aligned with the contract of ETH/USDC Vault already on mainnet. )
Those who have tried putting liquidity into a v3 pool already must know that this process is not really cheap.
What about the gas cost of depositing into Alpha Vault? Is it going to be more expensive than adding liquidity on v3, since there are also the logics of the Vault?
The answer is: way cheaper than adding liquidity to a v3 pool!
How? The reason is that depositing $ into Alpha Vault won’t lead to the action of adding liquidity on v3.
The movement of liquidity only happens when rebalancing, which means individual users don’t pay for the high gas cost of adding and removing liquidity. Currently, it’s the team’s own keeper fulfilling the duty of rebalancing at the frequency of twice per day recently.
Low gas cost, lovely! But doesn’t that also mean the fund a user deposits into the pool won’t get utilised until the next rebalancing? Yes. However, adding liquidity isn’t like buying a 10x perpetual contract; it’s usually a long-term or at least mid-term investment.
Losing the capital efficiency of several hours is not a big deal if a user is providing the liquidity for months. Plus, the gas cost is lower!
Pro tip: if you’re about to deposit into Alpha Vault, check out the Vault’s smart contract and see if the rebalancing just happens. If yes, there is no rush and you can wait for a lower gas price!
So, combined with the description in 2. Conditional rebalancing, is it possible that under extreme market conditions the fund a user deposits might be idle for a few days?
The answer is still YES, but that’s exactly the reason why there are conditions on whether the vault should rebalance or not: for protecting the users.
4. the Minimalism
- Moving liquidity around only when rebalancing
- Rebalance only when it’s needed
- Swapping tokens through providing liquidity instead of direct swapping
Before opening up their Github repo, it’s hard for me to imagine a v3 LP strategy to take only about 700 lines of code.
Apparently, the team is doing everything to minimize the strategy's complexity, which is why I call Alpha Vault the Minimalist LP Strategy!
There will be more strategies coming out for sure, and it’s expected that many are going to also employ Alpha Vault’s techniques, such as the passive rebalancing trick to avoid the transaction fee.
Let’s see if there’s another that can achieve the same performance and simplicity as Alpha Vault!
5. Warnings for apes 🙈
With the above understanding of the project, sounds like it’s about time to ape in… just wait.
As the project is not yet audited (it’s underway), there are two emergency buttons prepared for exceptional circumstances, such as serious bugs found.
In AlphaVault.sol, as the contract is not yet finalized, the governance/project owner has the rights to emergencyBurn() and emergencyWithdraw(), which means pulling the liquidity out from a pool and then transferring it to the governance.
Therefore, if one day the team is ready to finalize the contract (set finalized to true), probably after passing the audit, people will no longer have to worry about this issue.
Preserving privileges for emergencies in the early stage of a project is pretty common, but please bear these risks in mind before putting your life savings in, especially since Charm is an anonymous team.
Me mentioning this is not intended to stop people from using it but to merely remind people of the forever risk of putting $$ into smart contracts. After all, smart contracts can still be hacked no matter how many audit reports are backing them up.
Personally, I have read through their code, love the simplicity of their strategy and will definitely give it a go after the contract is finalized! But it’s all about the cliche: never invest more than you’re willing to lose.
6. Conclusion
That’s pretty much all the features of Charm’s Alpha Vault. Not really expecting such a simple strategy, right?
If you feel excited about trying Alpha Vault out, there’s another ETH/USDT vault coming on May 24th. Be sure not to miss it out!
The last thing I’d like to mention is: all Charm’s products are built by one dev only. How amazing and productive! I’m a big fan right now 😆
As usual, if you have any doubt or find any mistake, please feel free to leave a comment below!
Disclaimer: The content of this post is not investment advice.
