Skip to main content
Cloak’s proofs come from one circuit. This page describes its shape, the published artifact bundle the SDK proves against, and how to verify that bundle yourself.

The transaction circuit

  • Template: Transaction(32, 2, 2) — a Merkle tree of height 32, two inputs, two outputs
  • Public signals: root, publicAmount, extDataHash, mintAddress, inputNullifier, outputCommitment, chainNoteHash
  • 42,672 constraints, 9 public inputs
Both the SDK and the on-chain verifier are built against this shape. Short input or output sides are padded with zero notes — see Core concepts.

Published bundle: circuits/0.2.0

The deployed program is keyed by the multi-party trusted-setup ceremony cloak-transaction-0.2.0 (6 named contributors plus a public final beacon). This bundle is the only one the program accepts; the earlier circuits/0.1.0 artifacts are rejected. Base URL: https://storage.googleapis.com/cloak-circuits/circuits/0.2.0/

Verifying it yourself

The SDK checks these digests before it proves, so a substituted artifact fails closed rather than producing a proof the program would reject. The expected digests ship in the package as EXPECTED_CIRCUIT_HASHES, and resolveCircuitsBase() reports the base the build is pinned to. To check by hand, download the two proving artifacts and compare:
The verifying-key digest is the one to care about most: it is what ties a proof to the deployed program. The full verification recipe, including the deployed program artifact, is in Release notes.
The bundle version and the SDK version are separate numbers. The current SDK is @cloak.dev/sdk@0.2.5; circuits/0.2.0 is a proving-artifact version and is unaffected by SDK releases. See Release notes.

What consumes it

  • The SDK loads the proving artifacts to build witnesses and Groth16 proofs
  • The deployed program verifies against the embedded verifying key
  • A circuit change would require a new ceremony, a new bundle and a program redeploy, because the program only accepts proofs from the key it was built with