ZK Validity
Zero-knowledge validity is one of the core pillars of ZKAP. It ensures that every encrypted action submitted through the protocol is correct, authorized, and well-formed, without revealing anything about the content or the sender.
This section explains what “validity” means in ZKAP, how zero-knowledge proofs enforce it, and why this mechanism enables anonymous execution at scale.
1. The challenge: validating actions without seeing them
In traditional blockchains:
contracts inspect calldata
contracts verify signatures
contracts check parameters
nodes validate sender identity and nonce
This is impossible when the payload is encrypted.
ZKAP solves this with zero-knowledge proofs, allowing the protocol to validate requests without exposing any inputs.
2. What “validity” means inside ZKAP
A ZKAP action is considered valid if:
The identity used in the proof is correctly formed
The payload structure is correct
The commitment matches the encrypted payload
The nullifier is derived properly
The action is still within the expiry window
The request is not a replay
All of these checks are performed inside the ZK circuit, not on the blockchain.
The blockchain only sees a yes/no proof result.
3. The zero-knowledge proof enforces correctness
The proof guarantees:
the payload is well-formed
all constraints are satisfied
no invalid or manipulated data is included
the sender’s identity is valid, but never revealed
the nullifier is generated correctly
expiry rules are respected
Nothing about amounts, tokens, routing, or parameters becomes public.
4. Validity without identity
Normally, identity is required to validate actions:
Ethereum uses signatures from EOAs
Cosmos uses account sequences
Solana uses signer accounts
ZKAP eliminates this requirement.
Instead of showing who sent the action, ZKAP shows:
“I am allowed to perform this action”
“This payload is valid”
“I followed the protocol rules”
But never reveals the sender’s identity or signature.
5. Public and private inputs in ZKAP proofs
The proof contains:
Private inputs (hidden)
ephemeral identity
payload hash
nonce
expiry
constraints / parameters
Public outputs (visible)
nullifier
commitment root
These public outputs allow the blockchain to do verification without knowing anything about the private inputs.
6. Why the blockchain can trust the proof
The blockchain verifies:
the proof matches the circuit
the circuit enforces correct rules
the nullifier isn't reused
the expiry is still valid
Because zero-knowledge proofs are cryptographically binding, the validator contract can trust the proof fully without inspecting any plaintext data.
This is what allows ZKAP to maintain:
privacy
correctness
stateless execution
anonymous submitters
all at the same time.
7. Benefits of ZK-based validity
No need for signatures
Proofs replace signature authentication.
No visible calldata
The proof verifies structure without showing it.
No replay attacks
The nullifier is publicly checkable.
No identity leakage
Proofs hide all identity and metadata.
No need for application-specific circuits
ZKAP circuits are generic and reusable.
No trust assumptions
The contract verifies everything independently.
8. Example: validating a private swap
The proof asserts:
action type = swap
amount > 0
expiry > current block
nullifier is unique
commitment matches encrypted payload
routing constraints are valid
But never reveals:
which token
how much
which pool
who is swapping
The application decrypts the payload only after the proof succeeds.
Last updated