Aave V3 on Aptos

Aave is launching its first non-EVM implementation of the Aave V3 protocol on the Aptos blockchain. This deployment represents a significant milestone as it marks Aave's expansion beyond EVM-compatible chains into the Move language ecosystem. The Aave V3 on Aptos implementation has been developed in the Move programming language, closely following the Aave V3.3 implementation but without the umbrella and liquid e-modes components.

To ensure the security and integrity of this groundbreaking implementation, Aave is partnering with Cantina to run a comprehensive bug bounty program. This program aims to identify and address potential vulnerabilities before they can be exploited, protecting user funds and maintaining the high security standards that the Aave community expects.

We invite security researchers, Move language experts, and blockchain security professionals to participate in this bug bounty program and help secure this innovative implementation of the Aave protocol.

About Aave

Aave is a decentralized non-custodial liquidity protocol where users can participate as suppliers or borrowers in a common pool. Suppliers provide liquidity to earn a passive income, while borrowers are able to borrow in an overcollateralized (perpetually) or undercollateralized (one-block liquidity) fashion.

Aptos and Move Language

Aptos is a blockchain designed for building scalable and secure dApps. Developed by former leaders of Meta's Diem blockchain project, it aims to address some of the limitations in existing blockchain systems such as throughput, scalability, and security. With its robust infrastructure, Aptos offers high transaction throughput, low and predictable fees, and advanced security through the Move programming language.

The Move programming language is specifically designed for secure asset management on blockchain platforms. It features a strong type system and linear logic that enhances security by ensuring resources can only be moved, not copied or implicitly discarded. This prevents common vulnerabilities like double-spending and provides inherent protection against reentrancy attacks, making it an ideal language for financial applications like Aave.

Aave V3 on Aptos Implementation

The Aave V3 on Aptos implementation is a complete rewrite of the Aave protocol in the Move language. It follows the architecture of AaveV3.3 but excludes the umbrella and liquid e-modes components. The implementation consists of several key packages:

• aave-acl: Access control list Package
• aave-config: Configurator Package
• aave-data: Data Aggregator Package
• aave-logic: Main Protocol Logic Package
• aave-math: Math library Package
• aave-mocks: Mocks Package
• aave-oracle: Chainlink Oracle Package
• aave-periphery: Periphery Package
• aave-pool: Pool Package
• aave-rate: Interest Rate Package
• aave-tokens: Tokens Package

This modular structure allows for clear separation of concerns and facilitates security analysis of individual components.

Scope

In-Scope Targets:

The following assets are considered in-scope for this bug bounty program: https://github.com/aave/aptos-aave-v3

• The latest commit on the main branch is considered in scope

• Smart Contracts (Move Modules)

  • All Move modules in the official Aave V3 on Aptos repository :
  • Specifically, all modules within the following packages:
    • aave-acl
    • aave-config
    • aave-logic
    • aave-math
    • aave-oracle
    • aave-periphery
    • aave-pool
    • aave-rate
    • aave-tokens

• Frontend and Interfaces

  • The official Aave V3 on Aptos web interface
  • API endpoints related to the Aave V3 on Aptos implementation

• Deployment and Configuration

  • Deployment scripts and configuration files
  • Parameter settings for the Aave V3 on Aptos deployment

Out-of-Scope Targets:

The following are explicitly excluded from the scope of this bug bounty program:

• Known Issues

  • Vulnerabilities that have already been reported or are known to the Aave team
  • Issues that have been identified in previous audits and are pending fixes

• Third-Party Dependencies

  • Vulnerabilities in the Aptos blockchain itself
  • Issues in third-party libraries or dependencies not developed by Aave
  • Chainlink oracle implementation (only the integration is in scope)

• Specific Exclusions

  • Theoretical vulnerabilities without a working proof of concept
  • Issues requiring privileged access (e.g., governance or admin keys)
  • Economic or tokenomic vulnerabilities that do not result in direct loss of funds
  • Gas optimization issues without security implications
  • Centralization risks inherent to the protocol design

• Non-Technical Issues

  • UI/UX issues that do not impact security
  • Documentation errors or inconsistencies
  • Spelling or grammar mistakes

Resources and References

Documentation

• Aave V3 Technical Paper
• Aptos Move Documentation
• Move Language Book

