01
Facts enter
Credentials, limits, and transfer facts become structured inputs.
// proof-backed compliance enforcement
FOR INSTITUTIONAL RWA PLATFORMS
The backend can say approved. Your contract shouldn't have to trust it.
ZKCG proves that a defined policy was correctly applied to a specific transfer, onboarding decision, or payout release before execution. The verifier checks the proof — not an operator's claim.
PUBLIC PROOF SURFACE
Circuits + verifier logic
MULTIPLE PROVING PATHS
Halo2 + RISC0 zkVM
PUBLISHED TOOLING
Rust crates + security test primitives
SECURITY TESTING
Concrete findings surfaced and fixed
// architecture
A decision becomes a proof before it becomes an action.
Facts enter. Policy resolves. The outcome is committed, proven, and handed to execution as a verifiable artifact — not a trusted result.
02
Policy resolves
A versioned policy evaluates the defined inputs deterministically.
03
Decision commits
The outcome and reason bits are bound into a decision commitment.
04
Proof is generated
A cryptographic witness binds the computation to the committed result.
05
Execution verifies
The receiving system verifies before it acts on the decision.
// proof of rigor
Correctness is part of the product.
ZKCG is built for buyers who need to interrogate the verification boundary — not just read a feature list.
Public proof surface
Public proof programs cover shipped score checks and RWA onboarding and transfer evaluations, with public verifier, replay, state-binding, and attestation-binding logic.
Inspect the public verifier →Two proving paths
The public system exposes both a Halo2 backend and a RISC0 zkVM path for the shipped proof claims, giving teams two independently implemented proving routes to inspect.
Security findings are part of the record
Security testing surfaced a circuit constraint gap affecting policy-violating proofs and a proof-parser boundary issue where trailing bytes were accepted. Both were fixed and the testing methodology is public.
Published tooling
ZKCG publishes verifier/prover crates and reusable security-testing primitives, so the verification layer is inspectable outside the hosted product.
FORMAL AUDIT STATUS
No independent third-party audit yet.
That boundary is explicit. The public repository is the source of truth for what is currently proven, what is tested, and what remains outside the proof scope.
// ecosystem security work
ZKCG was used as the reference implementation in a Zcash Community Grants proposal for reusable Halo2 verifier security testing.
Read the proposal and testing scope →
// the difference
Trust versus proof. These are not the same thing.
A compliance platform can tell a contract that a wallet is eligible. ZKCG makes the computation itself part of what the verifier checks.
WITHOUT PROOF-BACKED ENFORCEMENT
// backend says eligible // contract trusts the result // policy logic stays outside the verifier if (backend.saysApproved(wallet)) { execute(); }
WITH ZKCG
// ZKCG commits the decision // proof binds the policy evaluation // verifier checks before execution if (verifier.verify(proof, inputs)) { execute(); }
// institutional workflows
Put the proof where the decision carries financial risk.
RWA transfer gating
Prove that defined investor eligibility and transfer restrictions were applied before an asset transfer executes.
Payout release control
Gate frozen payroll or treasury batches with proof-backed checks over manifests, caps, and recipient screening snapshots.
Credential stacks
Keep credentials upstream while ZKCG proves the application-specific rule was enforced before the action crossed the execution boundary.
// engagement model
Start with the workflow, not a checkout page.
For institutional buyers, the first step is a concrete evaluation of your decision boundary. Commercial terms follow the workflow, deployment surface, and security requirements.
Evaluate
Run a representative eligible and blocked case and inspect the proof surface.
Scope
Map the policy inputs, verifier boundary, execution path, and operational requirements.
Integrate
Move the selected workflow into a production deployment with the appropriate controls.
// workflow intake
Tell us what decision needs to become verifiable.
This is the only form on the site. Give us the real workflow, the inputs it depends on, and what executes after approval.
1
Describe the decision
What facts enter? What rule decides? What action follows?
2
We map the trust boundary
We identify what should be proven, what remains an input, and where verification sits.
3
Run the representative proof
We validate eligible and blocked paths before discussing production rollout.
// common questions
Questions technical and compliance teams ask early.
What exactly does the proof guarantee?
For the published proof programs, the proof binds deterministic policy evaluation over the specified normalized inputs to the reported decision. It does not make an upstream KYC, AML, identity, or accreditation source truthful by itself.
Which proof systems are supported?
The public verification layer supports Halo2 and a RISC0 zkVM path. The current repository documents which proof programs and verifier paths are public today.
What security work is public?
The public security-testing work includes adversarial and malformed-proof testing, replay/binding checks, differential-verification primitives, and published test artifacts. The evaluation also surfaced and fixed concrete circuit and proof-parser issues.
Has ZKCG had an independent third-party audit?
Not yet. That is an explicit boundary today. The public repository and testing artifacts are available for inspection while formal independent review remains a future milestone.
Can we evaluate our own workflow?
Yes. Submit the workflow above. The first step is to map the decision boundary and run representative eligible and blocked cases before discussing production integration.