Astroport

Astroport is the central space station of the Terra solar system, where travelers from all over the galaxy (Mirrans, Terrans, Anchorians, and more) meet to trustlessly exchange assets. As a galactic public good, Astroport will be governed by the Astral Assembly, a council of cryptonauts representing all corners of the universe.

The design philosophy behind Astroport is simple: to enable decentralised, non-custodial liquidity and price discovery for any asset. To achieve this, Astroport prioritises flexibility above all else; combining various specialised pool types and routing seamlessly across them.

For more information about Astroport, please visit https://astroport.fi/.

This bug bounty program is focused on their smart contracts and is focused on preventing:

• Thefts and freezing of principal of any amount
• Thefts and freezing of unclaimed yield of any amount
• Theft of governance funds
• Governance activity disruption

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System. 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 prefix. 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 suffice 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) 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 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 100 000 for Critical bug reports.

Prior to the official launch of Astroport, this bug bounty program will also have a hard cap of USD 1 500 000. In the event that multiple bug reports are submitted that exceed this amount, the rewards will be provided on a first come, first served basis. All remaining valid reports will have their rewards considered after the launch of the project.

Payouts are handled by the Astroport team directly and are denominated in USD. However, payouts are done in ASTRO or USDC, up to the discretion of the team.

All smart contracts of Astroport can be found at 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

We are especially interested in receiving and rewarding vulnerabilities of the following types:

Smart Contracts and Blockchain

• Re-entrancy
• Logic errors
  • including user authentication errors
• Rust/Terra details not considered
  • including integer over-/under-flow
  • including rounding errors
  • including unhandled exceptions
• Trusting trust/dependency vulnerabilities
  • including composability vulnerabilities
• Oracle failure/manipulation
• Novel governance attacks
• Economic/financial attacks
  • including flash loan attacks
• Congestion and scalability
  • including running out of gas
  • including block stuffing
  • including susceptibility to frontrunning
• Consensus failures
• Cryptography problems
  • Signature malleability
  • Susceptibility to replay attacks
  • Weak randomness
  • Weak encryption
• Susceptibility to block timestamp manipulation
• Missing access controls / unprotected internal or debugging interfaces

Out of Scope & Rules

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves, leading to damage
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist)

Smart Contracts and Blockchain

• Incorrect data supplied by third party oracles
  • Not to exclude oracle manipulation/flash loan attacks
• Basic economic governance attacks (e.g. 51% attack)
• Lack of liquidity
• Best practice critiques
• Sybil attacks

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• Any testing with pricing oracles or third party smart contracts
• Attempting phishing or other social engineering attacks against our 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
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty