> ## Documentation Index
> Fetch the complete documentation index at: https://developer.usewarp.net/llms.txt
> Use this file to discover all available pages before exploring further.
# Get Started
> Zero-Knowledge Proofs enable private, verifiable smart contracts with off-chain ZK validation.
## **Building ZK-Proofs with Warp**
***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.***
Write, compile & deploy ZK-Proofs on our platform. [Get Started](https://platform.usewarp.net)
*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.*