All smart contracts of Olympus can be found at [https://github.com/OlympusDAO/olympus-contracts](https://github.com/OlympusDAO/olympus-contracts). However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

__Impacts in Scope__

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

__Smart Contracts/Blockchain__

  - Loss of treasury funds
  - Loss of user funds
  - Loss of bond funds

__Web/App__

  - Loss of treasury funds
  - Loss of user funds
  - Loss of bond funds

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System](https://immunefi.com/severity-updated/). This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

All bug reports must come with a PoC in order to be considered for a reward. Smart contract bug reports must have the PoC be fully runnable.

Critical vulnerabilities are further subcategorized into two tiers:

  - Tier 1: For bugs/exploits which would lead to a loss of bond funds or a loss of user funds, a flat reward of __USD 333 333__ is provided.
  - Tier 2: For bugs/exploits which would lead to a loss of treasury funds, a flat reward of __USD 3 333 333__ is provided. 

For vulnerabilities of websites and applications, only bugs that lead to direct financial damage listed in the Impacts in Scope are accepted and are categorized as critical. All others are not accepted. An example of an acceptable vulnerability in this category would be [https://rekt.news/badger-rekt/](https://rekt.news/badger-rekt/).

Bugs that have been previously disclosed, either publicly or in an earlier bug submission, are ineligible for a reward.

Payouts are handled by the __Olympus DAO__ directly and are denominated in USD, under the terms set out in OIP-38. However, payouts are done in __USDC__.

All smart contracts of Astroport can be found at [https://github.com/astroport-fi/](https://github.com/astroport-fi/). However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

__Impacts in Scope__

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in the scope table.

__Smart Contracts/Blockchain__

  - Loss of user funds staked (principal) by freezing or theft
  - Loss of governance funds
  - Theft of unclaimed yield
  - Freezing of unclaimed yield
  - Temporary freezing of funds for at least 1 hour
  - Unable to call smart contract
  - Smart contract gas drainage
  - Smart contract fails to deliver promised returns
  - Vote manipulation
  - Incorrect polling actions

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System](https://immunefi.com/severity-updated/). This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

All smart contract bug reports must come with a PoC and a suggestion for a fix in order to be considered for a reward.

The following known issues are considered to be out of scope: 

1. Collection of ASTRO tokens in maker contract is not possible if there are no tokens to be swapped.
The condition in contracts/tokenomics/maker/src/contract.rs:129 implies that if there are no assets to be swapped, the reply will be skipped. This implies that a positive ASTRO balance in the maker cannot be collected.

2. Attackers can cause the generator’s send orphan proxy rewards function to run out of gas, locking orphan rewards in the contract.
In the send_orphan_proxy_rewards function in contracts/tokenomics/generator/src/contract.rs:721, the USER_INFO storage map is iterated over with the LP token preﬁx. That iteration is unbounded. An attacker can deposit many small amounts to make the iteration long enough for the send_orphan_proxy_rewards function to run out of gas. There is currently no way to recover from such an attack, any orphan rewards would be locked forever in the contract.

  The query_orphan_proxy_rewards query handler exhibits the same issue in     line 880, which could potentially cause calling contracts to run out of     gas.

3. Lack of tax deduction may lead to failure of maker contract’s swap to ASTRO function.
In contracts/tokenomics/maker/src/contract.rs:203, no taxes are deducted before sending native assets to the pair contract in order to swap them for ASTRO tokens. This implies that the maker's native token balance will be used to pay taxes, until eventually the balance will not suﬃce and the message will revert.

4. Generator proxy template assumes that unbonded amount is fully available for transfer.
In the generator proxy template, the reference implementation suggests that the unbonded amount is fully available for transfer in line templates/generator_proxy_template/src/contract.rs:130 and 157. In practice, some protocols apply withdrawal fees, taxes, or might subject bonded funds to slashing. In either case, the received balance might be less than what was unbonded, and the withdrawal would fail.

5. Incorrect slippage in stable pool. 
The calculation for slippage is incorrect in stable pool.

6. Incorrect formula for LP token minting amount in stable pool.
We use the same formula for calculating/minting LP tokens in stable pool as in xyk. This is not valid.
The current formula ([https://github.com/astroport-fi/astroport/blob/2b73e3e436a4f280cb3474b344fb4f9eece5b580/contracts/pair_stable/src/contract.rs#L298](https://github.com/astroport-fi/astroport/blob/2b73e3e436a4f280cb3474b344fb4f9eece5b580/contracts/pair_stable/src/contract.rs#L298)) implies that he will receive only 100 LP tokens, which doesn't seem correct as the ratio between tokens in stable pool is not 1:10, but ~1:1;
We need to use d for calculating the price for the whole pool, which is compared to d after liquidity is provided. The amount of LP tokens to mint should be based on this difference.

7. Run mass_update_pools before updating tokens_per_block.
In generator contract if admin updates tokens_per_block (e.g. set to 0) after a pool is created all rewards will change accordingly, so all users who don’t withdraw their liquidity are affected (so it kinda works backwards). We will add mass_update_pools before that operation so it does not work backwards and only affects the next blocks.

8. Unbounded iteration over pools could lead to out of gas issues.
In contracts/tokenomics/generator/src/contract.rs:256 and 349, unbounded iteration over POOL_INFO entries are performed. That implies that the gas consumption increases with the number of pools, which could eventually lead to transactions that hit gas limits. We classify this issue as minor since only the owner can add pools to POOL_INFO.

9. Possibility to create multiple pools with the same pair. Creating pools with the same pair generates unexpected situations, e.g. a user could withdraw more tokens than his fair share and affect other users in the pool.

10. Privileged addresses can be transferred without confirmation in the factory contract.

11. Miscalculation in the stableswap D invariant, leading to an incorrect denominator.

12. Incorrect stableswap slippage calculation. The slippage calculation will be removed from stableswap contracts.

Critical vulnerabilities are further capped at 15% of economic damage, with the main consideration being the funds affected in addition to PR and brand considerations, at the discretion of the team. However, there is a minimum of __USD 100 000__ for Critical bug reports. 

Payouts are handled by the __Astroport__ team directly and are denominated in USD. However, payouts are done in __ASTRO__. All rewards above 1 000 000 USD are subjected to a unlock period of up to 18 months where tokens will be vested linearly on a monthly basis.   If a bug is found within seven days of Astroport’s launch, the price of ASTRO will be calculated as the Time-Weighted Average Price (TWAP) price in UST since launch. If a bug is found 1 week to 30 days after launch, the price of ASTRO will be the TWAP price in UST over the previous 7 days. If a bug is found 30 days+ after launch, the ASTRO price will be the TWAP price in UST over the previous 30 days.


All smart contracts of Optimism can be found at [https://github.com/ethereum-optimism/optimism](https://github.com/ethereum-optimism/optimism).  However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System](https://immunefi.com/severity-updated). This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

All smart contract bug reports must come with a PoC in order to be considered for a reward.

Any freezing of funds that is recoverable via an upgrade would be considered as High severity.

Critical vulnerabilities are further capped at 10% of economic damage, with the main consideration being the funds affected in addition to PR and brand considerations, at the discretion of the team. 

However, there is a minimum of __USD 75 000__ for Critical bug reports.

Note: that there appears to be an obvious bug which would allow an attacker to withdraw a fake ERC20 token from L2 in exchange for a real ERC20 (such as WBTC) token on L1. There is no check in the L2StandardBridge, however the withdrawal is prevented from finalizing by a check in the L1StandardBridge. Naturally if you do find a way to circumvent our protections, then we would reward you. 

For testing any exploits involving cross-domain transactions, we recommend working with our [dockerized services](https://github.com/ethereum-optimism/optimism/blob/6f8e432506a5f4ba094f091b22a0bb6acc53fdac/ops/README.md) and modifying our [integration tests](https://github.com/ethereum-optimism/optimism/blob/6f8e432506a5f4ba094f091b22a0bb6acc53fdac/integration-tests/test/bridged-tokens.spec.ts)

The following known issues are considered to be out of scope of this bug bounty program:
  - The fact that their contracts are upgradable via a multisig. 
  - The fact that fault proofs (FKA fraud proofs) are not yet running.
  - A bug in Lib_MerkleTrie.sol which will prevent withdrawals from succeeding in some cases. There is a workaround for this, by modifying the proof to add an extra element.
  - A bug in Lib_ResolvedDelegateProxy.sol which could result in a storage slot key collision overwriting the address of the implementation. This bug is dependent on the layout of the implementation contract, and Optimism is not affected.
  - The user cannot commit to a L1 gas price, the OVM_GasPriceOracle is owned by a key controlled by Optimism and is responsible for setting the L1 gas price.

Payouts are handled by the __Optimism__ team directly and are denominated in USD. All payouts are done in __USDC__.

All smart contracts of Celer Network can be found at [https://github.com/celer-network/sgn-v2-contracts](https://github.com/celer-network/sgn-v2-contracts). However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program. For cBridge contracts (multiple instances on different chains), there will not be duplicated counting of bugs. One bug that exists in all contracts will be counted as a single bug. 

__Impacts in Scope__

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

__Smart Contracts/Blockchain__

  - Thefts and permanent freezing of any funds in liquidity pool smart contract or staking contracts
  - Thefts and permanent freezing of unclaimed yield rewards

__Web/App__

The only web vulnerabilities in scope are those which lead directly and unequivocally to loss of user funds, a direct breach of data, and the deletion of site data

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System](https://immunefi.com/severity-updated/). This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit. 

There are some modifications from the above Severity Classification for this bug bounty program:

Critical Level Security - Modified: 
  - Empty or permanent freeze the contract's holdings (e.g. economic attacks, flash loans, reentrancy, MEV, logic errors, integer over-/under-flow)

Medium Level Security - Excluded: 
  - Griefing denial of service (i.e. attacker spends as much in gas as damage to the contract)
  - Gas griefing

All web/app bug reports must come with a PoC in order to be considered for a reward. All High and Critical Smart Contract bug reports require a PoC and a suggestion for a fix to be eligible for a reward. 
Critical Smart Contract and Blockchain bug reports are further capped at 10% of economic damage up to USD 2,000,000, which primarily takes into consideration the funds at risk but may include branding and PR aspects at the discretion of the team. However, they have a minimum reward of USD 150,000. 

The following vulnerabilities are not eligible for a reward:

  - Previously known vulnerabilities (resolved or not) on the Ethereum network (and any other fork of these).
  - Previously known vulnerabilities in Tendermint and or/any other fork of these.
  - Previously known vulnerabilities in cosmos-sdk and or/any other fork of these.
  - Previously known vulnerable libraries without a working Proof of Concept.
  - Attacks requiring MITM or physical access to a user's device.
  - Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis
  - Any griefing attacks on the system or smart contract trying to spend gas costs or liquidity lockup to incur gas costs and computational overhead  for the validators and operators of the network.
  - Liquidity value reduction or arbitraging incurred due to the pricing mechanisms of the system and LP’s own operations. 
  - Attacks involving getting access to privileged admin keys 
  - Delay of cross-chain transfer (fund security not compromised) due to network/rpc error from the blockchain endpoint being used by SGN validators
  - Security issues related to connected blockchains of cBridge is not in the scope
  - As to the current implementation, it is possible (with low probability) that a user triggered transaction (e.g., add liquidity, send fund, delegate stake) is not automatically synced to the sgn, or the sgn failed to automatically submit the fund relay transaction to the destination chain (e.g., due to chain rpc endpoint failure). Such cases do not introduce fund security, and can be recovered through manual CLI tools. Related improvements will be included in later releases.

Celer Network requires KYC to be done for all bug bounty hunters submitting a report and wanting a reward. The information needed is acquired through mutually agreed third-party KYC solutions. The collection of this information will be done by the Celer Network team.

Payouts are handled by the __Celer Network__ team directly and are denominated in USD. However, payouts are done in __ETH__, __CELR__, __or a stablecoin__, with the choice of the ratio at the discretion of the team.


Web3's leading bug bounty platform, protecting $100 billion in user funds

For Hackers

For Projects