# Why We Ended Up Building on Aztec *Navigating the Tension Between AI and Regulation: Why We're Building on Aztec* By [MetaEnd](https://paragraph.com/@metaend) ยท 2026-04-22 aztec, ai, zeroknowledge --- * * * A quiet shift is happening between AI and regulation, and most people in either field are underestimating it. On the AI side, models now routinely touch data with real privacy and legal weight: building operations, emissions, supply chains, medical flows, financial positions, biometric evidence. The more useful a model gets, the more of that data it ingests and the more it derives inferences from. On the regulatory side, jurisdictions have started demanding proof, not claims, that specific thresholds are being met. Carbon intensity bands. Fair-lending scores. Model-bias audits. Human-oversight attestations. The direction is clear: if an AI system is making decisions about you or your asset, someone wants a verifiable record that the decision was legitimate. The tension is obvious. You cannot publish the raw data. It is commercially sensitive, personally identifying, or legally restricted. But you also cannot just trust a certificate PDF signed by "TrustMeBro Ltd." Regulators want cryptographic teeth. Users want privacy. Both sides are, in principle, right. This is a very old cryptographic wish list with a very new urgency. The shape of the problem ------------------------ Strip away the domain specifics and you end up wanting something like: * A private record of the full, honest data, readable only by its owner and their auditor. * A public summary of the _outcome_, readable by everyone: pass/fail, a band, a status. * A cryptographic link between the two, so the summary cannot lie about the data. * Selective disclosure: the owner can show the full record to a specific regulator later, without making it globally public. * A way for the auditor to be named on-chain without leaking who they audited for. This is a ZK-shaped problem. More specifically, a _private smart contract_ shaped problem: you need state, access control, something like events, and the private and public halves must be part of the same computation. Why not the obvious options --------------------------- We looked at what was available. **ZK rollups on Ethereum** are mostly optimised for scaling, not privacy. State is public by default. You can bolt on ZK-SNARK flows for individual actions, but building a stateful privacy-preserving contract on top of a transparent rollup means reinventing half of what a privacy L1 gives you for free. **Mixers and payment-privacy protocols** handle value transfers well but do not give you general-purpose contract state. Wrong shape for attestation. **Fully homomorphic approaches** are philosophically beautiful but operationally painful for anything beyond toy workloads. Performance and tooling are not there yet. **Off-chain ZK with on-chain verifier** (the "SNARK library plus verifier contract on Ethereum" pattern) works, but every piece of state you want to keep private still has to live off-chain in a trusted service. You end up rebuilding a PXE of your own, badly. What we needed was a chain where private state is a first-class primitive, not an afterthought, and where a single contract can hold both private notes and public state and hand off between them cleanly. How Aztec fits -------------- Aztec splits every contract into two execution layers. Private functions run in the user's own browser or client, produce a ZK proof, and emit encrypted notes that only the intended recipient can decrypt. Public functions run on the rollup like a normal L2 and see only the aggregate, non-sensitive state. In practice this maps directly onto the attestation problem: * Raw data goes into a private note, encrypted to the data owner and their verifier. * A private function computes the outcome (compliance check, intensity band, risk score) from the raw data. * That private function enqueues a public call that writes only the outcome to on-chain state, visible to anyone. * The user can later re-encrypt the same private note to an auditor's key, giving that specific auditor full visibility without making the data public. The chain sees a public summary, a verifier address, a timestamp. The world sees enough to trust the system without seeing anything sensitive. The regulator can demand the underlying data directly from the owner and verify it matches the on-chain commitment. That is the shape we wanted. Aztec is the first mainstream system where it is not a research project to build. The missing half ---------------- There is a matching problem upstream. The data reaching the private note does not appear from nowhere. It passes through a pipeline: meters, parsers, AI agents, API pulls. If that pipeline is opaque, the on-chain rigor is undercut by an ungovernable off-chain half. We run that layer in [WasmBox](https://tangled.org/metaend.eth.xyz/wasmbox-cli), a capability-sandboxed WASM tool launcher we built for exactly this kind of workload. Every execution runs against explicit syscall-level grants, produces an append-only JSONL transcript, and signs the transcript hash with Ed25519. That signed hash becomes the `raw_data_hash` committed in the Aztec note. On-chain you see the commitment. The auditor, when invited, reconstructs the full execution log the commitment points to. The two halves answer different questions. Aztec answers _"what can the public verifiably know about private state?"_ WasmBox answers _"what can we verifiably say about how that state was produced?"_ Together they give you an honest claim about private data, end to end. ![](https://storage.googleapis.com/papyrus_images/d92054254e52b4839686ded06dcd96d25207476fe33eb0ac55dea74ddaca656b.png) What it actually feels like to build on --------------------------------------- We implemented a real contract, around 300 lines of Noir, covering the full flow: admin, verifier registry, private attestation with a private-to-public teardown, public read endpoints, and selective disclosure to auditors. Then we migrated it to the just-released `v4.2.0-aztecnr-rc.2`. A few honest observations. The mental model is good. Once the private/public split clicks, writing privacy-preserving contracts stops feeling exotic and starts feeling ordinary. The syntax is Noir: more Rust-like than Solidity-like, with strong types and a real compiler. The tooling is young. The `v4.2` release is a near-total API rewrite compared to six months ago. That is healthy for a young system but brutal on documentation; half the tutorials you find online are already wrong. Expect to read the sample contracts in the monorepo more than the docs. The local sandbox works, and that is a bigger deal than it sounds. You can boot an L1, the rollup, and the PXE in one command, deploy a contract, and exercise the full private-to-public flow on a laptop in under a minute. That single fact is the best predictor of whether a chain is real to develop on. Production is still ahead. A disclosed critical vulnerability in the proving system (mid-March this year) means real mainnet deployments with real data should wait for the `v5` release, targeted for mid-2026. Testnet and sandbox are fine for building now. What we are sitting with ------------------------ The thesis is simple. AI is about to make "honest claims about private data" the bottleneck for a lot of real-world compliance. The chains that natively support private state and selective disclosure are going to be where that workload lives. Aztec is the most coherent attempt we have seen at that primitive, and it is far enough along to build against seriously. We are not betting the company on it. We are doing what you should do with any young infrastructure: building something real on it, learning what it can and cannot hold, keeping our options open. If a better shape of the problem appears, we move. If `v5` ships on schedule and holds up under real traffic, we stay. Either way, the underlying question, _how do you prove something about private data without revealing it?_, is only going to get louder from here. * * * **Disclosure**: I do not hold AZTEC tokens and have no financial position in the Aztec Network. This work is pure research and development. The observations above reflect what we found while building; they are not investment advice, not a partnership announcement, and not a prediction about token price or timing. WasmBox is our own product and I have a commercial interest in its adoption. If any of the above changes I will say so. --- *Originally published on [MetaEnd](https://paragraph.com/@metaend/why-we-ended-up-building-on-aztec)*