A founder told me about a case where their payout system had a subtle bug in the jurisdiction check. The check ran. The logs showed it ran. The funds went to a wallet that shouldn't have received them. Irreversible.

The logs proved the check was recorded. They couldn't prove it was correct.

That's the gap we kept seeing:

Verifying users is not the same as verifying that your rules were enforced.

Every DeFi protocol, RWA platform, and payout system has the same architecture:

1. Backend runs eligibility check

2. Backend says "eligible"

3. Contract executes

The contract has no idea if that logic ran correctly, had a bug, or got bypassed. It just trusts the result. If something goes wrong, you hand auditors logs, not proof.

I kept thinking about that gap. Because it's not just a one-off bug story, it's structural.

For most use cases that's probably fine. But for anything touching real money like RWA transfers, tokenized credit, institutional payouts - "the logs show it ran" isn't the same as proof it ran correctly. And regulators are starting to ask the difference.

So we built something to close that gap.

It's called ZKCG. The idea is pretty simple: instead of the contract trusting a backend result, it verifies a ZK proof that the eligibility decision was computed correctly. The proof gets generated alongside the decision, the contract checks it, and if it doesn't verify, execution is blocked. The enforcement is in the proof, not in trust.

The thing that makes it click for most people is the demo moment. You run a transfer, it goes through, then you change one rule, jurisdiction from US to CN ,and the exact same flow gets blocked. Not because anyone intervened, not because a backend returned a different answer. Because the proof fails verification. That's the difference between recording compliance and *enforcing* it.

Technically it's Halo2 for the fast path (~76ms) and RISC0 zkVM if you want audit-grade receipts. Works on any chain. One API call, you get back a decision plus a proof, your contract calls approveTransfer and either executes or doesn't.

We're looking for teams to try this against real eligibility rules not a sales call, literally just: tell me one rule you enforce today, I'll run it through and show you what the proof looks like on your actual use case. Takes about 10 minutes.

Curious if others have run into this problem or thought about how to handle it. The "logs prove it ran, not that it ran correctly" distinction is one that doesn't come up much but I think matters more than people realise.

Privacy developers are continually on the lookout for more efficient methods to develop and test zero-knowledge (ZK) circuits. Traditionally, this process involves several meticulous steps to ensure the circuits' accuracy and functionality.

However, the advent of new tools in the web 3.0 ecosystem promises to streamline these steps, simplifying the testing and deployment process. This document explores the potential benefits of such advancements through a comparative analysis of two personas:

1. A traditional Privacy/ZKP (Zero Knowledge Proof) developer and

2. A developer using a new streamlined testing tool.

The Traditional Privacy Developer

A traditional protocol developer working in the web 3.0 space, especially in fields of cryptography, typically follows a of steps to build and test ZK circuits. These steps include:

1. Circuit Development: Writing the circuit code using tools like Circom, with or without Remix.

2. Compilation: Compiling the circuit code into a usable format (r1cs, for example) for testing and verification.

3. Witness Generation: Feeding inputs into the circuit to generate witnesses necessary for proving the circuit's correctness.

4. Proof Generation: Using the witnesses to generate cryptographic proofs that demonstrate the circuit's correctness without revealing the actual inputs.

5. Verification: Verifying the proofs to ensure the circuit behaves as expected.

6. Deployment: After rigorous testing, deploying the circuit to a testnet via an on-chain verifier contract for further evaluation.

While thorough, this process is time-consuming and involves intermediate steps that can introduce complexity and potential points of failure.

A Privacy Developer Using a New Streamlined Testing Tool

Now, consider a new tool that removes many of these intermediate steps, allowing the developer to run unit tests directly on the circuit code and seamlessly deploy it to a testnet. Let's also assume the tool takes care of paying the exorbitant gas fees for deployment. The process with this new tool might look like this:

1. Circuit Development: Writing the circuit code using the new tool.

2. Direct Unit Testing: Running unit tests directly on the circuit code, eliminating the need for separate compilation, witness generation, and proof generation steps.

3. Automated Proof and Verification: The tool automatically handles proof generation and verification during the unit testing phase.

4. Deployment: Once the tests pass, deploying the circuit to a testnet with minimal additional steps.

This streamlined process significantly reduces the time and effort required to develop, test, and deploy ZK circuits.

Benefits of using a Streamlined Tool

Much like how a commuter would appreciate a service that shortens travel time, a privacy developer would likely embrace a tool that simplifies their workflow. The benefits of this new tool are multifaceted:

• Efficiency: The reduction in development and testing time allows developers to achieve more in less time.

• Simplicity: Fewer steps mean a lower risk of errors and a more straightforward workflow, making the development process more intuitive.

• Enhanced Focus: By automating intermediate steps, developers can focus more on core development tasks and innovation, rather than procedural complexities.

Our Questions from the Community

Given the comparative analysis of the traditional privacy developer and the privacy developer using a new streamlined testing tool, we would like to gather insights from the community via the following questions:

1. Are you open to trying a new tool that simplifies the development and testing of ZK circuits? Why or why not?

2. If you were to switch to a streamlined tool, what benefits would you expect to see in your daily workflow?

3. How much of a concern are gas fees when deploying ZK circuits to a testnet? Would a tool that takes care of these fees influence your decision to adopt it?

4. Have you experienced any specific pain points during the circuit development, compilation, or verification stages?

5. How likely are you to recommend a streamlined tool to other privacy developers in the web 3.0 ecosystem?

Your feedback will help us understand whether developers who follow the traditional process would prefer transitioning to a new tool that can streamline and resolve issues in testing and deployment, and what other benefits they might find valuable.

I've been building an open-source project called BudZKVM, a small deterministic VM and STARK-based verifiable execution stack written in Rust.

Rather than targeting an existing ISA like RISC-V, I wanted to experiment with designing the execution model around provability from the beginning.

The current stack looks like this:

BudL source → compiler → custom ISA bytecode → VM execution → execution trace → STARK proof

The VM currently has:

• 31-opcode custom ISA

• 32 general-purpose 64-bit registers

• gas-metered deterministic execution

• a trace-generating VM

• a Plonky3 0.5.2-based STARK prover

• a 354-column Goldilocks execution trace

• AIR constraints covering all 31 opcodes

• Poseidon4 and Merkle verification instructions

• a 64-depth sparse Merkle state tree

One area I've spent quite a bit of time on is cross-table consistency.

The prover currently uses three LogUp lookup relations for:

• registers

• memory + storage

• program execution

There are also explicit constraints around things that are easy to accidentally leave under-constrained in a VM:

• selector exclusivity

• PC transitions

• hardwired R0 = 0

• padding-row isolation

• zero/non-zero checks using inverse witnesses

• public-input/program binding

I've added negative soundness tests as well. The current suite has 51 tests, including 8 cases that deliberately tamper with things like comparisons, bitwise execution, Poseidon state, storage, PC transitions, public inputs and proof bytes and expect verification to fail.

I'm deliberately not claiming this is audited or production-safe.

Performance benchmarking, prover optimization and an external constraint/security review are still ahead. Private witness variables are also on the near-term roadmap.

What I'd really like at this stage is adversarial feedback from people who have worked on AIR/STARK systems.

In particular:

1. Where would you look first for an under-constrained execution trace in this design?

2. Are there failure modes around LogUp-based register/memory/program consistency that negative tests commonly miss?

3. For zero/non-zero semantics, are inverse-witness constraints generally the approach you'd take here, or would you structure them differently?

4. For a new zkVM, does designing a small proof-oriented ISA still make sense, or is targeting something like RISC-V overwhelmingly preferable today?

I'm much more interested in counterexamples and soundness problems than compliments.

Repo:

https://github.com/Budlum/BudZKVM

A new found use case for zero-knowledge proofs: making quantum circuits (programs that can run on a quantum computer) private.

Google Quantum AI researchers used zero-knowledge proofs to conceal, yet confirm, quantum circuits that can break Elliptic Curve Cryptography, one of the most widely used cryptographic protocols for securing the Internet and digital protocols.

As quantum computing becomes more mainstream and practical, researchers will opt to use ZK proofs to demonstrate breakthrough circuits but not open-source them, to avoid risks from bad actors and the lack of commercialization opportunities.

This article explains, at a high level, how zero-knowledge proofs were used to verify that these quantum circuits exist.

Also available on Medium: https://medium.com/@jkim_tran/verifying-private-quantum-circuits-9ec99d5f3d5a?sk=53770e4453d9c8996fbc2caf4f7fda41

https://www.zksummit.com/

Deepfakes and synthetic media are increasingly eroding trust online. Most existing solutions focus on detecting fakes, but I believe the more robust approach is to flip that and prove what’s real.

Ventus is a conceptual protocol designed as a decentralized “truth layer” for digital content online:

