Arcadia Finance Smart Contracts: Program info

IN SCOPE VULNERABILITIES: Smart Contracts

All targets are deployed on Base, Optimism and/or Unichain. Contract addresses can be found at: https://docs.arcadia.finance/developers/contract-addresses Only the code Arcadia-developed code of the deployed contracts is in-scope. Anything outside these files (tests, mocks, scripts, deployment tooling, and third-party dependencies/imports) is out of scope.

The "Max reward tier" indicates the highest severity payout available for each asset. It does not mean every finding in that repo is Critical. Severity of an individual report is determined solely by its demonstrated impact (see below).

Severity Classification & In-Scope Impacts

This program follows the Primacy of Impact principle. A report is only valid if it: (a) demonstrates one of the in-scope impacts listed below AND (b) demonstrates behavior that deviates from the protocol's intended and documented design. Identifying a coding flaw, deviation from best practice, or theoretical weakness that does not result in one of these impacts is out of scope, regardless of the bug class (reentrancy, overflow, reordering, etc. are root causes, not impacts).

An outcome that the protocol is designed to produce is not a vulnerability, even when it results in loss of funds. For example, bad debt or under-collateralization that arises because a liquidation does not recover sufficient value during normal market conditions (e.g. a steep drop in collateral price) is an intended and accepted property of the protocol's risk model, not a finding. To qualify, a report must show that the loss stems from a defect in contract logic that causes behavior to diverge from the intended design, not from market risk, asset volatility, or the normal operation of the liquidation, interest, or pricing mechanisms.

Severity is assigned by impact, not by the vulnerability category:

1. Critical: Direct theft of user funds; permanent (irreversible) freezing or loss of user funds; protocol insolvency or bad debt borne by users caused by a defect in contract logic (not by normal market risk, see rules above); unauthorized minting, burning, or modification of user balances.
2. High: Temporary (recoverable) freezing of user funds; theft or permanent freezing of unclaimed yield/funds; any loss of funds limited to protocol- or admin-controlled funds; any fund loss that requires a privileged/trusted role to execute and which is not an assumed trusted, priviledged flow.
3. Medium: Griefing or denial-of-service with no direct loss of user funds; recoverable accounting or rounding errors; vulnerabilities that require unrealistic or low-probability preconditions to exploit.
4. Low / Informational: Issues with no demonstrable fund impact. Low and informational issues will be regarded as out-of-scope.

Program-specific severity rules

These rules override the classification above where they apply:

• Privileged/admin actions are an accepted trust assumption and are out of scope. Any action that a trusted or privileged role (owner, admin, governance, guardian, keeper, asset manager) is able to perform is considered intended and accepted, including actions that could result in loss or freezing of funds. Reports describing what a privileged role could do, or that require a privileged role to act maliciously or be compromised, are not valid findings. This is a deliberate property of the protocol's trust model, not a vulnerability.
• Loss limited to protocol- or admin-controlled funds is capped at High. Where an unprivileged exploit causes loss that is limited to protocol- or admin-controlled funds (and not user funds), it is classified as High at most and is never Critical.
• Recoverable or reversible impact is never Critical. If funds can be recovered or the impact reversed (via admin intervention, pausing, a timelock, a rescue function, or because a freeze is temporary rather than permanent) the issue is capped at High/Medium. Critical is reserved exclusively for permanent, irreversible loss or freezing of user funds.
• No qualifying impact, no reward. Findings that do not demonstrate one of the in-scope impacts above are out of scope or, at most, informational.

Submission Requirements

• A submission must include a clear textual description of the vulnerability, the affected contract and function, the in-scope impact it produces, and step-by-step reproduction.
• A runnable Proof of Concept is mandatory for all Critical and High submissions. The PoC must be an executable Foundry test that reproduces the exploit against the in-scope commit or a mainnet fork and demonstrates the qualifying impact. Reports that assert an impact without a runnable PoC demonstrating it will be closed as out of scope.
• AI-generated reports without a runnable PoC are not accepted under this program.

Out of Scope Vulnerabilities

The following are explicitly out of scope:

