Alchemix is your unified platform for saving, earning, borrowing, and fixed-term fixed-yield opportunities—all in one place. Built on years of iteration since launching the original self-repaying loan in 2021, Alchemix v3 brings all three pillars together with a smarter, more flexible design.
Live
Triaged by Immunefi
Step-by-step PoC Required
This Audit Competition Is Live!
$100,000 USD in rewards is available for finding bugs on Alchemix’s V3 contracts.
For more information about the project, please visit about Alchemix
-
KYC is not required.
-
Flat Reward Pool
Proof of Concept (PoC) Requirements
-
A runnable PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.
-
Any technical questions and support requests can be asked directly to Alchemix team or Immunefi in the #alchemix-v3-audit-competition discord channel.
Rewards
Rewards by Threat Level
Rewards are distributed among SRs according to Immunefi’s Standardized Competition Reward Terms and includes All Star Pool and Podium Pool reserved for All Star Program participants.
Rewards are denominated in USD and distributed in USDC on Optimism
The reward pool is $100,000 USD if any bug is found. That means that even if 1 Low severity bug is found, the whole reward pool is unlocked and has to be fully distributed between security researchers.
If not a single bug is found (Insights do not count as bugs) the insight reward pool is $15,000 USD.
Proof of Concept (PoC) Requirements A runnable PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.
Program Overview
Alchemix is your unified platform for saving, earning, borrowing, and fixed-term fixed-yield opportunities—all in one place. Built on years of iteration since launching the original self-repaying loan in 2021, Alchemix v3 brings all three pillars together with a smarter, more flexible design. The protocol allows you to:
- Save and grow – deposit ETH or USDC and let our vault invest and earn yield across diversified strategies.
- Borrow up to 90% LTV – access liquidity now while your collateral grows with yield and your leverage is reduced over time through scheduled redemptions. No interest rates to monitor, no price-based liquidations.
- Earn fixed-rate yield – lock in predictable returns through fixed-term redemptions of alETH or alUSD.
There are a few elements to the system. First, there is the Meta Yield Token. This is a Morpho V2 vault with custom strategies and some custom admin roles. There is an ETH and a USDC vault for each chain.
The core system is based around the Alchemist/Transmuter. Alchemists mint alAssets, and accept MYT as collatearl. Each Alchemist has a single alAsset it can mint (alETH for ETH, alUSD for USDC). Each Alchemist can only accept a single MYT token as collateral (MYT ETH for alETH Alchemist). Each Alchemist has a single Transmuter paired with it, and each Transmuter is only paired with a single Alchemist.
The Transmuter’s role is to redeem alAssets. Users may deposit alAssets to the transmuter. After a fixed period of time, they may claim equivalent value (based on protocol assumption that 1 alAsset = 1 Underlying, ie 1 alETH = 1 ETH) of the MYT.
The Alchemist’s role is to accept the MYT as collateral, mint alAsset debt, and fulfill redemption obligations to the transmuter. When a transmuter claim is executed, the Alchemist reduces global system debt, and sends MYT from the alchemist to the transmuter user. Thus, when a redemption occurs, an individual Alchemist position will see both their collateral and debt reduced.
To ensure collateral will always be available for redemptions, the Alchemist employs an earmarking system. Essentially, the system will reserve collateral and debt from user positions for future transmuter claims (time-based, continuous). Earmarked collateral cannot be withdrawn from the system. The only way to withdraw earmarked collateral is to repay earmarked debt with external MYT tokens. Separately, non-earmarked collateral/debt may be repaid and/or withdrawn at any time (subject to LTV requirements).
The MYT strategies are meant to be priced based off of fundamental oracles, ie the backing of each strategy. This is meant to avoid unfair liquidations due to flash crashes. Additionally, the MYT is never unwrapped or wrapped with the Alchemist - this is why transmuter positions recieve MYT tokens at time of redemption, not underlying.
The MYT strategies have a dual-unwrap approach through contracts and dexes. When a better outcome is gained through a dex (vs wrapping), a dex is used. For unwrapping, if the contract unwrap is unavailable (due to a queue), a dex is used. Thus, the MYT may be worth 1 ETH from the Alchemist point of view, even if the unwrap value at that exact instance is 0.99 (due to one of the strategies having a withdrawal queue). For this reason, long-tail risk strategies should not be used in the MYT.
Audits
Known Issues
KYC not required
No KYC information is required for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.