> For the complete documentation index, see [llms.txt](https://knidos.gitbook.io/knidos/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knidos.gitbook.io/knidos/zk-proof-of-trades.md). # ZK Proof of Trades At Knidos, performance is only half the story. The real challenge is trust: how can users be sure that the AI fund manager is making real trades, following agreed limits, and not running as a hidden ponzi scheme—without us exposing the proprietary algorithm? Our solution is **Zero-Knowledge (ZK) proofs**, published daily. They mathematically verify that trades happened under strict conditions, while keeping the trading logic, data pipelines, and wallet addresses private. ### The Problem: Transparency vs. Security Users want guarantees: * Are profits generated by actual trading, not inflows from newcomers? * Are trades only executed on approved exchanges and tokens? * Are risk constraints respected (e.g., no overexposure to volatile assets)? * Can personal, ethical, or regulatory boundaries be enforced? Publishing raw trade logs would answer these—but at the cost of **reverse engineering** (competitors or attackers training counter-AIs) and **inefficiency** (thousands of transactions per day cannot be validated on-chain without breaking UX). ### The ZK Solution ZK proving allows us to keep inputs private while proving compliance. **Private Input:** * The AI’s full transaction history. **Public Inputs:** * Blockchain Merkle roots of transactions. * Exchange-provided signed statements. **Circuit Checks:** * All transactions occurred within the declared time window. * Only whitelisted exchanges and assets were used. * Net profit matches the reported APY. * Trades are statistically distributed across assets (no concentration risk). The output is a compact proof that the AI acted inside its boundaries. Importantly, the proof guarantees existence and legality of trades without exposing wallet addresses, order books, or strategies. ### Security Guarantees The proof includes only high-entropy commitments like Merkle roots or CEX signatures. This prevents brute-force attempts to link trades back to Knidos wallets, mitigating the reverse-engineering threat. Even if someone tried, they would face an unsolvable information gap. ### Performance and Latency * **Verification cost**: constant. One proof covers an entire vault, regardless of user count. As the community grows, cost per user asymptotically approaches zero. * **Proof generation**: heavier. Complex circuits may take minutes to compute. * **Latency model**: acceptable, because withdrawals are infrequent (daily at most). “Optimistic withdrawals” allow users to act immediately, with final verification confirmed once the proof completes. Parallelized proving lets us publish proofs at any desired frequency. ### Beyond Trust Daily ZK proofs mean Knidos is not asking for trust in people, reputation, or brand. Users trust mathematics. Every vault can cryptographically demonstrate that: * trades are real, * trades follow declared rules, * and reported performance is genuine. This is more than a transparency feature—it is a new standard for on-chain asset management. Knidos proves that AI trading can be both **private and verifiable**, marking a shift toward a financial future where trust is no longer promised, but mathematically enforced. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://knidos.gitbook.io/knidos/zk-proof-of-trades.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.