GitHub Repositories

• Aave V3 on Aptos Repository
• Aave V3 Core Repository

Previous Security Reviews

The reports for Aave V3 on Aptos implementation security reviews:

• Previous reports

Submission Process

How to Submit

1. All vulnerability reports must be submitted through the Cantina platform. To submit a report:
2. Create an account on the Cantina platform if you don't already have one
3. Navigate to the Aave V3 on Aptos bug bounty page
4. Click on "Submit a Bug" and fill out the required information
5. Provide a detailed description of the vulnerability and steps to reproduce

Required Information

All submissions must include:

• A clear description of the vulnerability and its potential impact
• Detailed steps to reproduce the vulnerability
• A working proof of concept (PoC) demonstrating the vulnerability
• An assessment of the severity level based on the criteria provided
• Any additional context or information that might be relevant

Proof of Concept Requirements

For all severity levels except Low/Informational, a working proof of concept is required. This can be in the form of: - Move code demonstrating the vulnerability - A script that reproduces the issue - Detailed instructions that allow the Aave team to verify the vulnerability

The PoC should be self-contained and executable in a local test environment to facilitate verification.

Rules and Guidelines

Responsible Disclosure Policy

All vulnerabilities must be reported exclusively through the Cantina platform and must not be disclosed publicly until:

1. The vulnerability has been verified by the Aave team
2. A fix has been implemented and deployed
3. The Aave team has granted explicit permission for public disclosure

Premature public disclosure will result in disqualification from the reward.

Testing Limitations

When testing for vulnerabilities:

• Do not test on public mainnet deployments
• Use local test environments or testnets for all testing
• Do not attempt to access or modify other users' data
• Do not perform any actions that could disrupt the normal operation of the protocol
• Do not use automated scanning tools without manual verification

Prohibited Actions

The following actions are strictly prohibited:

• Attempting to access private user data
• Social engineering or phishing attacks
• Denial of service attacks
• Physical or electronic attempts to access Aave infrastructure
• Any testing that violates applicable laws or regulations Threatening or harassing behavior

Duplicate Submission Handling

In the case of duplicate submissions:

• The first complete and verifiable report will be eligible for the reward
• Subsequent reports of the same vulnerability will not be eligible
• Reports that provide significant additional information about a previously reported vulnerability may receive a partial reward

Eligibility Requirements

Who Can Participate

This bug bounty program is open to all security researchers who:

• Are at least 18 years old or have parental/guardian consent
• Are not subject to sanctions or reside in countries under embargo
• Comply with all applicable laws and regulations
• Adhere to the rules and guidelines of this program

Restrictions and Exclusions

The following individuals are ineligible to participate:

• Developers who have worked on Aave Labs, BGD or any forks of the protocol at any point in time. Contributor with a meaningful amount of commits on Aave-related repositories.
• Security auditors that directly or indirectly participated in the review of exactly the code impacted.
• Entities that were compensated anyhow with funds of the DAO (excluding bounties recipients).
• Whitehats who already reported the same type of bug, with the same type defined as easy to infer by an Aave-expert party, like the Cantina reviewers.
• Individuals who have contributed significantly to the development of the Aave V3 on Aptos codebase Entities compensated by the Aave DAO (excluding previous bounty recipients)

Former contributors may become eligible if their last contribution was more than 24 months before the bug report submission.

KYC Requirements

Payment of rewards may be subject to Know Your Customer (KYC) verification. Participants should be prepared to provide identification documents if requested, especially for high-value rewards.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Likelihood. The combination of these factors determines the severity and guides the reward amount.

Severity Levels

Vulnerabilities will be classified according to the following severity levels:

• Critical

  • Direct theft of user funds (at least $100,000 at risk)
  • Permanent freezing of user funds (>$100,000)
  • Protocol insolvency due to accounting errors
  • Unauthorized minting of tokens
  • Permanent modification of protocol parameters leading to significant loss

• High

  • Direct theft of user funds (<$100,000 at risk)
  • Temporary freezing of user funds (>2 days)
  • Theft of unclaimed yield
  • Permanent freezing of unclaimed yield
  • Significant manipulation of oracle prices affecting protocol operations

