Paxos Labs

These rules add to Immunefi's default out-of-scope list. Where a rule below differs from a default item, the rule below applies to this program. Each rule is judged against the program and the deployed system as they stood when the report was submitted.

• In-scope contracts are the contracts deployed at the addresses listed in the Assets in Scope table. For a listed proxy, the implementation it points to when the report is submitted is also in scope.
• A proof of concept must reproduce the impact against the in-scope contracts, in a local or forked environment, including every condition the scenario needs. A condition does not have to exist on mainnet today if the proof of concept reproduces it, for example by forking a specific block or simulating a feed state, as long as the deployed system can reach that state. A report is theoretical, and out of scope, when it only asserts an impact or relies on a condition its proof of concept does not reproduce.

1. Admin or privileged-role configuration

Impacts that depend on a value set by an admin or other privileged role are out of scope when that value is possible but is not set in the deployed system. Such values include roles and permissions, Merkle roots, fees and fee modules, rate limits, exchange rate bounds, supported assets, cross-chain peers and gas settings.

This exclusion does not apply when:

• the value is set in the deployed system and the report demonstrates an impact; the report is then assessed under the normal scope and impact rules;
• an unprivileged actor can set or change the value, directly or through a vulnerability in the in-scope contracts; or
• a privileged function, called with a value the deployed system is designed to accept, causes an impact listed in Impacts in Scope because of a logic error.

2. Third-party services and infrastructure

Impacts caused solely by a third-party service or infrastructure that Paxos Labs does not control are out of scope, such as messaging networks and bridges, and compliance or screening providers. This covers their bugs, downtime, censorship, misconfiguration, and delayed or failed delivery. A vulnerability in the in-scope contracts remains in scope, including in how they handle a third-party failure.

This applies even when the third-party failure puts funds held by the in-scope contracts at risk, and whether or not Paxos Labs was already aware of the failure. A vulnerability in the protocol's own contracts, including in how they integrate with or rely on a third-party component, remains in scope.

3. Oracle and market manipulation

For this program, Immunefi's default exception for oracle manipulation and flash loan attacks is narrowed. Impacts that depend on manipulating the price or liquidity of an external market or oracle, including through flash loans, are out of scope unless the report includes a proof of concept that:

• runs against the in-scope contracts on a fork of mainnet;
• manipulates a market or oracle that the in-scope contracts read at the time of submission; and
• uses only liquidity that is available at the time of submission or expected within the next 12 months, as set out in Immunefi's Attack Investment Amount standard.

Hypothetical or assumed market conditions are not considered. An attack that is not profitable for the attacker is assessed under Immunefi's griefing standard.

4. Non-standard token behaviour

Impacts that depend on non-standard token behaviour are out of scope when the token is not enabled as a supported asset in the deployed system. Such behaviour includes fee-on-transfer, rebasing, ERC-777 or other callback tokens, unusual decimals, and the ability to blacklist, freeze or pause balances. For a supported asset, its behaviour as deployed is in scope. Enabling a new token is an admin action, so rule 1 also applies.

5. Positions and assets held in external protocols or markets

Losses arising from positions or assets that the in-scope contracts hold in external protocols or markets are out of scope. This includes hacks of those protocols, bad debt, slashing, liquidations, and price movement or depegging of any asset. A loss caused by a vulnerability in the in-scope contracts' own logic for integrating with or handling those positions remains in scope. Financial risk management decisions, such as which external positions to hold and their limits, are not in scope.

6. Code not deployed or not in production

Only the in-scope contracts are in scope. Other code in the repository is out of scope, including undeployed or deprecated contracts, scripts, tests and mocks. Undeployed code is in scope only when Paxos Labs has publicly stated that it will be deployed without further changes as an upgrade of an in-scope contract, as set out in Immunefi's standard for undeployed code.

7. Rounding and precision loss

Rounding errors and precision loss are out of scope unless the proof of concept demonstrates a loss to the protocol or its users of at least USD 100,000. The threshold can be met by repeating the operation or scaling the amounts, as long as the proof of concept runs the full sequence within the deployed system's current limits, such as rate limits and caps.

8. Chain-level and network-level events

Impacts that require a chain-level or network-level event outside Paxos Labs' control are out of scope. Such events include a sequencer or validator outage, censorship, network congestion, and a reorganization of blocks that the in-scope contracts or their messaging configuration already treat as final. This includes impacts that depend on a missing sequencer uptime check. Impacts on chains where the protocol is not deployed, including EVM differences, are also out of scope. How the in-scope contracts handle expected behaviour on the chains where they are deployed, such as a reorganization within the confirmation window they are configured to wait for, remains in scope.

9. User error

Impacts caused by a user's own error are out of scope, such as sending funds to an incorrect recipient or destination address, using a smart contract wallet the user does not control on the destination chain, sending tokens directly to a contract outside its intended flows, or setting slippage or minimum-output parameters that do not protect the user. A vulnerability that makes the in-scope contracts ignore or miscalculate a parameter the user supplied remains in scope.