Skip to main content

Space and Time

Space and Time (SXT) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Space and Time / SXT Chain — an AI/Other | Infra project: a “blockchain for ZK‑proven data” with the Proof of SQL protocol (ZK proofs of the correctness of SQL queries against tamperproof tables) and onchain verification of the results in EVM contracts (per the Tier‑1 whitepaper). Token: SXT (ERC‑20, Ethereum).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a network/platform that allows smart contracts to obtain verifiable results of SQL queries (ZK proof) over large datasets (including indexed onchain data).
  • Who it’s for: developers of smart contracts and applications that need a “query coprocessor” and provable data processing; also positioned as a data layer for AI applications.
  • Why onchain/token: onchain stores the table commitments and verifies the ZK proofs; the SXT token is used for validator staking and for payment/distribution of network fees (Tier‑1).
  • What you can actually touch (Tier‑1): the “Running ZK‑proven Queries” guide (Studio + API/CLI) + the open-source Proof of SQL (sxt-proof-of-sql).

How it works (very briefly)

  1. The user does: submits a query/job (SQL query) against data (onchain or offchain tables) via the SXT infrastructure.
  2. The system does: Indexer nodes load and normalize the data into a relational format; Prover nodes execute the SQL and generate a “Proof of SQL” ZK proof; Validators update the table commitments and provide BFT consensus.
  3. The user gets: the SQL result + a proof that can be verified onchain (for example, in an EVM verifier contract).
  4. Where the blockchain is: table commitments and consensus — in SXT Chain; onchain verification of proofs is possible in smart contracts on the target EVM chains.
  5. Token role: SXT — validator staking/collateral and the economic basis of the network’s fee model (Tier‑1 whitepaper; a votes module is implemented in the token contract).

Quick links: AI thesis fit

Project passport

Field Value
Project name Space and Time
Also known as (aliases) Space and Time DB | SXT Chain
Logo (logo) ../assets/60_space-and-time_logo.svg
Token symbol (ticker) SXT
Category AI/Other | Infra
Primary chain (chain) SXT Chain
Type Appchain
Network status beta
Consensus (consensus) BFT (SXT Chain validators; threshold-signed commitments)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
Token model (token_type) utility (payments + staking + governance)
Max supply 5,000,000,000
Issuance fixed cap
Tokenomics (tokenomics, brief) The ERC‑20 contract mints 5B SXT in the constructor (Etherscan); the whitepaper describes the fee model and validator staking/slashing.
Governance token governance (ERC20Votes) + admin/pauser roles (contract)
Admins/keys AccessControl (DEFAULT_ADMIN_ROLE), PAUSER_ROLE (contract)
Audit yes
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) verifiable SQL queries for AI apps
Use‑case (use_case) ZK-verified SQL coprocessor for smart contracts
DecAI Fit — AI thesis fit 6/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 3 / token_score 2 / evidence_score 3
Last verified 2026-02-10

General project overview

Space and Time positions SXT Chain as a “blockchain for ZK‑proven data”: a network that allows storing tamperproof tables (via cryptographic commitments) and producing ZK‑verifiable results of SQL queries using the Proof of SQL protocol. The key thesis of the whitepaper: smart contracts lack a “query layer”, and ZK‑verifiable SQL queries make data‑rich logic possible without trusting centralized indexers.

The network is described as 3‑layered: Indexer nodes (data ingestion and ETL), Prover nodes (SQL execution + proof generation) and Validators (BFT consensus, updating commitments and threshold signatures). Results can be verified onchain in an EVM verifier contract and passed to a “client contract” via a callback.

Features/modules

  • Proof of SQL: a ZK protocol for proving the correctness of an SQL query against tables.
  • Tamperproof tables via commitments: storing commitments (not the entire data layer) onchain in order to scale tables without bloat.
  • Indexer / Prover / Validator nodes: the network roles for ingestion, proofs and consensus.
  • EVM verification flow: onchain verification of the proof and delivery of the result to a smart contract.

Typical scenarios

  • Scenario 1 (DeFi/contract): a contract requests aggregates/history (for example, risk metrics) → receives a verified result → applies conditions (rates/limits/whitelist) trustlessly.
  • Scenario 2 (cross‑chain application): a contract on one chain verifies the state/events of another chain via ZK‑verified SQL (per the whitepaper description).
  • Scenario 3 (AI app): an AI application gets access to onchain/offchain data and verifiable SQL computations (the whitepaper directly mentions AI apps as consumers).

