Open proof engine
Proof-critical execution and public contracts are MIT licensed and reviewable. Guard does not modify the proof semantics of the released engine.
Security boundary
Proof data stays out of TinyZKP infrastructure.
Guard is designed to run on customer-owned Linux compute. TinyZKP does not receive workloads, witnesses, checkpoints, scratch files, or proofs.
Never submit sensitive proof material. GitHub reports, issues, diagnostics, and merchant support must not contain witnesses, inputs, checkpoints, scratch files, proofs, environment variables, tokens, or license keys.
Trust boundary
Customer-controlled data
Workload files and scratch remain under customer-selected roots. Paths, symlinks, devices, release identity, and integrity are validated before use.
One-time activation
Activation sends limited license and release metadata to the merchant. Once activated, proving, resume, verification, and license status are local and offline.
Release integrity
Each qualified release publishes immutable hashes, an OCI digest, SBOM, provenance, signed channel manifest, schema identities, compatibility profile, source identity, and review evidence. Verify the exact release before use. Do not install an artifact whose identity is missing or inconsistent.
Scratch safety
- Use dedicated local NVMe with restrictive owner permissions.
- Assume scratch may contain sensitive intermediate data.
- Do not use shared or untrusted network filesystems.
- Preserve scratch only as long as required for resume, then delete it according to your own retention policy.
- Disk encryption, host hardening, access control, backup policy, and secure deletion remain customer responsibilities.
Security claims TinyZKP does not make
TinyZKP does not claim that every supported workload is zero knowledge, that SSD scratch is inherently private, that Guard provides a trusted execution environment, that the system supports arbitrary Plonky3 configurations, or that a release is independently reviewed before its evidence is published.
Vulnerability reporting
Use the repository's private vulnerability report for security-sensitive findings. Use a public issue only when the report contains no exploit detail or sensitive material. The project does not promise an SLA or guaranteed response time.