A privacy-first identity and verifiable data stack that proves what is true without exposing what is private.

ZAKAPI Technology – How It Works

Zakapi’s platform is powered by a fusion of cryptography, SQL-aware non-interactive proofs, open standards, and robust engineering. This section peels back the layers to show how Zakapi delivers trust without data exposure and performance without compromising correctness.

Zero-knowledge proof engine

At the core is our zero-knowledge proof engine - the component that proves both credential facts and SQL-style policies without revealing the underlying data or tables. It is inspired by recent research on efficient non-interactive proofs for arbitrary SQL query verification and combines that with identity-focused primitives.

SQL-aware circuits and database commitments

• Committed datasets
• Before any query is proven, the data owner commits their database or logical view using cryptographic commitments. That commitment is public and can be pinned to a registry, blockchain, or internal trust store. Every proof produced later is explicitly tied to that commitment, so verifiers can check that queries were run on the correct, up-to-date dataset rather than a stale or manipulated copy.

PLONKish, Halo2-style circuits

• We encode SQL semantics into PLONKish circuits similar to those used in Halo2: range checks, filters, joins, group-by, sort, and aggregation are each expressed through custom gates optimized for low-degree constraints and good composability. Rather than treating a query as a giant generic circuit, we build on specialized gates for typical database operations, which keeps proving time and memory usage practical even for analytical workloads.

Custom gates for database operators

• The proof engine implements families of gates and argument systems tailored to SQL-like workloads:
• Range check gates for predicates such as age greater than or income less than a threshold.
• Sort and permutation gates to prove that result sets are correctly ordered and that no rows were dropped or duplicated.
• Group-by and aggregation gates to handle sums, counts, averages, and similar operations over groups of rows.
• Join gates for primary-key and foreign-key joins, using sorted keys and permutation arguments to prove that each joined row corresponds to real, matching records in the committed tables.

IPA-based polynomial commitments

• Zakapi uses inner-product argument style polynomial commitments, in the same family as Halo2, to keep proofs succinct and verification efficient while avoiding per-circuit trusted setup. Universal parameters can be generated once for a parameter range and reused across many SQL circuits and workloads.

Non-interactive proofs and reusability

The engine produces non-interactive proofs that can be:

• Verified offline by any number of parties, including regulators and auditors.
• Cached and replayed later to demonstrate that a particular query or policy check was run correctly at a given time.
• Embedded into higher-level identity proofs, so a single object can attest that both user attributes and backend SQL checks were satisfied, without interaction with the original database at verification time.

This non-interactive model avoids verifier round trips during query execution, fits naturally into asynchronous workflows, and makes it straightforward to give third parties independent verification capabilities.

Multi-layer proof composition

Zakapi combines two layers in one engine:

• Identity layer proofs - that an issuer really signed a credential for a subject and that the holder controls that credential.
• Data layer proofs - that a given SQL-style statement on a committed dataset evaluated to a certain result, such as "this person’s KYC status is passed" or "this account has no matches against sanctions list X as of date Y".

Using recursive and composite proof techniques, we can bundle these into one compact, non-interactive proof that:

• Hides the underlying rows and attributes.
• Reveals only the required predicates and result bits.
• Can be verified with a single check by the relying party.

Circuit quality and security

Because a zero-knowledge proof is only as strong as its circuit and constraints, we treat circuit engineering as a first-class discipline:

• Structured circuit libraries for common patterns such as range checks, joins, and group-by, rather than ad hoc encodings.
• Extensive unit tests and test vectors to ensure circuits accept valid statements and reject invalid ones.
• Static and symbolic analysis on constraint systems to catch under-constrained or malformed circuits.
• Fuzzing strategies for critical circuits such as age checks and risk-score thresholds to guard against edge cases.
• Third-party cryptography reviews and audits of core circuits and libraries, with public reports where possible.

Self-sovereign identity stack

While the SQL-aware proof engine handles verifiable queries and policy checks, Zakapi’s identity stack ensures that all of this connects cleanly to real-world subjects, issuers, and verifiers in a standards-compliant way.

W3C Verifiable Credentials (VC) 2.0

Every credential issued through Zakapi conforms to the W3C VC data model:

• An issuer (often identified by a DID or domain-based identifier).
• A subject or holder.
• A set of claims, such as birthDate, KYCStatus, licenseType, or role.
• A cryptographic proof: a digital signature or selective-disclosure capable proof.

