TON ZK Proofs
Overview
Route TON ZK work without confusing circuit correctness, verifier validity, application authorization, and release evidence.
Operating Rules
- Use
$groth16-systems for general theory and review; this collection adds TON requirements.
- The bundled read-only helpers require Python 3.10+.
- Inspect the repository and installed tools before changing files.
- Treat the documented TON verifier path as BLS12-381; stop on BN254/bn128 until current platform support is independently proven.
- Scope monorepo artifacts to owners. Map a consumed sibling verifier/circuit with
--artifact-package; only an independent non-TON package is non-blocking.
- Prefer Tolk for new work; preserve existing FunC/Tact architecture.
- Keep discovery read-only; do not install, regenerate keys, deploy, commit, or mutate remote state without an explicit request.
- Never hand-edit the cryptographic core of a generated verifier.
- End-to-end work requires all five focused skills; report an unavailable phase as missing.
- A full release also requires the independent evidence in audit-handoff.md; development workflow completion is not an audit pass.
Workflow
- Run the detector; inspect lockfiles, configs, circuits, artifacts, contracts, wrappers, and tests.
- Select stack, proof system, curve, format, target, and maturity from capability-matrix.md.
- Establish general
$groth16-systems evidence, then identify the TON values and encodings that extend it.
- Use
$ton-zk-circuit-workflows; proof, public signals, and VK must verify from one build.
- Use
$ton-zk-verifier-generation; run export-ton-verifier doctor before rendering.
- Use
$ton-zk-contract-integration; separate proof validity, semantics, authorization, domain, replay, and transition.
- Use
$ton-zk-testing, then $ton-zk-integration-review for the TON boundary.
- Keep
TON_INTEGRATION_READY distinct from FULL_ZK_RELEASE_READY; any required NOT_ASSESSED phase blocks the latter, and owner acceptance cannot replace evidence.
- For requested deployment, follow deployment-checklist.md and require a separate mainnet gate.
Quick Reference
| Need |
Skill |
| Circuit/proof/artifact creation |
$ton-zk-circuit-workflows |
.zkey, VK, generated verifier/wrapper |
$ton-zk-verifier-generation |
| Cells, BoCs, messages, nullifiers, policy |
$ton-zk-contract-integration |
| Negative, replay, gas, code-size tests |
$ton-zk-testing |
| TON integration verdict |
$ton-zk-integration-review |
| Full ZK release evidence |
audit handoff |
python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --format json
python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --package packages/ton-app --format json
python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --package packages/ton-app --artifact-package packages/verifier --format json
npm ls export-ton-verifier snarkjs --depth=0
Use project routing, sources/versioning, or the deployment checklist as needed.
Common Mistakes
- Starting contract work before defining the statement and public-input order.
- Assuming a valid proof authorizes the requested TON action.
- Mixing proof, public inputs, and VK from different builds.
- Treating a getter as a state-changing security boundary.
- Calling experimental PLONK production-ready without current capability and test evidence.
- Deploying after a green getter without checking runtime domain, code hash, replay, fees, and receiver.
Completion Gate
Report inventory, dependency specs/resolved versions, capability, local verification, doctor, generated targets, public-input semantics, replay/domain, tests, gas/code size, setup provenance, and risks. For deployment also report network/global_id, address, hashes, transaction, fees, balance, smoke tests, and approval gate.
1---2name: ton-zk-proofs3description: Use when planning or implementing an end-to-end TON zero-knowledge workflow across circuits, Groth16 or experimental PLONK, BLS12-381 artifacts, export-ton-verifier, Tolk/FunC/Tact integration, testing, or deployment.4license: Apache-2.05---67# TON ZK Proofs89## Overview1011Route TON ZK work without confusing circuit correctness, verifier validity, application authorization, and release evidence.1213## Operating Rules1415- Use `$groth16-systems` for general theory and review; this collection adds TON requirements.16- The bundled read-only helpers require Python 3.10+.17- Inspect the repository and installed tools before changing files.18- Treat the documented TON verifier path as BLS12-381; stop on BN254/bn128 until current platform support is independently proven.19- Scope monorepo artifacts to owners. Map a consumed sibling verifier/circuit with `--artifact-package`; only an independent non-TON package is non-blocking.20- Prefer Tolk for new work; preserve existing FunC/Tact architecture.21- Keep discovery read-only; do not install, regenerate keys, deploy, commit, or mutate remote state without an explicit request.22- Never hand-edit the cryptographic core of a generated verifier.23- End-to-end work requires all five focused skills; report an unavailable phase as missing.24- A full release also requires the independent evidence in [audit-handoff.md](references/audit-handoff.md); development workflow completion is not an audit pass.2526## Workflow27281. Run the detector; inspect lockfiles, configs, circuits, artifacts, contracts, wrappers, and tests.292. Select stack, proof system, curve, format, target, and maturity from [capability-matrix.md](references/capability-matrix.md).303. Establish general `$groth16-systems` evidence, then identify the TON values and encodings that extend it.314. Use `$ton-zk-circuit-workflows`; proof, public signals, and VK must verify from one build.325. Use `$ton-zk-verifier-generation`; run `export-ton-verifier doctor` before rendering.336. Use `$ton-zk-contract-integration`; separate proof validity, semantics, authorization, domain, replay, and transition.347. Use `$ton-zk-testing`, then `$ton-zk-integration-review` for the TON boundary.358. Keep `TON_INTEGRATION_READY` distinct from `FULL_ZK_RELEASE_READY`; any required `NOT_ASSESSED` phase blocks the latter, and owner acceptance cannot replace evidence.369. For requested deployment, follow [deployment-checklist.md](references/deployment-checklist.md) and require a separate mainnet gate.3738## Quick Reference3940| Need | Skill |41|---|---|42| Circuit/proof/artifact creation | `$ton-zk-circuit-workflows` |43| `.zkey`, VK, generated verifier/wrapper | `$ton-zk-verifier-generation` |44| Cells, BoCs, messages, nullifiers, policy | `$ton-zk-contract-integration` |45| Negative, replay, gas, code-size tests | `$ton-zk-testing` |46| TON integration verdict | `$ton-zk-integration-review` |47| Full ZK release evidence | [audit handoff](references/audit-handoff.md) |4849```bash50python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --format json51python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --package packages/ton-app --format json52python3 <skills-root>/ton-zk-proofs/scripts/detect_project.py --root . --package packages/ton-app --artifact-package packages/verifier --format json53npm ls export-ton-verifier snarkjs --depth=054```5556Use [project routing](references/project-routing.md), [sources/versioning](references/source-of-truth.md), or the [deployment checklist](references/deployment-checklist.md) as needed.5758## Common Mistakes5960- Starting contract work before defining the statement and public-input order.61- Assuming a valid proof authorizes the requested TON action.62- Mixing proof, public inputs, and VK from different builds.63- Treating a getter as a state-changing security boundary.64- Calling experimental PLONK production-ready without current capability and test evidence.65- Deploying after a green getter without checking runtime domain, code hash, replay, fees, and receiver.6667## Completion Gate6869Report inventory, dependency specs/resolved versions, capability, local verification, `doctor`, generated targets, public-input semantics, replay/domain, tests, gas/code size, setup provenance, and risks. For deployment also report network/global_id, address, hashes, transaction, fees, balance, smoke tests, and approval gate.