Multisig Admin Rights

Access Control

Alchemist Contracts

Alchemist contracts for alUSD and alETH allow the user to create a collateralized debt position by depositing tokens as collateral and taking debt against the collateral by minting alUSD or alETH.

Each Alchemist Contract has the following privleged roles: Admin, Sentinel, and Keeper, with the following privleges:

1. Admin

   • Add tokens to the list of underlying and yield tokens supported by the Alchemist

   • Enable and disable tokens from this list

   • Add and remove sentinels and keepers

   • Transfer the admin role to a different address (must be accepted by the new admin)

   • Configure the Alchemist's parameters, including limits, fees, and the addresses of the transmuter and protocol fee reciever

   • Reset ("snap") the expected value of a yield token to the current value. Since deposits, withdrawals of the underlying, and liquidations are blocked if the value of a yield token suddenly drops significantly below its expected value, this can prevent the contract from becoming unusable if the yield token doesn't recover, or takes too long to recover.

   • Disable or enable whitelisting requirements

2. Sentinel

   • Sentinels can disable (ie, pause) underlying and yield tokens. pauseUnderlyingToken() will disable deposit(), depositUnderlying(), repay(), and liquidate() functionality for the given underlying token. pauseYieldToken() will disable deposit(), depositUnderlying(), withdraw(), withdrawUnderlying(), liquidate() and harvest()for the given yield token (ie, given yield strategy). See Pause Control below for more information.

3. Keeper

   • Keepers can trigger harvests of the yield tokens.

Upgradeability

One major design choice of note in Alchemix v2 is that of upgradeability. All 3 major contracts (AlchemistV2, TransmuterV2, and TransmuterBuffer) are built to be used via upgradeable proxies. This entrusts the Alchemix DAO with the ability and responsibility to upgrade the functionality of these pieces as it sees fit.

Pause Control

Sentinels have the ability to pause yield tokens should there be an issue. Admins may then unpause the tokens. When an underlying token is disabled, it should be noted that the withdraw(), withdrawUnderlying(), repay(), mint(), and burn() (ie, repay debt with alAssets) functions can still be called - allowing users to settle their debt and withdraw the yield token or underlying token.

Each accepted yield token has a configured maximum amount of loss that it can experience and still function normally. If the yield strategy loses more than the specified maximumLoss, then the yield strategy is paused automatically, meaning users may not make any deposits, may not liquidate or repay, and may not take a new loan with these strategies. Harvests will also be disabled. Lastly, users will be unable to withdraw collateral in the form of the underlying asset. Users will still be able to repay their loan and withdraw the yield token, however. For example if the maximumLoss was exceeded, a user could not withdraw DAI from a strategy that uses yDAI, but they would still be able to repay their loan with DAI to withdraw their yDAI collateral).

Sentinels also have the ability to pause underlying tokens should there be an issue. This would only be applicable to alAssets with multiple underlying tokens, such as alUSD. If an underlying token is paused, the deposit(), depositUnderlying(), liquidate(), and repay() functions would be disabled for that token. Notably, debts may still be paid down by harvests and users may repay debt with alAssets or other underlying tokens and withdraw their funds.

Multisigs, Timelock, and veALCX

The Alchemix Developer Multisig acts as the admin for the Alchemix contracts as well as the owner of the operational budget for the protocol. Separately, the timelock multisig holds the majority of DAO-owned ALCX and owns the sweep functions of the AMO contracts (ie, AMO funds can only be removed from the AMO contracts by the timelock multisig). The timelock is currently 600 seconds, reduced from 24 hours in resonse to the July 30th Curve Exploit. In the future, the timelock will likely be retired and all admin controls will be assigned to a mix of veALCX and the dev multisig, with a goal of shifting more power to veALCX and away from the dev multisig over time.

More Information

For more in-depth information on admin controls and contract features, see the v2 audit and developer docs.