• Theoretical vulnerabilities with no proof or demonstration of a qualifying impact.
• Any finding that does not result in one of the in-scope impacts listed above.
• Any outcome the protocol is designed to produce, even if it results in loss, including bad debt, under-collateralization, or liquidation shortfalls arising from normal market risk, collateral price volatility, or a steep drop in asset price. A report must show a defect in contract logic that diverges from the intended design, not normal operation of the liquidation, interest, or pricing mechanisms.
• Anything a privileged/trusted role (admin, owner, governance, guardian, keeper, asset manager) is able to do (including actions that could result in loss or freezing of funds) as well as centralization risk and governance vectors. All privileged-role behavior is an accepted, intended trust assumption of the protocol.
• Issues already reported in, or covered by, prior audits or prior disclosures.
• Issues requiring unrealistic or external preconditions: a compromised or malfunctioning third-party oracle (e.g. Chainlink), malicious or non-standard tokens not on the supported-asset list, validator/miner collusion beyond simple transaction reordering, or specific unrealistic gas-price conditions.
• Generic mempool front-running with no resulting fund impact.
• Vulnerabilities in imported/third-party contracts and libraries (e.g. OpenZeppelin, Solmate) not modified by Arcadia.
• Incorrect, missing, or misleading event emissions with no fund impact.
• Any finding pertaining adding collateral assets with non-standard ERC20 or ERC721 behaviours (fee-on-transfer, rebasing, ...) as such findings depend on a trusted role (admin, risk manager) adding said tokens as collateral.
• Any finding requiring an Account Owner to delegate asset management actions to a malicious initiator.
• Rounding or ERC-4626-style share issues that net no material loss of funds.
• Old or unlocked compiler version, code-style violations, redundant code, gas optimizations, and best-practice issues.
• Issues in test files, mocks, scripts, or deployment tooling.

Common reported findings which are out of scope:

• Any finding related to malicious asset managers which have been set and thus approved by the Account owner (including high fees causing reverts or configurations that allow the initiator to take more fees than expected)
• Any findings related to the most Senior tranche (if multiple tranches are deployed) to withdraw during ongoing liquidations
• Any findings related to interest accruals during protocol pause, whether fully paused or partially paused.
• Any findings related to the actionTarget state (including balances), as the actionTarget is an untrusted contract.
• Any findings where the flow is not related to Arcadia, such as users intentionally sending tokens to a smart contract, which may be withdrawn by any other user through a public skim-like function.
• It must be explicitly mentioned that any intentionally bad configuration, action or approval by the Account Owner which results in loss of the funds of that Account (Owner) (while not impacting the global accounting, solvency of the protocol, ...), is out of scope. Any user-action that thus results in loss of their own funds is not applicable (this includes withdrawing to a random address, configuring asset manager configurations that cause funds to end up at the asset manager contract, having asset manager configurations where the initiator may take 100% of the fees, approving or setting malicious initiators, ...)

• Avoid using web application scanners for automatic vulnerability searching which generates massive traffic
• Make every effort not to damage or restrict the availability of products, services, or infrastructure
• Avoid compromising any personal data, interruption, or degradation of any service
• Don’t access or modify other user data, localize all tests to your accounts
• Perform testing only within the scope
• Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
• Don’t spam forms or account creation flows using automated scanners
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
• All communication regarding the program must take place exclusively through the HackenProof platform. Contacting the project team directly through support channels, social media, or any other external communication channels is strictly prohibited. Researchers who violate this rule may be disqualified from the program and may face account suspension.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
• No vulnerability disclosure, including partial is allowed for the moment.
• Platform-Only Disclosure: Disclosure is only possible through the HackenProof Disclosure function.
• Researchers may request disclosure (Limited or Full) within the report ticket;
• We reserve the right to approve, redact, or deny disclosure requests at our sole discretion.
• Mutual Required: Any publication requires explicit mutual agreement. Reports must remain Private until the status is officially changed to "Public" on the HackenProof platform by the team.

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability.
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must not be a former or current employee of us or one of its contractor.
• ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded).
• Provide detailed but to-the point reproduction steps.
• AI-generated reports without runable PoC are not accepted under this program.