Skip to main content

Zero-Knowledge Proofs (Operational View)

A zero-knowledge proof allows a party to prove that a specific computation or set of rules was executed correctly without revealing the private inputs used to perform that computation. The chain does not execute the logic itself. It verifies a proof that the logic was executed correctly off-chain. Operationally:
  • computation and sensitive data stay off-chain
  • the contract only verifies proof validity
  • verification cost is bounded and predictable
This model is used to enforce correctness without exposing data or paying full on-chain execution costs.

ZK Contracts Without Writing Solidity

The system allows users to deploy ZK-powered smart contracts without writing Solidity or implementing ZK circuits manually. Users define constraints — the rules that must be satisfied — and the platform generates the circuit, prover, and on-chain verifier. At deployment time:
  • constraints are compiled into a ZK circuit
  • a verifier contract is deployed on-chain
  • no private logic or data is stored on-chain
The resulting contract behaves like any other Ethereum contract, with the difference that correctness is proven rather than executed.

Constraint Definition (What Users Actually Specify)

Users define constraints that describe what must be true for a proof to verify. These constraints map directly to circuit conditions and verifier checks. Typical examples include: Trading rules
  • a trade size is within a defined range
  • execution price is within a tolerance of a reference price
  • slippage remains below a fixed threshold
The contract enforces the rule without revealing trade size, entry price, or strategy. Risk limits
  • wallet balance is above a minimum
  • leverage stays below a maximum
  • drawdown remains within bounds
The proof shows compliance with the risk model without exposing balances or positions. Strategy proofs
  • a sequence of actions followed predefined logic
  • parameters stayed within allowed ranges
  • outputs were derived from approved inputs
This allows users to prove a strategy was followed without revealing the strategy itself.

Proof Flow and On-Chain Verification

Proofs are generated off-chain using private inputs and the deployed circuit. The proof is submitted to the verifier contract, which performs a cryptographic check and gates execution on the result. What matters for implementation:
  • the contract never receives private inputs
  • only the proof and public parameters are submitted
  • execution is conditional on proof validity
If the proof verifies, the contract proceeds. If it fails, the transaction reverts.

Dashboard vs API (Same System, Different Interfaces)

The Dashboard and API are two interfaces over the same contract and circuit generation system. The Dashboard is intended for rapid definition and deployment:
  • constraints are defined declaratively
  • contracts are generated and deployed automatically
The API exposes the same capabilities programmatically:
  • constraints defined as structured inputs
  • integration into bots, backends, or automated systems
There is no functional difference in the resulting contracts.

Running Contracts on the Network

Verification on Ethereum has a fixed cost ceiling, but that cost is non-trivial at scale. The system will support running ZK contracts on a dedicated network where proof validation is performed by decentralized providers. In this model:
  • proofs are validated off-chain by independent validators
  • computation does not touch Ethereum
  • settlement or finalization can anchor to L1
This preserves correctness guarantees while significantly reducing execution cost.

Design Goals

The system is built around a few core principles:
  • ZK should be a primitive, not a specialization
  • users define intent, not cryptographic machinery
  • contracts must remain verifiable, deterministic, and trust-minimized
For developers, this removes the need to build and maintain ZK infrastructure.
For degens, it enables enforceable rules without leaking information or edge.