Security policy

Use this page to report a suspected vulnerability, to check whether a surface is in scope and to understand what help the maintainer can offer. The repository's SECURITY.md (opens in a new tab) is the controlling policy.

Report a vulnerability#

Report suspected vulnerabilities privately through either channel:

• Email [email protected].
• Use GitHub private vulnerability reporting on the Security tab of the source repository (opens in a new tab).

Include:

• the affected revision;
• your environment;
• the steps to reproduce;
• the expected and the observed behavior;
• the potential impact.

Arrange a protected transfer before you send sensitive supporting material. Do not include credentials, private keys, personal information or private infrastructure locations. Do not test systems or accounts that you do not own or lack explicit permission to assess.

What happens after you report#

The maintainer reviews each report, coordinates the fix and its disclosure with you and may restrict details while the fix is prepared. Meaningful contributions are credited through Git history, release notes or an advisory as appropriate.

Scope#

Security-sensitive surfaces include:

• sparse-Merkle semantics and circuit compilation;
• sumcheck, GKR verification, transcript binding and circuit commitment;
• proof encoding and the fixed zkVM program identity;
• canonical vector and receipt encodings;
• prepared material and deterministic artifact identity;
• resource exhaustion, side channels and dependency integrity;
• external proof and destination integrations where the repository directly owns the code.

For what the component checks and assumes, see Trust boundaries.

If a tampered proof is accepted#

Stop and open a private report through one of the channels above. Include the exact revision and a minimal local reproduction. A proof that verifies after you change its bytes, path, root, asset identifier or operation is a suspected vulnerability, not an ordinary defect.

Support#

For a production deployment, contact Oraclizer Labs through StateSync-GKR licensing.

Public issues#

Use public issues (opens in a new tab) for reproducible defects, documentation errors and focused design proposals. Include the exact revision, operating system, tool versions, commands, expected behavior, observed behavior and a minimal reproduction.

What the maintainer can help with#

Maintainer responses may cover the repository source, the documented build and test commands, public vectors, formal sessions, the release verifier and claim boundaries.

Questions about deployment operation, key management or service levels belong to a commercial engagement.

What to expect#

Issues are triaged in batches, and reproducible defects and concrete documentation errors are handled first. If a thread has gone quiet, a comment on it is welcome and is the fastest way to get it picked back up. Broad questions and large proposals can take longer, or may be answered with a pointer to the relevant boundary document. None of this is a service-level commitment.

Conduct concerns#

Report code-of-conduct concerns through the same private email channel. Do not include unrelated personal data.