ADI Foundation zkVM Verification: Program info

IN SCOPE VULNERABILITIES

We are looking for evidence of attack that causes invalid proofs or state transitions to be accepted by either native or on-chain verification, including:

• Affirmative verification of an invalid/forged proof (false accept) by the Rust verifier or on-chain verifier
• Public input / instance mis-binding (e.g., wrong state root, block number, chain ID, or message commitments verified as if correct)
• Transcript / Fiat–Shamir malleability leading to proof reuse or altered challenges being accepted
• Polynomial-commitment / FRI / MSM / subgroup errors that allow constructing a proof passing verification with incorrect witness
• Aggregation bugs (batched or recursive proofs) that let invalid subproofs pass overall verification
• Verifier interface misuse (ABI / calldata packing, memory layout, or endianness errors) that accept malformed proofs

Please use the following tags for the source code:

• ADI-Sack-Airbender-Prover: v0.5.1-b
• ADI-Sack-Airbender-System: v0.5.1-b
• ADI-Stack-Contracts: zkos-v0.29.11
• ADI-Stack-Protocol: commit 767759541cd018e4271f9774f0d760ce727c905d

Reports from any other source code version would be rejected.

OUT OF SCOPE VULNERABILITIES

• Theoretical vulnerabilities without any proof or demonstration
• Sub-circuit-only vulnerabilities that cannot be recreated/leveraged for the full circuit statement (per your request)
• Issues that require modifying the verifier/guest/circuit to exploit
• Documentation/test/demo issues
• Best-practice critiques, gas optimizations, rounding, or purely economic considerations without proof-soundness impact
• Attacks that rely on social engineering
• Attacks that rely on leaked toxic wastes during key generation
• Public Zero-day vulnerabilities
• Wrong proof acceptance not related to the proof verification procedure (it's a part of another bounty program), e.g.:
  • Bypassing verification by calling finalization/bridge/rollup functions that don’t invoke the verifier
  • Access-control/upgrade/config bugs that let an admin or external contract finalize state without going through the verifier
  • Return-value misuse (verifier result ignored/mis-checked) or calldata routing bugs in contracts outside the verifier that lead to acceptance of a wrong state
  • Any logic in L1/L2 contracts that lives outside the dedicated verifier functions (bridge, message passing, governance, pausing, fee/accounting, etc.).
• 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., ZKsync) 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.

• 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
• Broken link hijacking is out of 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

• 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