Space and Time is a decentralized data warehouse where all inserted rows are verifiably tamperproof. Applications can write data into relational tables using standard API calls or direct blockchain transactions, depending on their trust model and UX requirements. Every insertion is verified by the SXT validator set and results in a table commitments update that cryptographically reflects the new state of the table.

Types of Inserts

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.

Insert Transactional Format

Each insert is submitted as a signed extrinsic to Space and Time (built on Substrate).
The transaction payload contains:

• Target table ID
• Insert row data (as a JSON or binary blob, schema-aligned)
• Optional metadata (e.g., insert source, timestamp, zkTLS proof hash)
• Signature (ECDSA or ED25519)
• Public key (or wallet address) of the signer

Upon receiving an insert extrinsic:

• Validators verify the signature and validate schema conformity
• If valid, the insert is committed to the tamperproof table
• The cryptographic table commitment scheme is updated and threshold-signed by the validator set
• The new commitment is pinned to SXT Chain's onchain state.

Insert UX

When inserting data through an App or Dapp, you can choose between:

• Direct blockchain inserts: by submitting extrinsics via Polkadot JS, SDKs, or RPCs.
• Offchain API inserts: via REST or gRPC endpoints that relay data through an SXT-backed gateway which submits extrinsics on their behalf. Coming Soon!
• Block Explorers: Testnet or Mainnet

All insert types result in cryptographically verifiable rows, making SXT Chain the foundation for dapps that depend on trusted data writes—whether onchain, offchain, or user-generated.