As of the time of this writing, the Alchemix Protocol has substantial deposits in the peg stability module, also known as the transmuter. In addition to acting as a backstop for the alUSD and alETH peg, the funds in the transmuter are deployed to yearn finance to earn additional yield which benefits alUSD and alETH debtors in the form of boosted yield.
The question going forward with the release of v2, is what to do with the 161m DAI and 51k ETH in the v1 transmuters. As the v1 transmuter will boost v1 yield, and the v2 transmuter will boost v2’s yield.
Migrating funds from V1 transmuters to V2 transmuters is relatively straightforward with some help from a small contract to act as a conduit for the funds.
Steps
- the DAO determines how much DAI/ETH should be migrated
- governance multisig calls TransmuterV1.pause()
- governance multisig calls TransmuterV1.recallFundsFromVault(<vault ID>, <amount>)
- governance multisig calls TransmuterV1.migrateFunds(<TransmuterConduit address>)
When TransmuterV1 calls distribute on the TransmuterConduit, the TransmuterConduit transfers the DAI/WETH from TransmuterV1, then transfers it to the relevant TransmuterBuffer, then calls TransmuterBuffer.onERC20Received(<dai/weth address>, <amount>) (just like the AlchemistV2 would).
This method of migrating transmuter funds is flexible, allowing for any schedule we like.
Migration Plan
The contents of the v1 Transmuter will be migrated to v2 Transmuter in even steps every week for 6 weeks. ⅙ the balance would move the first week, then ⅕, ¼, ⅓, ½, and 1/1 in the following weeks. V1 Transmuter contents will boost v1 Alchemix depositors, and v2 Transmuter contents will boost v2 Alchemix depositors. The rationale to do this in even steps over time is to ensure a predictable and orderly transition from v1 to v2. There wouldn’t be a rush to move over immediately, which would put less stress on the system overall as the markets could have time to react to users reestablishing their v1 positions in v2.
Alchemix V2 Transmuter Algorithmic Market Operator
The Alchemix Algorithmic Market Operator (AMO) is a proposed addition to the current peg stability module (PSM), the Transmuter. The AMO can perform even greater peg-maintenance functions, enhance the Transmuter, promote the growth of our TVL, and turn our biggest liability, liquidity provisioning, into a source of revenue.
This system is powered by smart contracts that can conduct monetary policy as long as it does not change the alUSD price off its peg. This does not give us the ability to print alUSD out of thin air, but by owning a significant chunk of the liquidity for any pair, it gives us extremely fine grained controls to maintain the peg, and can help bolster our efforts towards sourcing liquidity.
While this portion of the proposal is discussing the alUSD AMO, the same logic for how it functions can be applied to the future alETH AMO, meant to launch sometime after the alUSD AMO is up and running successfully.
There are 4 core operations of the Alchemix AMO:
-Add liquidity - pulls funds from the v2 transmuter buffer into the AMO contract. Migrated funds from v1 transmuter would be sent to this contract.
-Market Strategy - Deposit usdc, usdt, and dai into alUSD3CRV LP and then farm with the LP tokens on Convex Finance.
-Farming Strategy. The staked alUSD3CRV LP will earn CVX and CRV tokens. With these rewards, 100% of CVX should be locked to hasten acquisition of CVX for the DAO’s long term liquidity provisioning. Sell 80% of the harvested CRV for alUSD, and then use that alUSD for boosted yield debt repayments for v2 depositors. The 20% of CRV we do not sell will be locked and staked in cvxCRV, which will earn additional CRV, CVX, and 3CRV LP.
-Remove liquidity - if the Curve pool is imbalanced leading to alUSD going under $0.998 in USDC, withdraw alUSD single sided from alUSD3CRV and remove the alUSD from circulation.
The debt repayments will be a constant flow of paired assets (DAI, USDC, USDT) into the alUSD3CRV pool, putting positive price pressure on alUSD and deepening liquidity. They also grow the AMO, enhancing the system. This is the standard flow for the AMO – as long as the protocol owned liquidity hasn’t been completely withdrawn into alUSD. In the extreme case in which the AMO falls under a minimum non-alAsset balance, the AMO would be disabled and the public transmuter will be enabled to guarantee the 1:1 conversion of alUSD into another stablecoin.
The primary strategy serves as an algorithmic peg management system. By owning the alUSD3CRV and being able to withdraw liquidity single sided, it gives us fine grain controls over the balance of the Curve pool. If we are overbalanced alUSD, we simply withdraw enough alUSD to rebalance the pool once more. Future iterations of the AMO may permit some usage of the withdrawn alUSD, but for the initial version, these funds will simply be removed from circulation.
The Curve Convex strategy is what turns this from an interesting experiment into a killer app. In the diagram, we can see two initial inputs: stablecoin collateral debt payments feeding the AMO, and ALCX emissions bribing the Convex Curve gauge for the alUSD3CRV LP pool. The interplay between these two inputs has exciting consequences. The strategy would imply we deposit all Transmuter deposits into the alUSD3CRV pool. This will lead to a large alUSD premium, which will encourage more TVL in Alchemix, and will grow the AMO as people do the self-liquidation route to arbitrage the peg. These underlying tokens will be converted into alUSD3CRV, which we can then use to farm CRV and CVX on Convex. If the Transmuter’s deposits its current DAI balance into alUSD3CRV, the AMO will own 40% of the total pool, and accordingly our LP position would receive approximately 40% of the CRV and CVX rewards going to it. Furthermore, Alchemix is already on the path to accumulating a war-chest of CVX, as it is a key asset in provisioning liquidity through its influence on the Curve Gauge system. We can accelerate our accumulation by farming it in Convex.
The next part is the Convex bribes on Votium.app. We currently bribe about 10k ALCX a month for alUSD3CRV, alETHCRV, and d3 LPs. That's ~$1m a month with our current prices and emissions – which is only becoming more and more unsustainable in the face of disinflationary emissions. However, now this budget is not a complete liability for us with the AMO strategy. Alchemix currently owns 235k CVX, and together with these votes and our bribes, it leads to about 1.2m CVX votes for our pools per epoch. When we vote for the pool we bribe, we get rewarded with ALCX, which is effectively a rebate on our bribe. The more CVX we have (and thus % of the total votes for us), the more ALCX we get back. When factoring in the bribe rebates and CRV and CVX rewards, liquidity provisioning could transition from being our single largest liability, to being a minor expense, neutral, or even a source of profit. As this flywheel continues, we will earn more and more CVX, which will allow us to have sustainable liquidity incentives for our LPs on Curve by getting rebates on bribes and more CVX and CRV rewards (especially considering our future ALCX emissions). Furthermore, acquiring more CVX will help us in the bootstrapping phases for all new alAssets.
The MVP of the AMO will focus solely on the Convex flywheel strategy via a smart contract that contains all of the functions that are necessary to operate it. We can maintain security by having all of the callable functions be protected by whitelisted addresses who are allowed to call them. Most functions will be whitelisted for keepers so that they can automate the system. The contract will include a minimal proxy, which can execute arbitrary function calls. This was added because it can allow the AMO to be flexible enough to handle unforeseen situations in the future, such as governance voting or claiming airdrops. Since this function has potential for abuse, it will be locked behind the DAO’s timelocked multisig.
Recap:
This proposal seeks authorization of the Alchemix AMO as an enhancement to the v2 Transmuter, with the v1 funds migrating into it over the course of 6 weeks post deployment of the AMO.
A vote “for” authorizes this plan for migration and the addition of the v2 Transmuter AMO
A vote “against” rejects all proposed changes.
