Cloak Protocol Security Update: Turning an AI-Discovered Circuit Issue Into a Stronger Protocol

Crypto security is entering a new era.

For years, protocol security depended on a very small group of highly specialized auditors, cryptographers, and protocol engineers. That is still true for final judgment and responsible fixes. But something important has changed: frontier AI models are now good enough to help people inspect complex open-source systems in ways that were not realistic even a short time ago.

This has major consequences.

It means attackers can move faster. But it also means communities can move faster. Bugs that might have remained hidden for years can now be found earlier, responsibly disclosed, and fixed before damage is done.

We just experienced this directly with Cloak.

A community member, Porky, used an AI model to review the open-source Cloak protocol code. Porky is not a zero-knowledge cryptographer. He did not spend months manually auditing zk-SNARK circuits. He used modern AI tooling to ask the right questions and inspect the code.

The model identified a real issue in the spend_output circuit.

After reviewing it carefully, we confirmed the issue. The circuit created internal signals related to value balance, but the necessary constraints tying those signals back to the actual hidden note amounts were incomplete. In simple terms: the circuit was supposed to prove that the value being spent and the value being created were balanced. The structure for that logic existed, but part of the actual enforcement was missing.

That is serious. Circuit soundness matters. In zero-knowledge systems, the verifier only sees the proof and the public inputs. If a circuit does not enforce an invariant, the contract cannot magically recover that hidden information later.

The good news: there is no evidence that this was exploited. The contracts have already been locked for spends to protect the pool while we prepare the fix. Cloak is still early, the current Merkle tree contains only a small number of leaves, and we are in a position where we can fix this properly without a painful migration for users.

We want to publicly thank Porky for reporting this. He will receive a bug bounty.

What exactly happened?

The affected area is the spend_output circuit.

This circuit is responsible for a transaction shape where a shielded note is spent and a new shielded note and/or public output is created. The protocol needs to prove that the accounting balances without revealing the private note values.

The bug was not in the cryptography primitives themselves. It was not a broken hash function, not broken encryption, and not a compromise of user keys.

It was a circuit constraint issue.

In zk circuits, simply computing a value inside the witness generator is not enough. The circuit must constrain that value. Otherwise, a malicious prover can provide a different witness and still satisfy the proof system.

Once confirmed, we immediately moved to protect the system by blocking spends while the fix is prepared.

Why this is also an opportunity

Because this is a circuit issue, the fix requires new zk-SNARK parameter files and new verifying keys. That means we need to run another trusted setup ceremony.

That is a big deal, but there is no way around it. When a circuit changes, the proving and verifying parameters must change too.

Since we have to do that anyway, we are going to use this opportunity to improve Cloak further.

The main additional improvement we are planning is reducing the Merkle tree depth.

The current tree depth was designed for a very large anonymity set: over one million leaves. That is theoretically nice, but it also makes proof generation slower. The Merkle path is part of the circuit, and each level adds expensive boolean/hash constraints. In practice, this affects user experience.

Cloak is still early. The existing tree has far fewer than 1,024 leaves. So we can safely migrate the existing leaves into a smaller tree while preserving their logical positions.

The planned new tree depth is 10, which means 1,024 leaves.

This reduces the maximum tree capacity compared to the old design, but it still provides a meaningful anonymity set for the current stage of the protocol. More importantly, it improves proving performance, reduces the on-chain RAM costs dramatically and makes Cloak more usable.

Privacy is not only about theoretical maximum anonymity. It is also about whether people can actually use the protocol comfortably.

A privacy system that is too slow for users is not good privacy.

Will existing notes break?

No.

The note commitments themselves are independent of the Merkle tree depth. The encrypted note data is also independent of the Merkle tree depth.

The one detail we had to check carefully was nullifiers.

In Cloak, nullifiers depend partly on the note’s Merkle position. That means we cannot reorder leaves, compact the tree, or move notes to different logical positions. If we did that, we could break nullifier consistency.

Luckily, because the current tree has far fewer than 1,024 leaves, we can migrate every existing leaf into the new depth-10 tree at the exact same logical index.

Old leaf #0 becomes new leaf #0.

Old leaf #1 becomes new leaf #1.

Old leaf #137 becomes new leaf #137.

And so on.

That preserves the position value used in nullifier computation. The new root and authentication paths will change, because the tree itself is rebuilt with a different depth. But the notes, commitments, and logical positions remain intact.

Wallets will need to resync because old cached Merkle paths and tree data are no longer valid. But user funds do not disappear, notes are not corrupted, and users do not need to create new shielded funds from scratch.

What users will need to do

Once the upgrade is ready, users will need to:

1. Back up or export their current wallet seed/private key.
2. Download the new Cloak wallet version.
3. Delete the old local wallet file.
4. Import the existing seed/private key.
5. Resync from chain.

This is important. The old wallet file contains cached chain-derived state based on the old Merkle tree depth. The seed remains valid, but the local wallet state must be rebuilt.

We will publish clear instructions before the wallet update goes live.

What we are doing now

The recovery plan is:

1. Keep spends disabled to protect funds.
2. Patch the affected circuit constraints.
3. Add regression tests, including malicious-prover tests.
4. Add additional contract-side sanity checks around public unshielded outputs.
5. Reduce the Merkle tree depth from 20 to 10.
6. Generate new zk-SNARK parameters through a new trusted setup ceremony.
7. Deploy updated smart contract code.
8. Migrate the existing leaves into the new smaller Merkle tree while preserving order and logical positions.
9. Update the on-chain verifying keys.
10. Release a new wallet with the new parameters.
11. Ask users to recreate their wallet file from seed and resync.
12. Re-enable spends after validation.

This will take at least a few days. We will not rush it.

Why we are being public about this

The core Cloak protocol (zeos-caterpillar) is open source. That is intentional.

Open-source privacy protocols are supposed to be inspected. That includes inspection by cryptographers, developers, auditors, community members, and now AI-assisted tooling.

This is the new reality. Anyone can point a frontier model at a repository and ask hard questions. That increases risk, but it also increases defense. The right response is not to hide. The right response is to move fast, verify carefully, reward responsible disclosure, and improve the protocol.

We are still early enough to make this fix cleanly.

No damage has been detected.

The issue has been identified.

The contracts are protected.

The fix is understood.

The upgrade path is clear.

And Cloak will come out of this stronger: with corrected circuit constraints, a fresh trusted setup, better tests, improved contract-side validation, much less RAM consumption and faster proving time thanks to a smaller Merkle tree.

Thank you to Porky for taking the time to review the code and report the issue responsibly.

This is exactly how open-source crypto should work.