Aztec Network

Aztec Network is an open source layer 2 network bringing scalability and privacy to Ethereum. Aztec Network uses zkSNARK proofs to provide privacy and scaling via our zkRollup service.

Further resources regarding Aztec Network can be found in their documentation, https://developers.aztec.network/. A draft of their protocol specification can also be found here, https://hackmd.io/@aztec-network/ByzgNxBfd.

The bug bounty program is focused around its smart contracts and is mostly concerned with the loss of user funds and deanonymization of their ZK-SNARK circuits.

This bug bounty program is further covered by the Armor Alliance Bug Bounty Challenge.

Rewards for Smart Contract vulnerabilities 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.

Rewards for ZK-SNARK Circuits vulnerabilities are distributed according to the CVSS v3.1 Scoring System.

ZK-SNARK Circuits

For vulnerabilities covering ZK-SNARK Circuits, Critical vulnerabilities are those with a CVSS score of 9.0 - 10.0, High are those with a CVSS score of 7.0 - 8.9, Medium are those with a CVSS score of 4.0 - 6.9, and Low are those with a CVSS score of 0.0 - 3.9.

The exploitability of the vulnerability reported will be taken into consideration when determining the final reward. Higher significance will also be attributed for vulnerabilities around the RollupProcessor.sol and TurboVerifier.sol contracts and files within the barrentenberg/src/aztec/rollup/proofs/ folder.

Payouts up to USD 150 000 are handled by the Aztec Network team directly and are denominated in USD. However, payouts are done in DAI. For payouts greater than that, the remainder is paid out in ARMOR by the Armor Alliance Bug Bounty Challenge with a vesting period of up to 24 months.

Prioritized Smart Contract/Blockchain vulnerabilities

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

• Re-entrancy
• Logic errors
  • including user authentication errors
• Solidity/EVM details not considered
  • including integer over-/under-flow
  • 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

Prioritized ZK-SNARK vulnerabilities

• Attacks on “balance soundness” - i.e. being able to spend more funds than one has deposited, e.g. by a double spend reusing the same note somehow.
• Deanonymization attacks - i.e. obtaining information about sender, receiver or amounts sent in a transfer.
• “Faerie gold” attacks - where one manages to send funds to a receiver, who is convinced the funds were indeed received but cannot later spend them.
• Malleability attacks - where a rollup provider or other party can alter the transaction somehow from the sender’s original one.
• Cryptography problems
  • Signature malleability
  • Susceptibility to replay attacks
  • Weak randomness
• Problems with rollup circuit
• Problems with escape hatch circuit

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)
• 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
• Smart contract code that does not conform to standard heuristics but is not exploitable
• An example would be a case of not checking for integer overflow for an addition that cannot overflow, because of prior checks on the input operands.

The following activities are prohibited by 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