• Medium

  • Smart contracts inoperable due to lack of funds
  • Griefing attacks causing temporary service disruption Unbounded gas consumption
  • Temporary freezing of funds (<2 days)
  • Incorrect interest rate calculations affecting protocol economics

• Low/Informational

  • Issues not directly impacting user funds or protocol operations
  • Best practice violations
  • Minor deviations from specifications
  • Code quality issues
  • Lack of input validation without security implications

Impact Assessment

The severity level of a vulnerability will be determined based on both its impact and likelihood:

• Impact Factors

  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access

• Likelihood Factors

  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Detectability of the exploit
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

Rewards will be paid in GHO according to the following structure:

Severity Level	Reward Range
Critical	$25,000 - $500,000
High	$5,000 - $25,000
Medium	Flat $5,000
Low	Flat $1,000

• Reward Calculation for Critical Vulnerabilities

  • For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to a maximum of $500,000. The calculation of the amount of funds at risk will be based on the time and date the bug report is submitted.
  • A minimum reward of $25,000 will be awarded for critical vulnerabilities to incentivize security researchers against withholding bug reports. There needs to be an absolute minimum of $10,000 at risk for a vulnerability to be considered Critical.

• Reward Calculation for High Severity Vulnerabilities

  • For high severity vulnerabilities, rewards will be capped at up to 100% of the funds affected, with a maximum of $25,000. In the case of temporary locking of funds, the reward will increase based on the duration of the lock, up to the maximum amount.

• Bonus Considerations

  • Additional bonuses may be awarded for:
    • Exceptional quality of the vulnerability report
    • Provided fix or mitigation strategy
    • Novel attack vectors or vulnerability types
    • Vulnerabilities affecting multiple components

Legal Considerations

Confidentiality Requirements

All information provided by Aave during the bug bounty program must be treated as confidential. Participants agree not to disclose any non-public information about the Aave V3 on Aptos implementation without explicit permission.

Terms and Conditions

Participation in this bug bounty program constitutes acceptance of these terms and conditions. Aave reserves the right to modify these terms at any time, with changes being effective upon posting to the bug bounty page.

Liability Limitations

Aave and Cantina are not liable for any damages resulting from:

• Participation in this bug bounty program
• Use of information provided during the program
• Actions taken based on vulnerability reports

Jurisdiction and Governing Law

This bug bounty program and all related activities are governed by the laws of the jurisdiction in which Aave operates. Any disputes arising from this program will be resolved according to these laws.

Appendices

Appendix A: Glossary of Terms

• Move Language: A programming language designed for secure asset management on blockchain platforms.
• Resource: In Move, a special type that can only be moved, not copied or implicitly discarded. Module: The equivalent of a smart contract in the Move language.
• Object: A Move resource that represents an asset or entity in the system.
• Signer: A special type in Move that represents the authority to execute transactions.
• Linear Logic: A logic system where resources must be explicitly consumed or moved, not implicitly discarded.

Appendix B: Technical Details of Move Implementation

The Aave V3 on Aptos implementation leverages several key features of the Move language to enhance security:

• Resource Types: All assets in the protocol are represented as resource types, ensuring they cannot be duplicated or destroyed without explicit operations.
• Access Control: The implementation uses Move's access control mechanisms to ensure that only authorized users can perform sensitive operations.
• Module Structure: The codebase is organized into modules with clear interfaces and minimal dependencies, reducing the attack surface.
• Formal Verification: Move's design facilitates formal verification of critical components, enhancing security guarantees.

Appendix C: Security Considerations Specific to Move Language

When reviewing the Aave V3 on Aptos implementation, consider the following Move-specific security considerations:

• Object Ownership: Verify that functions properly check object ownership before performing operations.
• Global Storage Access: Ensure that global storage access is properly controlled and authenticated.
• Function Visibility: Check that function visibility modifiers are appropriately used to restrict access.
• Type Safety: Leverage Move's type system to prevent common vulnerabilities.
• Resource Management: Ensure resources are properly created, moved, and destroyed without leaks or duplications.
• Cross-Module Interactions: Verify that interactions between different modules maintain security invariants.

Other Terms

By submitting a report, you grant Aave the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of Aave. The terms, conditions, and scope of this Program may be revised at any time. All participants are responsible for reviewing the latest version before submitting a report.