The System Behind Sub-Second Proofs

ZK Coprocessor (Query Execution Layer)

Structured queries are executed within a custom zero-knowledge virtual machine (zkVM). Each operation generates a ZK proof that binds the query input, logic path, and output into a verifiable computation unit.

Responsible for:

• Parsing SQL or GraphQL into deterministic execution plans

• Executing computation in a verifiable zero-knowledge context

• Generating compact ZK proofs linked to query inputs and results

• Ensuring that logic paths are consistent and tamper-proof

Indexing Runtime (Data Abstraction Layer)

Multi-chain data from Ethereum, Solana, Aptos, and others is normalized into a shared schema layer. Events, state, and transactions are abstracted into a unified query surface across chains.

Responsible for:

• Ingesting events, state, and transaction data from supported chains

• Mapping native formats (e.g. Ethereum storage, Solana logs) to a shared model

• Maintaining real-time index freshness for low-latency access

• Enabling chain-agnostic queries without per-chain logic rewriting

Verifier Runtime (Result Validation Layer)

Proofs returned with query results can be independently verified by smart contracts or offchain systems. This layer operates without dependency on the Flux network, suitable for audit trails or contract-based pre-checks.

Responsible for:

• Providing APIs for proof integrity checks

• Supporting both onchain and offchain proof validation

• Enabling contracts to reject unverifiable data inputs

• Operating as a stateless, decentralized verification layer

Commit Layer (State Registry)

Results and verification metadata can be committed to a state ledger for future referencing. Commitments store hash paths and context metadata, ensuring results remain immutable and traceable over time.

Responsible for:

• Storing proof commitments, query hashes, and context metadata

• Creating referenceable snapshots for downstream use

• Ensuring that results cannot be modified or re-interpreted post-submission

• Linking data provenance to public ledger entries

Capsule Registry (Modular Query Logic)

Reusable query logic can be packaged into Capsules and registered. Each Capsule defines input schema, execution logic, proof configuration, and invocation cost model, enabling ecosystem-wide composability.

Responsible for:

• Hosting declarative Capsules with schema, logic, and fee models

• Handling permissioning and access controls

• Tracking usage metrics and routing rewards

• Enabling modular reuse of verifiable query logic across apps and agents