1. Inspiration
As AI agents mature, the autonomous trading programs are beginning to execute real money on behalf of clients. For a trade to be verified as compliant, the AI must present three evidences to the auditing party:
- Trade ≤ 5%% NAV limit — but only the custodian holds the NAV;
- Counterparty not sanctioned — but that data sits in a compliance oracle;
- Decision not market manipulation — but that logic is proprietary to the quant strategy.
Every party has a legal right to refuse the AI's request for data:
- The custodian cannot disclose portfolio data;
- The compliance database cannot be made public;
- The trading strategy is a trade secret.
So how can an agent prove it was compliant without any party revealing their private data? That’s the problem we set out to solve.
2. What it does
AuditProof is a zero-knowledge compliance framework for autonomous AI agents. Three mutually distrusting institutions each verify one slice of private fact locally (portfolio NAV, trading hours, sanctions list) and sign a compact cryptographic verdict.
A Groth16 circuit combines those three signatures with a binding commitment to the agent's reasoning, producing one auditable proof:
These three institutions verified my trade, and here is a binding commitment to the reasoning I acted on.
The on-chain TradeExecutor records every proof permanently that compliant trades is executed; non-compliant trades revert but leave a permanent, regulator-readable audit trail.
Target users: Autonomous trading agents/ Compliance officers/ Regulators (EU AI Act Art.12, MiCA)
Key features:
- Reasoning-as-auditable-object — the agent commits to its reasoning text before it learns any compliance verdict, preventing post-hoc rationalization
- Three-witness binding — all three institutional signatures endorse the same reasoning commitment, so changing the story invalidates all three signatures simultaneously
- Permanent audit trail — blocked trades are also recorded, giving regulators a complete picture
- Ambiguity surfacing — the Policy Compiler flags underspecified policy language and records which interpretation was chosen
3. How we built it
Frontend
- HTML + CSS – Compliance officer dashboard
- JavaScript + Ethers.js – Query on-chain records from TradeExecutor
Backend & Off-Chain
- Node.js + Express – Three witness services (custodian / oracle / sanctions), each holds its own EdDSA private key and signs compliance verdicts
- Claude API – Policy Compiler: parses natural-language rules into circuit constraints, emits ambiguity_notes for vague rules
Smart Contracts
- Solidity 0.8.24 – Verifier.sol (proof verification) + TradeExecutor.sol (execute or record rejection)
- Hardhat – Local deployment and testing
ZK Circuit
- Circom 2.1 + Groth16 – Combines 3 signatures + reasoning commitment into one proof
- Snarkjs – Trusted setup, zkey generation, proof generation & verification
4. Challenges we ran into
Circuit Debugging: Circom has limited tooling. Combining 3 EdDSA signatures with reasoning commitment into one circuit caused constraint conflicts even when each component passed individually. We isolated and tested each module separately, then re-integrated step by step with intermediate signal logging.
Poseidon Hash Mismatch: The off-chain proof passed, but on-chain verification kept failing. Root cause: circomlib's Poseidon implementation differed from the Solidity version. We fixed it by locking the same circomlib version and standardizing input encoding.
Witness Service Sync: Three witness services needed parallel responses. Promise.all handled concurrency, but timeouts were required. We added a 5-second per-service timeout so the agent fails fast if any witness is offline.
5. Accomplishments that we're proud of
- Implemented a reasoning-commitment circuit that rejects post-hoc fabrication
- Built a 3-of-3 witness signing flow that timestamps the reasoning commitment before compliance verdicts are known
- Split execution and recording into two on-chain functions
- Built a Policy Compiler that surfaces ambiguity_notes for underspecified policy rules
6. What's next
| Limitation | Mitigation | |
|---|---|---|
| 1 | tradeHash is not recomputed on chain via Poseidon (too expensive today) |
Regulators recompute off-chain; production can integrate Poseidon precompiles |
| 2 | The reasoning commitment proves binding, not that the reasoning is honest | kills post-hoc fabrication; honest-dishonest is a separate problem |
| 3 | Single-party trusted setup | Production needs multi-party ceremony or PLONK/Halo2 migration |
| 4 | Three-of-three witnesses; any one offline halts the agent | Threshold signatures are next step |
Built With
- anthropic
- circom
- circomlib
- express.js
- groth16
- hardhat
- node.js
- snarkjs
- solidity
- typescript

Log in or sign up for Devpost to join the conversation.