By aligning to VC 2.0, Zakapi can act as a wallet and verification layer inside larger national or sector-specific ecosystems, including EU-style digital identity wallets and other SSI deployments.

Decentralized identifiers (DIDs) and pairwise privacy

Zakapi uses DIDs for people, organizations, and services:

• did:key and did:web for simple deployment and domain-rooted trust.
• Support for ecosystem-specific methods like did:ebsi or did:ion where required.
• Pairwise pseudonymous DIDs per verifier by default, which prevents correlation of users across services based solely on identifiers.

DIDComm and Aries-style agents

For live interactions, Zakapi supports DIDComm v2 patterns, drawing on the Hyperledger Aries protocols:

• Encrypted and authenticated messaging between wallet and verifier.
• Credential issuance, presentation, and revocation flows that can run interactively when needed.
• Interoperability with existing Aries agents and wallets based on the same open protocols.

OpenID Connect for verifiable credentials

Zakapi implements OIDC4VCI and OIDC4VP:

• Issuers can expose OIDC endpoints to deliver credentials to wallets using familiar OAuth and OpenID Connect flows.
• Verifiers can plug verifiable presentations into their existing OIDC-based login and onboarding flows, such as "Log in with Zakapi" or "Prove KYC".
• Selective disclosure and zero-knowledge predicates can be expressed within these flows using SD-JWT, BBS+ proofs, or linked ZK proofs, depending on the credential type.

Selective disclosure and predicate proofs

To minimize data exposure, Zakapi combines:

• BBS+ signatures for JSON-LD credentials, allowing holders to reveal only selected attributes while still proving issuer signatures.
• SD-JWT for JWT-based credentials, so holders can release just the claims that a verifier has requested.
• ZK predicate proofs on top of attributes, such as "age greater than 18" or "riskScore below threshold", without revealing the attribute value itself.

When attributes depend on SQL or complex logic over a database, those predicates are backed by SQL-aware circuits compiled into the proof engine, so the verifier knows the check was executed correctly on the committed dataset.

Architecture and deployment

Zakapi is built as a modular, cloud-native system that you can deploy as a whole platform or as individual components.

Issuer service

• Connects to authoritative data sources such as national ID registries, KYC provider results, or internal customer databases.
• Issues verifiable credentials that represent stable facts like identity, KYC status, license status, or account attributes.
• Registers and maintains commitments to relevant datasets when those facts depend on SQL-style checks, so future proofs can reference a specific committed snapshot.
• Uses HSMs or secure key vaults for signing keys and supports OIDC4VCI for issuance to wallets.

Verifier service and SQL-proof gateway

• Exposes APIs and SDKs for relying parties to request proofs, ranging from simple age checks to more complex policy checks over backend data.
• For identity-only checks, verifies cryptographic signatures and selective-disclosure proofs.
• For data-backed policies, constructs or selects SQL-style statements and their associated circuits, then delegates proof generation to the proof engine against the committed dataset.
• Returns compact, non-interactive proofs and clear boolean or structured results, so application code only deals with high-level decisions, not cryptographic details.

Orchestration and workflow

• Uses workflow engines for multi-step flows such as initial KYC, credential issuance, and subsequent reuse.
• Encodes business rules like when to refresh a proof, how often to rotate dataset commitments, or which queries must be rerun for regulatory changes.
• Supports asynchronous verification use cases such as batch checks and scheduled re-validation of risk or eligibility conditions.

Audit log and analytics

• Stores cryptographically hashed records of proof events, linking queries, commitments, and outcomes without exposing underlying data.
• Optionally anchors proof summaries or log hashes to an internal ledger or blockchain for immutability.
• Offers dashboards and export tools for compliance teams, making it easy to demonstrate that specific SQL-style checks and identity verifications were performed at specific times with specific parameters.

Infrastructure and DevOps

• Written primarily in Rust for high performance and memory safety.
• Containerized and ready for Kubernetes, with support for on-premises, cloud, and hybrid deployments.
• All internal traffic is encrypted, and services are designed to hold minimal personal data, pushing sensitive state to user wallets and committed databases under customer control.
• Integrates with Prometheus, Grafana, and common logging stacks so your existing operations teams can monitor and manage Zakapi like any other critical service.