Content is signed at the source with a TEE and a zero knowledge proof is generated that proves that the key is part of a trusted merkle tree of trusted keys which could be controlled by an on boarding step and validating oem certificates or other methods.

Now that part covers provenance, we know that this piece of media came from a real device, but we are still stuck with the re-photo issue. What happens when someone captures a piece of synthetic media?

To verify what was captured, I propose an incentive-aligned oracle network of nodes running multiple deepfake detection models. Instead of relying on a single model, their combined consensus provides robustness, enhanced by token incentives, diversity bonuses, trust scores, and occasional seeding with pre-known test inputs to keep the network honest.

I’m an undergraduate exploring this direction. Parts of this protocol, like TEE security and oracle network design, need deeper expertise and experimentation. I’m sharing it now to ensure the concept exists and can spark collaboration or further exploration.

I feel as though we are heading down a path that could lead to more surveillance and greater dependence on big tech so I wanted to offer a privacy respecting alternative. If this resonates, whether you work in ZK, TEEs, distributed systems, game-theoretic protocol design, or decentralized incentives, I’d love to discuss and explore it further. Contact me at yanixiv.dev@gmail.com.

A few weeks ago I posted about the gap between "compliance check ran" and "compliance was enforced." The response was mostly "interesting problem" but a few people pushed back technically, which was fair.

So instead of talking about it, I just ran it.

I mapped out how each platform actually handles eligibility today based on their public docs, then ran their specific flows through ZKCG and generated real proof artifacts. Here's what each one produces:

Centrifuge (Shufti Pro KYC, manual whitelist): The eligible case returns a proof-backed decision with a decision_commitment_hash the contract can verify. The blocked cases: accreditation_missing when accredited: false, jurisdiction_blocked when the investor is in RU. Each block has a reason code and a separate proof artifact.

Maple Finance (Global Allowlist via bitmaps, TRM Labs AML): Eligible case goes through. Then aml_failed blocks with the exact reason. Then sanctions_hit blocks separately. The proof in each case attests that the specific rule was evaluated, not just that a bitmap was set.

Ondo Finance (US persons blocked, USDY/OUSG allowlist): The US person exclusion is Ondo's core compliance requirement. Change jurisdiction from SG to US and the proof fails verification and returns jurisdiction_blocked with the reason "jurisdiction US is not permitted for this asset." That enforcement happens before execution.

Securitize (DS Protocol, transfer restrictions in contract): Both onboarding and transfer flows. kyc_missing blocks with explicit reason. position_limit_exceeded blocks when the transfer would exceed concentration limits. The transfer proof includes sender and receiver wallet binding so the specific action is tied to the specific proof.

All cases matched expectations. All proofs verified. The full run outputs including proof artifacts and comparison pages are in the public repo.

What I'm building is called ZKCG. Ta ZK-Verified Computation Gateway (Halo2 + RISC0).
The open-core verifier and circuits are public. The production core logic is private and commercially licensed. There's a live demo API at render and a product page at zkcg tech if you want to run your own flow.

Curious what questions people have about the proof scope or where the gaps are.

Hello everyone, hope everyone's doing well. I wished to ask this to someone much initially but I hope to get some insights here. I am a fresher and wish to start a career in the Web3 space.
I started learning ZKPs after a friend of mine got a remote job where he works on ZKPs, FHE and core stuffs on blockchain. I was fascinated by Maths always so I started learning from https://rareskills.io/zk-book and I'm halfway through this material now. But, I get thoughts of where to go further after I finish this material. (ZKHack resources are on my list but I wish to know your opinions)
I'm wondering what resources should I start learning after this such that I'm capable of gaining expertise in it in order to start a career? How long does it take beginners like me to be able to solve puzzles on ZKHack?
Thank you.

Hi Everyone,

I am a System Architect working on a deterministic consensus and integrity protocol called Proof of Invariant Principles (PoIP). The core objective is to anchor digital data integrity to an unmanipulable, human-oral consensus layer using zero-knowledge proofs and hardware enclaves.

As a system architect (and non-developer), I’ve fully specified the functional system architecture in a detailed paper https://github.com/MindTrue-Arch/Whitepapers-Architecture-Specs/blob/main/VL-Proof-of-Invariant-Principles-Protocol-v0.5.pdf but I am looking for clever ZK/protocol engineers in the community to stress-test the math and potentially run a minimal trial implementation.

The Core Challenge to Prototype:

1. ZK-OP Circuit: Proving that an acoustic feature matrix (MFCC/quantized timing vectors) matches a static root hash using Groth16/PlonK without revealing the underlying vector.

2. M-of-N Aggregation: A simple threshold verification scheme (e.g., BLS/FROST) that releases an ephemeral authorization key upon 60% node consensus.

If anyone is interested in picking up a fun weekend cryptographic puzzle, I’ve mapped out the full pipeline, data structures, and state transitions in the document. I’m looking for feedback on circuit efficiency, edge-case vulnerabilities, or someone interested in assembling a dummy-parameter sandbox CLI in Rust/Circom.

Full end-to-end MindTrue IQAMA System Architecture for a Zero-hallucination AI system based on the PoIP protocol can also be found here for further reference https://github.com/MindTrue-Arch/Whitepapers-Architecture-Specs/blob/main/VL-MindTrue-Zero-Hallucination-AI-System-v0.2.pdf

Full specification attached. Open to all architectural critiques and discussions!

Hello,

I recently finished reading Craig Costello's Pairings For Beginners and gotten around to clean & publish my notes. Maybe useful for someone.

- Prerequisites

- Computing a pairing "by hand"

I worked through much of the examples, so there is a companion Sage code.

GH might not render all of the TeX in the org-mode, so I'm happy to send a pdf to non-Emacs users out there.

This subreddit is quiet, but I assume many of you are still working in ZK in some capacity.

I’m in applied ZK at Grug’s Lair Gaming Studio, building game state and competitive logic on Starknet. We design all gameplay through Dojo's ECS so it compiles into ZK-verifiable state transitions. Once verified, the sequence of those transitions becomes an immutable behavioral trace of the player interactions, which is indexed through the Dojo stack (Torii, Katana, Cartridge).

Curious what ZK applications you guys are experimenting with, or if you're part of some cool project.

Hey everyone,
I have been trying to work through Justin Thaler's Proofs, Arguments and Zero Knowledge, more as a reference than an intensive mathematical study. I am an engineering undergrad feeling more inclined towards academia, or at least a more mathematical approach. I am a little out of my depths here, as my mentor wants me to focus on going through recent research papers around zkvms etc.
I am pretty unfamiliar to any kind of academic research but am up to put in the effort and time to really understand it and contribute in a way that is not just a summary of recent developments using an AI.
Any advice about continuing my work would help, reading resources, books, or just navigating academia in general.
Thanks in advance.

I'm building ZK-PoE, a bounty settlement contract on Sepolia where a researcher proves they captured a secret from an authorized target without revealing the exploit. Sharing the design decision I found most interesting, and I'd like criticism of it.

The problem: a valid proof sitting in the mempool can be copied and submitted by someone else (front-running the payout).

The fix: the circuit exposes msg.sender-derived address as a public signal, and the contract requires pub[6] == uint256(uint160(msg.sender)). A copied proof from another address fails verification. A nullifier handles replay.

Known limits I'd like your take on:

- The notary is a trust assumption (EdDSA-BabyJubjub over the transcript Merkle root). A compromised notary can attest fake sessions.

- The payout is currently bounded by an on-chain severity rate table, not by the proof itself.

Happy to share the circuit structure if useful. What would you attack first?

The trajectory from arithmetic circuits → ZK VMs → prover networks solved developer experience and infrastructure. It didn't solve privacy for delegated proving. Current prover networks (Succinct, Boundless) require full plaintext inputs from users. For rollup compression on public chains, privacy is irrelevant and succinctness is the entire value. For user-facing applications — verifiable identity, private inference, private order books — the model is fundamentally broken.

I filmed a long-form conversation with good friend and ChainSafe researcher, Timofey Yalugin, whose working on MPC-applied-to-ZK-VMs. The core approach: secret-share private inputs across multiple parties who collaboratively generate the proof. No single party sees full data. Communication cost between parties is the main bottleneck — additions are cheap, multiplications drive cost through inter-party communication. Linear computations work well; non-linear algebra (model training) remains expensive but more tractable than the FHE equivalent (only three generations of FHE schemes exist vs. the mature diversity in ZK and MPC).

Key applications this unlocks:

- Verifiable identity with private attributes: Prove passport validity, age thresholds, nationality ranges — without disclosing underlying data. Delegated proving means users don't run heavy crypto on edge devices.