Getting started (wallet/network)

  • What you need: the documentation/whitepaper + contracts/SDK (see links_*; public repositories may be moved to other org accounts; the Evidence includes the Cantina scope).
  • Network/chain: the SXT token — Ethereum; the product network — SXT Chain (whitepaper).
  • Fees: the whitepaper describes query payments and data insertion fees, distributed between validators and table owners.

Architecture/tech (non‑AI)

  • Components: SXT Chain validators (BFT), table commitments onchain, prover nodes (GPU), indexer nodes, the EVM verifier contract and the relayer flow.
  • Participant roles: validators (stake/slash), provers (proof generation), table owners, developers/clients.
  • Where logic runs: offchain — SQL execution + proof generation; onchain — consensus/commitments in SXT Chain and proof verification on the target EVM chains.
  • Dependencies: EVM chains for onchain verification, GPU infrastructure for provers, data sources (blockchains/offchain providers).

Token/economics (expanded, no forecasts)

  • Token utility: the whitepaper describes SXT as a utility token for validator staking and the network’s fee model (query/data insertion fees and distribution by role).
  • Protocol necessity drivers: validators must stake SXT as collateral to participate in the cryptographic procedures and consensus; slashing is possible.
  • Who pays fees: clients/contracts pay for queries and data insertion (whitepaper).
  • Where fees go: to validators and table owners, with optional delegation of part of the fees to provers (whitepaper).
  • Issuance/burn: the ERC‑20 contract mints 5B SXT (Etherscan); the whitepaper’s issuance additionally describes bootstrap incentives (a time‑limited emission schedule).
  • Security/incentive mechanisms: staking + slashing (downtime, tampering, SLA), a vault model of rewards (whitepaper).
  • Distribution and token issuance schedule: — (not extracted from the excerpts; see whitepaper section 5).
  • Treasury: vault modules are described (security budget vault, table owner rewards vault, etc.; whitepaper).

Governance

  • Who makes decisions: — (not extracted as a “governance process” from the Tier‑1 whitepaper; at the same time, the token contract includes a votes module).
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: the ERC‑20 contract has AccessControl roles (admin/pauser); separate governance contracts for the network are mentioned in the bug bounty scope (Cantina).

Security and incidents

  • Audits: — (there is no Tier‑1 audit report in links_*; see the bug bounty scope on Cantina as a proxy for the existence of audit artifacts).
  • Bug bounty: yes (Cantina competition, completed).
  • Incidents: — (not found).
  • Threat model: validator/prover risks (downtime, tampering), the correctness of commitments and onchain verification; risks of the admin roles of the ERC‑20 contract.

Project status and timeline

  • Current status: the SXT token is active on Ethereum; the documentation publishes beta/release milestones (Changelog).
  • Key releases/milestones: the Changelog in the docs records beta releases and 1.0.x releases.
  • Roadmap: — (links_* shows —).

Ecosystem/integrations

  • Integrations: target EVM chains (onchain verification), data sources (major blockchains), dev documentation (docs) and a security program (Cantina).
  • Partners: —.
  • Where it’s actually used: — (not recorded; a separate overview of integrations is needed).

AI component of the project

  • What is real AI here? the product is not about inference models, but about data and computation for AI applications: the whitepaper and the Etherscan description state that the platform gives AI apps access to onchain/offchain data via verifiable SQL queries.
  • What is truly onchain? table commitments and the validators’ BFT consensus (SXT Chain) + onchain verification of ZK proofs in EVM contracts (per the whitepaper); the SXT token — ERC‑20 on Ethereum.
  • Why is a token needed? per the whitepaper, SXT is needed for validator staking/collateral and the security budget (slashing/rewards); the token contract includes a voting module (votes).
  • Red flags (based on the information found): AI‑washing — medium risk (AI here is a “data consumer”, not an onchain LLM); onchain‑washing — low risk (onchain commitments+verification are the core of the whitepaper’s thesis); token‑washing — medium risk (it needs to be clarified in which currency/how exactly query/insert fees are paid in practice).

DecAI Fit component summary

  • DecAI Fit: 6/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 3
