Space and Time (SXT)

Space and Time: How SXT Turns SQL Queries Into Verifiable Blockchain Inputs

Space and Time is building a data layer for smart contracts: it indexes blockchain and offchain information into committed tables, executes SQL away from the chain, and returns zero-knowledge proofs that let EVM contracts verify the result. SXT pays for network activity and helps secure the validator set, but the system still depends on accurate data ingestion, prover availability, validator coordination, and continued developer demand.

A database layer for smart contracts

Space and Time, also referred to as SXT Chain, is a permissionless blockchain designed to store and verify structured data rather than compete as a general-purpose execution chain. Developers can create relational tables, insert blockchain or application data, and query those tables using SQL. The project’s intended users include DeFi protocols, tokenized-asset systems, analytics applications, dashboards, and smart contracts that need historical or cross-chain information without storing all of it directly onchain.

The system separates data storage and heavy computation from onchain verification. Full table contents are held offchain, while cryptographic commitments representing table state are recorded and updated through the SXT Chain validator process. This design is meant to provide the query flexibility of a database while giving smart contracts a way to check that the underlying dataset and computation were not altered after the fact.

How Proof of SQL works

The core mechanism is Proof of SQL. A client submits a SQL query or a precompiled query plan. A prover node executes the query offchain against committed tables and generates a zero-knowledge proof covering both the correctness of the SQL computation and the integrity of the data commitment used by that computation. An EVM contract can then verify the proof without loading or recomputing the complete dataset.

For smart-contract use, the QueryRouter contract receives the query plan, payment, callback target, and related parameters. After offchain execution and proof generation, a designated executor returns the result through the callback path. The receiving contract must check that the callback came from the authorized executor and that the query identifier matches a request it actually created. This means the cryptographic proof is one part of the integration; application-level callback validation remains necessary.

Tables, validators, and data dependencies

A table begins with a signed CREATE TABLE transaction that defines its schema and owner. Subsequent inserts, updates, or deletions change the table commitment, which validators collectively verify and publish through threshold consensus. The public node repository describes validators as witnessing data inserts, reaching Byzantine Fault Tolerant consensus, and agreeing on the latest commitment for each table.

This architecture does not make the original data source automatically true. Indexed blockchain information depends on indexers, source-chain RPC access, decoding logic, and the network’s procedures for accepting updates. Offchain datasets introduce additional assumptions about the party supplying the data and the evidence supporting it. Proof of SQL can show that a query was correctly run against a committed table; it cannot, by itself, establish that every external input was accurate when first submitted.

What SXT is used for

SXT has several stated protocol roles. The project describes it as the payment asset for creating or updating tables, running queries, and using verifiable compute. Its documentation also describes SXT-denominated gas or compute credits on SXT Chain, with fees intended to flow to validators and provers that process data and return verified results. The Ethereum token address published by the project is 0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195, and the project’s token announcement lists a maximum supply of 5 billion SXT.

Staking is the other major role. Validators are expected to stake SXT as economic collateral for consensus and commitment updates, while holders can delegate to validators without operating infrastructure. The documentation describes a seven-day cooldown for undelegation and says validators may participate in governance. It does not, in the material reviewed for this article, explain a complete public voting framework, quorum rules, or the precise authority for upgrades, so governance should be treated as an area requiring further verification rather than as a fully documented feature.

Who may use it

The clearest target users are developers that need verifiable access to historical, cross-chain, or application-specific data. A lending protocol could query collateral or activity histories; an application could combine indexed blockchain events with its own database; and a smart contract could use a proven result for rewards, settlement, compliance, or collateral logic. The project also presents data APIs and application dashboards as supported outputs, so not every user needs to interact with SXT Chain through a smart contract.

The practical dependency is integration complexity. Developers must prepare compatible tables or query plans, fund query payments, handle asynchronous callbacks, and rely on the relevant indexers, validators, provers, verifier contracts, and source-chain data. Public repositories show active codebases for the node, Proof of SQL, token, and staking-related contracts, but repository activity is evidence of development infrastructure, not proof of broad production adoption or economic sustainability.

What remains unproven

Space and Time’s central proposition is technically specific: prove database-backed SQL results rather than asking every smart contract to repeat expensive data processing. The main questions for independent evaluation are operational. They include the size and independence of the validator and prover sets, the availability and redundancy of offchain table data, the accuracy of indexer pipelines, the performance of verifier and router contracts under stress, and the amount of fee-generating usage that exists outside project demonstrations.

SXT therefore represents both a utility token and a claim on future network coordination. Its value within the system depends on real query and data-insertion demand, sufficient staking participation, functioning cryptographic infrastructure, and governance that can manage upgrades without weakening verification assumptions. Those conditions are distinct from the existence of an ERC-20 contract or the publication of open-source components.

Key takeaways

• Space and Time is designed as a verifiable data and query layer for EVM applications, not simply as a conventional smart-contract platform.
• Proof of SQL separates offchain SQL execution from onchain proof verification.
• Table commitments protect against undetected changes to committed data, but they do not guarantee that external data was originally accurate.
• SXT is intended to pay for table operations, queries, and verifiable compute, while also supporting validator staking and delegation.
• Developers must manage practical dependencies including indexers, provers, validators, callback security, source-chain data, and query funding.
• The public material reviewed describes validator governance participation but does not fully document voting rules or upgrade control.

Risks and open questions

• Data correctness depends on indexers, source-chain RPC providers, table owners, and procedures for accepting offchain inputs.
• Validator or prover concentration could weaken availability, censorship resistance, or the economic security assumed by the design.
• The system relies on asynchronous router callbacks and contract-side validation; integration mistakes can create application-level vulnerabilities.
• Offchain table storage and prover availability remain practical dependencies even when commitments and proofs are verified onchain.
• The project’s public documentation does not fully specify governance voting mechanics, upgrade authority, or all validator-set controls.
• Token supply unlocks and staking emissions may affect economic incentives independently of technical usage.