Aero (also referred to as MetaDEX03) is Dromos Labs' multichain liquidity protocol, building on its earlier protocols, Aerodrome and Velodrome. Aero combines stable-swap, constant-product and concentrated-liquidity AMMs with an emissions system that lets AERO holders use their staking weight to direct newly issued AERO across chains and pools, earning trading fees and external incentives in return. Liquidity providers earn AERO emissions continuously by staking their liquidity positions in gauges. Base serves as the root chain and coordinates rewards and allocations across supported chains through Hyperlane messaging.

Aero also includes a range of important periphery contracts built around the core protocol. This includes the Relay for pooled staking and allocation management, and the Metarouter for batching protocol actions.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Conditions. 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 and immediate theft of user funds, other than unclaimed yield (>$500,000 USD)
  • Permanent freezing of funds, other than unclaimed yield (>$500,000 USD)
  • Unauthorized minting that causes significant dilution or allows assets to be withdrawn without corresponding backing
  • Serious protocol insolvency
• High
  • Theft of user funds requiring preconditions that can realistically occur
  • Theft of unclaimed yield
  • Permanent freezing of unclaimed yield
  • Temporary freezing of user funds (>7 days)
  • Forged deposits or artificially inflated balances that accrue yield without corresponding backing
• Medium
  • Loss of funds requiring preconditions that are unlikely to occur
  • Smart contract unable to operate due to unfixable lack of token funds
  • Smart contracts are inoperable due to unfixable lock of funds
  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
• Low
  • Minor loss of funds
  • Contract fails to deliver promised returns, but doesn't lose value
  • Issues not directly impacting user funds or protocol operations

Impact Assessment

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

• Impact Factors
  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access
• Conditional Factors
  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

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

Severity Level	Reward
Critical	50,000 USD - 500,000 USD
High	Maximum 50,000 USD
Medium	1,000 USD - 10,000 USD
Low	Maximum 1,000 USD

• Reward Calculation for Critical Vulnerabilities
  • To qualify as critical, a vulnerability must put more than $500,000 USD of funds at risk.
  • For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to a maximum of $500,000 USD. 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 $50,000 USD will be awarded for critical vulnerabilities to incentivize security researchers against withholding bug reports.
• Reward Calculation for High Severity Vulnerabilities
  • High-severity rewards are calculated as 10% of the funds directly affected, capped at $50,000. There is no minimum reward. Note: to encourage early reporting, we may award more than 10% of the funds directly affected if an issue could put substantially more funds at risk over time.
  • Temporary freezing of user funds qualifies as high only if the demonstrated freeze lasts more than seven days. Shorter freezes will be assessed lower severity.
• Repeatable Attacks
  • For repeatable attacks, only the first attack is considered if the smart contracts where the vulnerability exists can be upgraded, paused, or killed. If the attack impacts a smart contract directly holding funds that cannot be upgraded or paused, the amount of funds at risk will be calculated with the first attack being at 100% of the funds that could be stolen, and then a reduction of 25% from the amount of the first attack for every hour the attack needs for subsequent attacks from the first attack, rounded down.
• Preconditions

  • Preconditions are the circumstances required for an exploit to succeed. Examples include specific protocol states, transaction timing, available liquidity, and actions required from other users.

  • Severity depends on how likely these conditions are to occur in production and whether an attacker can create them. A condition that appears uncommon may still be realistic if an attacker can reliably cause it. These examples are illustrative and not exhaustive. No single precondition automatically determines severity.

Reward Payment Terms

Payouts are handled by the Dromos Labs team and are denominated in USD, paid on Ethereum mainnet.

General Notes

• Sherlock's Criteria for Issue Validity guide can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (PoC) with instructions to run it is required for all severities. The PoC must reflect production code and configuration, and demonstrate that the exploit’s prerequisites are achievable in production. Any artificial changes to balances, permissions or protocol state must be justified by showing how equivalent conditions can arise in production.
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage.

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Scope

Out of scope

• Best practice recommendations and feature requests
• Loss of rewards / rebases from burning an NFT prior to collecting the rewards / rebases
• Centralization risks
• Fee-on-transfer / non-standard ERC20 token compatibility issues
• Incorrect data supplied by third-party oracles. This does not exclude oracle manipulation or flash loan attacks.
• Attacks contingent on malicious governance (including 51% attacks)
• Impacts requiring basic economic and governance attacks (e.g. 51% attack). Note that these exclusions do not apply to vulnerabilities that allow users to obtain voting weight or emissions they are not entitled to, such issues would be valid.
• Lack of liquidity impacts
• Impacts from Sybil attacks
• Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
• Impacts caused by attacks requiring access to leaked keys/credentials
• Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
• Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
• Mentions of secrets, access tokens, API keys, private keys, etc. in GitHub, without proof that they are in use in production
• Impacts on test files and configuration files
• Vulnerabilities that have already been reported or are known to the protocol team
• Issues that have been identified in previous audits and are pending fixes
• Vulnerabilities in the blockchain itself
• Issues in third-party libraries or dependencies not developed by the protocol team
• Theoretical vulnerabilities without a working proof of concept
• UI/UX issues that do not impact security
• Documentation errors or inconsistencies
• Spelling or grammar mistakes
• Impacts requiring phishing or other social engineering attacks against the project's employees and/or customers
• Vulnerabilities originating in third-party protocols, such as Hyperlane
• Losses caused by user mistakes
• External network outages, sequencer downtime or message-delivery failures
• Temporary denial of service issues where the affected operation can be successfully retried immediately

Disclosure Policy

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

1. The vulnerability has been verified by the protocol team
2. A fix has been implemented and deployed
3. The protocol team has granted explicit permission for public disclosure
   Premature public disclosure can result in disqualification from the reward.

Testing

When testing for vulnerabilities:

• Do not test on mainnet or public testnet deployments; all testing should be done on local forks of either a public testnet or mainnet
• Do not test with pricing oracles or third-party smart contracts
• 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 against the project's 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
• Physical or electronic attempts to access the protocol's infrastructure
• Any testing that violates applicable laws or regulations
• Threatening or harassing behavior
• Public disclosure of an unpatched vulnerability

Additional Context

Chains in scope

Base (root chain), Ethereum, OP Mainnet, Arc, Ink, Robinhood, Arbitrum.

Findings that depend on behaviour unique to a chain the protocol does not deploy on will be considered out of scope.

Tokens

Standard ERC20 tokens. Fee-on-transfer and other non-standard ERC20 tokens are out of scope.

Trusted roles

Protocol-appointed contract owners, administrators and operators are trusted to use their permissions as intended. Relay administrators and operators are trusted within their respective Relays and associated modules.

Protocol resources

• Aero
• Aero contracts (MetaDEX03)
• Aero concentrated-liquidity contracts (MetaDEX03 Slipstream)
• Aero contracts auditor guide

Previous audits and known issues

All issues in the audit reports below are considered known issues, as are the accepted behaviors listed in Aero's audit notes and the Known Issues section of the Aero contracts auditor guide.

• ChainSecurity final audits [PENDING PUBLICIZING REPORT]
• Sherlock Blackthorn final audits: [PENDING PUBLICIZING REPORT]
• Sherlock Audit Engine public contest [PENDING PUBLICIZING REPORT]
• Sherlock Blackthorn, phase 1 and phase 2
• ChainSecurity: application layer, Slipstream application layer, coordination layer
• Riley Holterhus solo audit
• Grego AI audit scan