SDK Overview
The ZKAP SDK is the primary toolkit for developers integrating anonymous, encrypted, zero-knowledge–validated actions into their applications. It provides high-level functions for identity generation, payload encryption, proof generation, frame construction, and interaction with the ZKAP Validator.
This section gives an overview of the SDK’s architecture, capabilities, and how each component fits into the ZKAP workflow.
1. What the SDK Does
The ZKAP SDK is responsible for:
generating ephemeral anonymous identities
encoding and encrypting payloads
generating zero-knowledge proofs
constructing ZKAP Frames
submitting frames to the validator
listening to anonymous events
decrypting the payloads for applications
In short, the SDK acts as the client-side engine for ZKAP.
The blockchain only verifies proofs and emits encrypted events; the SDK handles everything else.
2. Key SDK Modules
The SDK is divided into five primary modules:
2.1 Identity Module
Creates ephemeral, unlinkable ZKAP identities.
Functions include:
generateIdentity()deriveNullifier()createSessionHash()
2.2 Payload Module
Responsible for:
serializing payloads
encrypting using AES-GCM or ChaCha20-Poly1305
validating structure before proof generation
Functions include:
encryptPayload()decryptPayload()
2.3 ZK Proof Module
Handles witness generation and proof construction.
Functions include:
generateProof()verifyProof()(optional for local testing)
Supports:
Groth16
Plonk
Halo2
STARKs (depending on environment)
2.4 Frame Builder Module
Constructs a valid ZKAP Frame containing:
zk proof
commitment root
encrypted payload
nullifier
session hash
expiry block
Primary function:
buildFrame()
2.5 Validator Interaction Module
Enables submitting frames and listening for events.
Functions:
submitFrame()onAnonymousAction()decodeEvent()
3. End-to-End SDK Workflow
A typical developer workflow using the SDK looks like this:
Step 1 — Generate identity Step 2 — Build raw payload Step 3 — Encrypt payload Step 4 — Generate zero-knowledge proof Step 5 — Build ZKAP Frame Step 6 — Submit frame to validator Step 7 — Listen for AnonymousAction event Step 8 — Decrypt and execute logic
The SDK handles each step with simple functions.
Example (conceptual):
const id = generateIdentity(); const ciphertext = encryptPayload(payload, key); const proof = await generateProof(id, ciphertext); const frame = buildFrame({ proof, ciphertext, id }); await submitFrame(frame);
4. SDK Environment Compatibility
4.1 Browser
• WASM proof generation supported • Good for user-facing wallets or interfaces
4.2 Node.js
• Full proof generation • Recommended for backend systems or agents
4.3 Serverless
• Frame building works • Proof generation may require custom build
4.4 Agent frameworks
• No private keys needed • Can generate identities on the fly • Execution stays completely private
5. Supported Cryptographic Backends
The SDK integrates with multiple proof systems:
SnarkJS (Groth16)
Plonk
Halo2 WASM
Stark-based compilers
Developers can plug in their own backend by implementing the proof interface.
Encryption backends supported:
AES-GCM
ChaCha20-Poly1305
WebCrypto (browser)
Node crypto module (server)
6. Error Handling & Safety Guarantees
The SDK provides robust error types for debugging:
invalid payload format
proof generation errors
incorrect encryption key
replay attempt (duplicate nullifier)
expiry validation failure
unsupported proof backend
All unsafe operations include detailed logs and type-checking at compile time (TypeScript).
7. Who Should Use the SDK?
The SDK is designed for:
DEX developers
wallet builders
agent frameworks
automation tools
RFQ systems
cross-chain routers
governance systems
backend services
If your app needs to perform actions privately while ensuring correctness, the SDK is the main integration point.
Last updated