Safely Forking the Aave Protocol
As decentralized finance (DeFi) continues to evolve, the Aave protocol has become a cornerstone for lending and borrowing platforms. Its robust design and feature-rich ecosystem make it a popular choice for projects looking to build on existing technology. However, forking Aave comes with its own set of challenges and risks, many of which have been highlighted through real-world incidents and bug bounty reports. This blog aims to raise awareness about these issues and provide actionable mitigation strategies for projects considering a fork of the Aave protocol.
Before You Fork
Before diving into the specifics, it’s crucial to emphasize a foundational principle: If you don’t fully understand the Aave codebase, don’t fork it. DeFi protocols operate in a high-stakes environment where even minor oversights can lead to catastrophic losses. Ensure your team has the technical expertise to comprehend the intricacies of Aave’s codebase and the potential vulnerabilities that may arise.
Code base: https://github.com/aave/aave-v3-core
Security checklist: https://github.com/aviggiano/security/blob/main/audit-checklists/Aave-fork.md
Additionally, familiarize yourself with the common issues reported in Aave’s bug bounty program and similar forks. Learning from these incidents can save your project from repeating the same mistakes.
Common Vulnerabilities in Aave Forks
Base on list of issues reported on their bug bounty program: https://governance.aave.com/t/bgd-bug-bounties-proposal/13077
1. Flash Loan Premium Not Passed Correctly to the Receiver
Issue: Incorrect handling of flash loan premiums can result in financial discrepancies.
Mitigation: Always fork from Aave’s latest stable commit (v3.0.2) to incorporate the most recent fixes.
2. Misusage of e-Mode Oracle Feed After Asset Removal
Issue: Removing an asset from e-mode can lead to oracle feed misuse.
Mitigation: Avoid enabling e-mode unless absolutely necessary. If used, implement rigorous testing and monitoring.
3. Griefing Risk with LTV0 and Isolated Collateral Assets
Issue: Setting assets to LTV0 can open the door to griefing attacks.
Mitigation: Use the pause functionality instead of changing assets to LTV0. Reassess this issue as your asset pool grows.
4. Price Manipulation Risks with Illiquid Assets (e.g., GUNI USDC/USDT)
Issue: Illiquid assets can be susceptible to price manipulation.
Mitigation: Conduct thorough evaluations of tokens before adding them as borrowable or supplyable assets.
5. Inconsistent Amounts in aToken Transfer Events
Issue: Discrepancies in transfer event amounts can create accounting issues.
Mitigation: Use Aave’s latest stable commit (v3.0.1) to address this issue.
6. Stable Rate Mode Bug
Issue: Bugs in stable rate mode can lead to unintended behaviors.
Mitigation: Disable stable rate mode entirely unless a specific use case demands it and thorough testing is performed.
Case Studies: Lessons from Notable Forks
1. Agave
Root Cause: Reentrancy attacks enabled by non-standard ERC667 tokens with post-transfer hooks.
Mitigation: Audit all L2 bridged tokens to ensure compatibility and security.
2. Radiant Capital
Root Cause: Exploitation of a rounding issue during the activation of a new market, allowing the attacker to manipulate the liquidityIndex and drain funds.
Mitigation: Adopt Aave’s policy of requiring mandatory deposits alongside any new listing.
4. Polter Finance
Root Cause: Chainlink’s BOO oracle became inaccurate during BOO pool v2 has manipulated through flashloan.
Mitigation: Choose strong, reliable borrow and collateral assets. Regularly review oracle dependencies.
5. Replay Attacks Using Digital Signatures
Issue: Replay attacks can occur if digital signatures are reused across different contexts.
Mitigation: Implement robust nonce mechanisms to ensure the uniqueness of each transaction.
Lesson Learned
Forking Aave can be a rewarding endeavor, but it’s not without its challenges. By learning from past vulnerabilities and implementing robust mitigation strategies, your project can avoid common pitfalls and build a secure, reliable platform. Always prioritize thorough audits, rigorous testing, and continuous monitoring to safeguard your protocol and its users.
Remember: Security is not a one-time task but an ongoing commitment.