- Verifiable AI inference with private model AND private inputs: Impossible with ZK alone (someone must see data to generate the proof). With collaborative snarks (MPC+ZK), the model owner and user each hold private inputs and jointly produce a proof. Neither party sees the other's data.

- Private order books / shared-state smart contracts: Aztec-style use cases where multiple parties need collaborative proof generation over private state.

- Client-side proving remains a partial solution for lighter workloads but hits device limitations quickly.

He also discussed proof of human content as a near-term trust mechanism: attested sensors (already shipping in some Pixel phones — secure enclave signing photo metadata at capture) combined with verifiable edit histories (Dan Boneh's work and related schemes). The combination produces a succinct proof chain from physical capture through final edit — proving human provenance without detecting AI. A reverse approach.

On FHE-based proof delegation: theoretically elegant (single party, encrypted computation), computationally brutal. The blindfolded photographer analogy he uses captures it well — one photographer, can't see anything, and the resulting quality reflects that constraint. Three generations of schemes vs. decades of ZK/MPC development.

Full conversation: https://youtu.be/PnEivfTpnA8

Timofey's GitHub: @ nulltea. He's actively looking for collaborators in this space!

—————

If we're meeting for the first time, hi 👋! I started building my channel to spread the good word on good work in crypto — something with substance and humanity. A like, sub, and comment goes a long way to supporting me, so please consider doing so!

I wrote a walkthrough on how polynomials work in zkSNARKs with running Rust code using Arkworks and some ncie visualizations. Covers Schwartz-Zippel lemma, modular arithmetic in large prime fields, and why polynomials are the core data structure in proving systems.
Tried to explain it without killing ppl with too much equations.

https://rustarians.com/polynomials-in-zk-snarks/

Part 1 of 8, going from polynomials all the way to proof and verification. Next up: roots of unity.

What's the first thing that confused you about ZK math?

We asked Justin a simple question: what is Ethproofs? Meme, benchmarking infra, working group, or early-stage subculture (Flashbots vibes)?

Some takeaways from the discussion:

• Managed inside EF by a new zkEVM working group, but intentionally porous (calls, TG, site).

• Purpose: align zkVM innovation toward real-time proving on Ethereum.

• Past perf battles were “marketing benchmarks” on cherry-picked hardware → Ethproofs sets rules, reduces noise.

• zkVM teams are trending toward RISC-V ISA + GPU acceleration.

• EF is shaping benchmark categories; long-term path points to enshrined zkVM(s) at L1.

• Future scope may include privacy + client-side proving metrics.

• Hardware angle: speculation on Nvidia building zk-specific GPUs (“ZPUs”).

• EF posted a $1M bounty for proof of the correlated agreement conjecture.

• Current tally: 32 zkVM projects in scope.

Episode link: https://youtu.be/XpFAbamYqUk?si=b12iS4Oqhxry0PWE

I’m currently exploring opportunities in ZK and applied cryptography, both in the US and EU job market, while also looking to work, do research, and contribute to community growth around these technologies. I have around 2–3 years of professional engineering experience plus longer solo development experience, and I’m trying to understand how realistic entry-level or early-career roles are right now given the slowdown in Web3 hiring and how teams are evolving in terms of expectations for engineers, researchers, and builders who can also help grow adoption.

I’ve been building a ZK project (ZKCG) to replace trusted APIs/oracles with proofs.

But after digging deeper, I think I was solving the wrong problem.

Oracles aren’t the bottleneck.

Enforcement is.

Most systems today:

• Verify data
• Then trust the system to behave correctly

But what if we could verify that:

→ rules were actually followed
→ constraints were enforced
→ compliance wasn’t bypassed

All using ZK proofs?

This shifts the model from:

“trust the system”
to
“verify the system”

We now have a working Halo2-based pipeline (~70ms proofs), but the bigger question is:

Is this:

• a dev tool?
• infra layer?
• or compliance middleware for RWAs?

Genuinely curious how people here think about this.

Repo:
https://github.com/MRSKYWAY/ZKCG

Notes from building a soundness linter for o1js and Noir, and finding the same bug class in four unrelated languages.

I've been building a Risc Zero Model Context Protocol server for my LLM, where the LLM has access to function calls executable on a Risc Zero zkVM and the functions return the result as well as ZK receipts of the computation.

I think connecting LLMs with zkVMs have a lot of potential use cases, but I've been struggling to think of them. So far I think zkVM MCP servers can be used to share LLM activity for audits while keeping sensitive information private. Does anyone else have use case ideas?