Alchemix is a self repaying loans protocol. This contest covers the synthetic xerc20-enabled assets and the reward router that enables incentives for loan-takers.
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
For xalAssets
xalAssets are Layer 2 alAssets that are compatible with Connext's xERC20 system, also referred to as xTokens. Optimism and Arbitrum are currently live. Future plans include Layer 2 chains such as Metis, Linea, and Base. There are two xalAssets - xalUSD and xalETH (when already in the context of Layer 2, they are simply referred to as alUSD and alETH).
Reward router/collector
The reward router/collector is only currently intended to be deployed on Optimism, Arbitrum, and Ethereum.
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
xalAsset
xalAssets are tokens. Connext has mint/burn control via the xERC20 standards and whitelisting of the Connext bridge.
Reward router/collector
The reward router/collector will only interact with ERC20 tokens sent to the vault and queued by the multisig for distribution. Distributed tokens will be sold on an integrated dex for alUSD or alETH.
Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?
Gelato - Gelato is trusted. Gelato can be unresponsive - if gelato is unresponsive, the harvest will fail. This is acceptable as Alchemist admins can manually trigger harvests, and users will still accumulate credit/yield while waiting for a harvest.
Connext - Connext is trusted to operate properly, be responsive, and not steal funds or mint unbacked assets.
Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.
xalAssets
Admin role - trusted, can update the whitelist and map of bridges
Whitelist - allows contracts to mint the alAsset, including Alchemist contracts and bridges. It is assumed the Alchemist is safe/trusted, as all security functions to ensure backed minting of alAssets are covered by the Alchemist itself (which is already audited and live, and not in scope of this audit). Bridges are assumed safe/trusted, as security checks for minting/burning are done by the bridge itself, which is not in the scope of this audit.
Map of Bridges - Each whitelisted bridge is mapped to its rate limits
Reward router/collector
The router contract has an admin/owner. The admin/owner is restricted to sweeping tokens and updating the list of collectors. It should be assumed that this is always a trusted admin (multisig). The router calls the collector, which the gelato keeper calls as part of yield harvests. The gelato keeper is the only contract that can call harvests.
All Contracts
Contracts are upgradeable, so the audit scope would not include any economic damage a malicious administrator could cause from upgrades.
For permissioned functions, please list all checks and requirements that will be made before calling the function.
xalAsset - Admins need to verify that addresses and rate limits are correct when updating the whitelist and map of bridges.
Router Contract - Admins need to verify that addresses are correct prior to adding connector contracts to the list of connectors.
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
xalAssets
The xalAsset codebase is expected to comply with Connext's xERC20 standard.
The only deviation is that the old alAsset contracts have their own mint/burn functions that separate mint()/burn() and mintFrom()/burnFrom(). mint()/burn() is how a user mints/burns alAssets to/from their account. mintFrom()/burnFrom() is how a user gives another contract the right to mint/burn alAssets on their behalf.
Connext xERC20 merges all of these functions into mint() and burn(). Therefore, the canonical alAsset contract was modified as follows:
Mint() and mintFrom() functions did not require any changes.
Reward router/collector
Not designed to comply with any EIPs.
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
xalAssets
Connext monitors bridging off-chain and can pause bridging
Reward router/collector
The gelato keeper will call the harvester contract, which calls the harvest function on the Alchemist for regular yield AND calls the reward router. The router holds the reward tokens that the DAO intends to distribute and sends those tokens to the collector. The collector receives those funds and checks if there are any other funds to claim from a 3rd party protocol (ie, 3rd party rewards), then the collector swaps all the funds into alAssets and donates to the depositors.
Are there any hardcoded values that you intend to change before (some) deployments?
No.
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
It is acceptable to assume the sequencer won't misbehave or go offline.
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
These issues should be reported for xalAssets. They need not be reported for the reward router/collector contracts.
Please discuss any design choices you made.
xerc20
The past deployment of the bridging portion of alAssets on L2 is a fork of Frax's original bridge contracts. The contracts are being upgraded to be compatible with xERC20. See the “deviations from specifications” section above to describe the deviation in burn() functions.
The state variables of the old contracts cannot be deleted when upgraded, so the state variables of the old contracts related to the old bridging system could not be removed. The old functions have not been removed in case any oversights need to be undone related to the old state variables. Therefore, auditors should:
There is a crossChainCanonicalBase and an alchemicalTokenBase that are combined to create the xalAssets. The crossChainCaonicalBase has all of the old bridging functions and state variables that are not intended to be used, while alchemicalTokenBase has the new xERC20 functions and the standard alAsset functions.
Reward router/collector
1, One could in theory merge some collectors, but there is no large benefit in doing so
Please list any known issues/acceptable risks that should not result in a valid finding.
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
No - 7 days is acceptable.
Please provide links to previous audits (if any).
Please list any relevant protocol resources.
Additional audit information.
The primary difference between the battle-tested alAssets on Mainnet and the L2 xalAssets is the retired bridge system and the new xERC20 bridge system. This is the purpose of this audit - to ensure the upgrade to xERC20 is not creating any issues with the alAsset.
The reward router/collector has a very specific purpose—to receive a token from the DAO or 3rd party incentives, convert it to an alAsset, and then donate that alAsset to increase depositors' yield.
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
8,500 USDC
7,000 USDC
400 USDC
600 USDC
Status
Scope
Start Time
End Time
Finished
488 nSLOC
Apr 15, 2024, 3:00 PM
Apr 19, 2024, 3:00 PM