ADI Foundation Smart Contracts: Program info

IN SCOPE VULNERABILITIES

We are looking for evidence and reasons for incorrect behavior of the smart contract, which could cause unintended functionality. Examples include (but aren’t limited to):

• Theft or permanent loss of funds (direct or via fee/interest/accounting bugs)
• Unauthorized actions: bypassing access control
• Transaction ordering assumptions where state can be corrupted or assets stolen when calls are reordered by an adversary (not simple MEV PnL; must break invariants)
• Attacks on logic (behavior of the code is different from the business description)
• Upgradeable proxy misconfig (wrong impl slot, delegatecall hazards, unsafe UUPS/Beacon usage)
• Admin/key/guardian logic that allows unintended upgrades, self-destructs, or parameter changes that bypass intended checks
• Finalization or message processing without a valid verifier result due to miswiring (e.g., contract never calls the verifier, ignores boolean return, or binds wrong inputs around the call)
• Reentrancy
• Over and underflows
• Balance manipulation
• Contracts execution flows

Use only the zkos-v0.30.2 tag (commit 9ddc915c85d1f44c79b5d55e160d384138ed5105) of the source code. This is the version currently deployed on ADI mainnet. Reports against any other version will be rejected.

Reports submitted before 05-10-2026 against zkos-v0.29.11 will still be reviewed against that version.

Deployed contracts: Ethereum mainnet (L1)

If your PoC uses a fork, use only these L1 addresses. Do not take addresses from other sources.

OUT OF SCOPE VULNERABILITIES

• Theoretical vulnerabilities without any proof or demonstration
• Compiler concerns: “old version” or “pragma not pinned” without an exploit
• Vulnerabilities in imported contracts
• Style, redundancy, best practices, gas/packing optimizations
• Best practice issues
• Front-run/MEV-only profit scenarios that do not break invariants or cause loss/theft
• Attacks that rely on social engineering
• zkProof verification algorithm (it's a part of another bounty program)
• Public Zero-day vulnerabilities
• Vendor-specific or third-party modules not maintained by ADI Foundation, including but not limited to Matter Labs libraries or any components delivered by external vendors that are:
  • Not part of the officially tagged source code repositories specified in scope
  • Not under ADI Foundation’s direct maintenance or review process
• Reason: The program only intends to cover code under direct project control; vulnerabilities in third-party vendor libraries should be raised with the respective vendor bounty program or governance.
Example: the zkProof verification algorithm is out of scope because it belongs to another bounty program.
• Imported contracts or dependencies not written by the core ADI team unless:
  • They are modified and part of the deployed on-chain ABI targeted in scope
  • They are explicitly mentioned in our in-scope targets
• Vulnerabilities that are shared with vendor-maintained code (e.g., Matter Labs) and were already fixed in the vendor’s public codebase prior to report submission are out of scope, regardless of whether the fix had been deployed to ADI Foundation contracts at that time.

Deprecated deployments (out of scope)

These addresses are not part of the current deployment. Findings based only on them are out of scope.

General Conduct

• 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
• Testing on mainnet or public testnet deployments is strictly prohibited. All testing must be done on a local environment or a local fork.
• Do not test against third-party contracts, oracles, bridges, or infrastructure that are not listed in scope.
  • Reports that test an Ethereum mainnet (L1) deployment other than those listed under "Deployed contracts", including the deprecated addresses, will be closed as Out of scope.

AI-Generated and Automated Reports

• AI-generated reports will be ignored straight away. Only manually written reports are accepted.
• This applies to any report where the description, root-cause analysis, impact analysis, or PoC was produced by AI tools (e.g. ChatGPT, Claude, Gemini, Copilot), AI auditing agents, or automated scanners and static analysers (e.g. Slither, Mythril, Aderyn) and submitted without the researcher independently verifying and reproducing it.
• Raw or lightly edited output from any automated tool is not accepted as a report.
• You are fully responsible for every statement in your report. You must personally understand the issue, reproduce it yourself, and write the report in your own words.
• Reports showing signs of AI generation will be closed without review. Signs include: references to functions, files, variables, or line numbers that do not exist in the in-scope code; generic impact statements not tied to our code; attack paths that cannot be executed; PoCs that do not compile or run; and boilerplate recommendations.
• The decision of the program team on whether a report is AI-generated is final.
• Researchers who repeatedly submit AI-generated, automated, or low-quality reports will be removed from the program and reported to HackenProof for further action on their account.

Proof of Concept (PoC) Requirements

• Reports without a Proof of Concept (PoC) and a video will not be accepted.
• The PoC must be working code. Written explanations, pseudocode, diagrams, or theoretical scenarios are not accepted as a PoC.
• The PoC must be runnable end-to-end (e.g. a Foundry or Hardhat test for smart contracts, or a Rust test for prover/verifier issues) against the exact in-scope version listed in this program.
• The PoC must include: exact commands to run it, tool and dependency versions, fork block number (if a fork is used), expected result vs actual result, and output proving the impact (e.g. balances before and after, broken invariant, accepted invalid proof).
• The PoC must demonstrate real impact on an in-scope asset. PoCs that modify in-scope code, mock core components, or rely on privileged roles acting maliciously are not accepted, unless the vulnerability itself is gaining that privilege.
• If the program team cannot reproduce the issue using the PoC provided, the report will be closed.

Video Requirements

• Every report must include a video recording of the PoC being executed from start to finish.
• The video must clearly show: the in-scope repository and commit/tag being tested, the command(s) being run, the full terminal output, and the final result proving the impact.
• The video must be a continuous, unedited screen recording. Screenshots, slideshows, edited or AI-generated videos are not accepted.
• The video must be attached to the report on HackenProof or shared through a private link accessible only to the program team. Uploading the video publicly counts as public disclosure and will lead to disqualification.
• A video does not replace the PoC. Both are required.

Report Quality

• Submit one vulnerability per report. Related issues with the same root cause must be submitted in a single report.
• Each report must include: a clear title, affected contract/file/function with line numbers at the in-scope commit, root cause, step-by-step attack scenario, impact, severity justification, PoC, video, and recommended fix.
• Placeholder reports (vague title, very few details, no reproducible steps) will be closed without review.
• Reports against any code version other than the in-scope version will be rejected.

Violations

• Breaking any of these rules may result in the report being closed without reward, forfeiture of any bounty, removal from the program, and referral to HackenProof for 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.
• Please do NOT publish/discuss bugs

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