Onchain necessity high 3
Token necessity high 2
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): intent is not needed: there is a Tier‑1 description of a working product as a data layer for AI apps (AI_1=1).
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): AI_0 is used when there is only a roadmap; here there is a whitepaper describing the use‑case and the network components.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the platform gives smart contracts and AI apps the ability to run ZK‑verifiable SQL queries against onchain/offchain data (Proof of SQL).
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper, https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
  • Why sufficient / why not (one line): the Tier‑1 whitepaper and the description on Etherscan record the AI use‑case and purpose.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is a Tier‑1 step‑by‑step guide on how to run ZK‑proven (tamperproof) SQL queries in Space and Time Studio and via the API/CLI.
  • Evidence: Tier‑1 — https://docs.spaceandtime.io/docs/running-tamperproof-queries
  • Why sufficient / why not (one line): this is a reproducible “what you can touch” artifact (a guide + a UI/CLI path).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the whitepaper contains claims about the performance of Proof of SQL, but “AI quality” metrics (of models/agents) are not relevant and are not provided.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): there is a technical description, “Proof of SQL protocol overview” (Verifier/Prover, commitments, ingestion/query flow) + the whitepaper on the SXT Chain architecture.
  • Evidence: Tier‑1 — https://docs.spaceandtime.io/docs/proof-of-sql-overview, https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the Tier‑1 documentation describes the ZK/data architecture and the roles of the components relevant to the AI use‑case.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum (SXT ERC‑20) + SXT Chain (per the whitepaper)
  • Addresses/identifiers: SXT ERC‑20: 0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
  • Evidence: Tier‑1 — https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195, https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the token address and onchain parameters are confirmed; the network and node roles are described in the whitepaper.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: SXT Chain stores table commitments and participates in BFT consensus; the onchain verifier in the EVM checks the ZK proofs and passes the result to the client contract.
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes an onchain architecture beyond the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain commitments/consensus and onchain verification, the “trustless” guarantee of tamperproof tables and verifiable results for smart contracts disappears.
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the trust model is built on onchain commitments + verification.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, SXT (ERC‑20).
  • Evidence: Tier‑1 — https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
  • Why sufficient / why not (one line): the onchain token contract is confirmed by Etherscan.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): the whitepaper describes the fee structure (query/insert) and distribution, but the available Tier‑1 excerpts do not unambiguously establish that fees are paid specifically in the SXT token (by form of payment).
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): we record 0 (conservatively) until an explicit Tier‑1 statement “fees paid in SXT”.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): whitepaper: validators must stake SXT as collateral; slashing is possible for downtime/tampering/failure to perform the cryptographic procedures.
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper
  • Why sufficient / why not (one line): the “SXT Token Utility” section describes staking/slashing.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): the token contract includes ERC20Votes (delegation/votes), which indicates the token’s governance readiness.
  • Evidence: Tier‑1 — https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
  • Why sufficient / why not (one line): the votes implementation is an onchain fact of the contract.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): given staking/slashing and a governance module, we do not draw a strict conclusion about replaceability.
  • Evidence: Tier‑1 — https://spaceandtime.io/whitepaper, https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195
  • Why sufficient / why not (one line): the data is insufficient for a replaceability test.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://spaceandtime.io/whitepaper Tier‑1: the SXT Chain architecture, Proof of SQL, node roles (indexer/prover/validators), the onchain verification flow, token utility (staking/slashing) and the economic model.
Tier‑1 https://etherscan.io/token/0xE6Bfd33F52d82Ccb5b37E16D3dD81f9FFDAbB195 Tier‑1: onchain facts of the SXT token (max supply 5B, contract, votes/roles, verified source).
Tier‑1 https://docs.spaceandtime.io/changelog Tier‑1: the public changelog of releases/beta and a mention of the publication of Proof of SQL on GitHub (as a development artifact).
Tier‑1 https://docs.spaceandtime.io/docs/running-tamperproof-queries Tier‑1: step‑by‑step guide (Studio + API/CLI) for running tamperproof (ZK‑proven) SQL queries (AI_2 demo/quickstart).
Tier‑1 https://docs.spaceandtime.io/docs/proof-of-sql-overview Tier‑1: Proof of SQL protocol overview (Verifier/Prover, commitments, ingestion/query flow).
Tier‑1 https://docs.spaceandtime.io/docs/sxtcli Tier‑1: installation and use of the CLI (developer onboarding).
Tier‑1 https://github.com/spaceandtimefdn/sxt-proof-of-sql Tier‑1: open-source Proof of SQL (README, examples, benchmarks, supported SQL).
Tier‑1 https://cantina.xyz/competitions/3cc30b66-1cba-4044-968f-a0817cd7bf83 Tier‑1: an active security program/competition specifying the repo scope and components (node/contracts/proof‑of‑sql/token).
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top