ContractGraph-QA is intended for defensive smart-contract quality assurance and security testing.

Use the project only on:

• contracts you own;
• open-source contracts used as local test fixtures;
• systems for which you have explicit authorization;
• public bug-bounty programs strictly within their published scope and rules.

Do not use this repository to target third-party production systems without permission. A public contract address or publicly readable chain state is not, by itself, authorization to perform active security testing.

Fork-based testing must use a fixed snapshot and explicit scope evidence. The Authorized fork smoke workflow requires a scope identifier, authorization reference, exact chain/block/target, an affirmative authorization confirmation, and a secret RPC endpoint before opening the fork.

The v0.6 smoke test is read-only: it does not call target functions or broadcast transactions. Client-specific active fork scenarios must remain within the written authorization or published bounty scope.

Never commit RPC credentials, private keys, seed phrases, signing material, or client secrets. Authorization references supplied as workflow inputs should be non-sensitive because workflow metadata and logs may be visible to repository collaborators or the public.

The v1 product runtime invokes Foundry with an argument array rather than a shell command string. Product config capture identifiers are restricted to safe identifier characters, and manifest/result/finding/report/bundle paths must be distinct.

The evidence ZIP is an integrity/provenance container, not encryption. It can contain target identifiers, authorization references, state descriptions, findings, and client-facing impact text. Treat the bundle and Markdown report according to the engagement's confidentiality requirements.

cgqa verify-bundle validates hashes and the semantic manifest → result → finding → report chain. It does not establish who originally authored or transmitted the bundle. Use an authenticated client-delivery channel when authenticity matters.

Do not place secrets in adapter manifests, explorer results, finding text, report notes, or product config files that may be committed or shared.

Please open a GitHub issue for non-sensitive defects.

For a sensitive vulnerability, use GitHub private vulnerability reporting from this repository's Security tab (Report a vulnerability) when that option is available. Do not open a public issue containing exploit details, private keys, secrets, or reproduction steps that could put users at risk.

If private vulnerability reporting is unavailable, open a non-sensitive issue asking the maintainer to provide a private contact channel, without including vulnerability details. Give the maintainer a reasonable opportunity to assess and fix the issue before public disclosure.

Files explicitly named Vulnerable* are intentionally insecure local fixtures. They exist to demonstrate invariant detection and must not be deployed.