Inserting Verified Data

Although query execution by Prover nodes requires zero knowledge proofs (ZK proofs) generated by a single GPU, inserts are executed across the validator set with consensus proof. SXT Chain) validators are responsible for witnessing all insertions into the network and updating tamperproof commitments for each table. These commitments act as cryptographic digests of a table’s contents and are threshold-signed by a quorum of validators under BFT consensus.

Lifecycle of a tamperproof insert:

Insert Submitted: A client (app, indexer, or gateway) submits an insert transaction to an SXT Chain RPC.
Signature Check: Validators verify any included EDDSA/ED25519 signatures (for signed inserts) or zkTLS proofs (for HTTPS-originated data).
Redundancy Matching: For chain-indexed tables, validators wait for redundant inserts from multiple Indexers and compare proposed rows.
Quorum Reached: Once a quorum of identical rows is reached, the validators threshold-sign an updated commitment hash.
Commitment Finalized: The new commitment is anchored onchain and becomes the source of truth for future query proofs.

Each insert can be traced back to its origin via signature, user wallet, insert method, and the cryptographic evidence associated with its ingestion. This ensures a provable chain-of-custody for all data in the system. Threshold-signed data commitments (one per table) across the validator set serve as proof of attestation of the underlying data by the validators, with these signatures verifiable in the EVM along (with the ZK-proof itself + the query result returned onchain to be verified).

In summary,

Data commitments threshold-signed by the validators ensures underlying tables are tamperproof
The ZK-proof proves the SQL computations executed on the data
The final query result can be verified in the EVM using the signed commitments + associated ZK-proof of SQL.

To learn more, check out our Validator Github repo.

To support diverse data sources and use cases, SXT Chain supports multiple verification pathways before updating table commitments:

Signed ECDSA/ED25519 Inserts (Gas-Sponsored Client Data)

For consumer applications like games or social platforms, data can be inserted by having the end-user sign a message (ECDSA or ED25519) representing the data payload (e.g., user_id=0xabc... action="liked" post_id=123). The application then submits the insert to SXT Chain, sponsoring the gas cost on the user's behalf. Validators verify the user’s signature before including the insert and updating the table commitment.
This method is used by dapps where the end user cryptographically signs the data they are contributing (e.g., social apps, games, wallets).

The user signs a payload (e.g., user_id=0xabc... action="liked" post_id=123) using their ECDSA (Ethereum-compatible) or ED25519 keypair.
The application submits the signed message to the SXT Chain insert endpoint or an onchain insert contract.
The SXT validator set verifies the signature and inserts the payload if the signature is valid.
The table’s cryptographic commitment is updated via BFT consensus.

This method enables gasless UX for end users (apps can pay gas) while preserving end-to-end verifiability of who submitted the data.

Redundant Inserts via Indexer Quorum (Chain-Indexed Data)

For onchain data from networks like Ethereum, Base, etc. a decentralized network of Indexer nodes monitors blockchain activity and transforms event logs, transactions, and state diffs into SQL-compatible rows. These Indexers independently submit proposed inserts to SXT Chain for each data slice.
The validator set then compares incoming inserts from multiple Indexers. If a quorum (e.g., 2-of-3) submit identical rows for a given block height and table, SXT validators threshold-sign a new cryptographic commitment for the table and finalize the insert.

This process guarantees trustless, consensus-based indexing of any chain into a tamperproof SQL format.

A decentralized network of Indexer nodes continuously monitors the source chain using light clients and RPCs.
Each Indexer transforms chain data (blocks, events, txs, balances) into SQL-ready rows and submits the same inserts to SXT Chain.
Validators compare insert proposals across Indexers. If a quorum (e.g., 2-of-3) submit matching rows, validators threshold-sign and finalize the insert.

This mechanism enables tamperproof, trustless indexing of any blockchain into relational format, ensuring that even the most data-heavy protocols (e.g., DEXs, lending markets) can be queried verifiably.

zkTLS Verifications on Insert (End-User Verified Data)

Applications that collect user-consented offchain data (e.g., TradFi accounts, GitHub activity, browser metadata) can insert data into Space and Time using zero-knowledge TLS (zkTLS) proofs. These proofs ensure that data presented by the app was retrieved from a verified HTTPS source (e.g., api.tradfi.com) and that the user explicitly opted in via wallet signature. The insert transaction includes both the payload and the zkTLS proof, which is verified by SXT Chain validators before updating the table’s commitment.

The user signs a payload (e.g., user_id=0xabc... action="liked" post_id=123) using their ECDSA (Ethereum-compatible) or ED25519 keypair.
The application submits the signed message to the SXT Chain insert endpoint or an onchain insert contract.
The SXT validator set verifies the signature and inserts the payload if the signature is valid.
The table’s cryptographic commitment is updated via BFT consensus

This method also enables gasless UX for end users (apps can pay gas) while preserving end-to-end verifiability of who submitted the data.

All these models converge on a single principle: data must be cryptographically proven before it is committed.