Is Space and Time Quantum Safe?

Is Space and Time quantum safe? It is a question gaining urgency as cryptographically relevant quantum computers move from theoretical risk to engineering roadmap. Space and Time (SXT) is a decentralised data warehouse that uses a novel cryptographic proof system called Proof of SQL to verify query results on-chain. Like virtually every production blockchain project, its wallet-layer and signature infrastructure relies on elliptic-curve schemes that a sufficiently powerful quantum computer could break. This article breaks down exactly what cryptography SXT uses, where the exposure sits, what migration paths exist, and what "quantum-safe" would actually require.

What Space and Time Actually Is — and Why It Matters for This Question

Space and Time is a decentralised SQL query layer designed to serve verifiable data to smart contracts and off-chain applications. Its headline innovation is Proof of SQL, a zero-knowledge proof construction that lets a prover demonstrate to a verifier that a SQL query was executed correctly over a committed dataset, without revealing the underlying data.

That proof system sits on top of a broader infrastructure that includes:

• On-chain settlement via Ethereum and other EVM-compatible chains.
• Node operator staking secured through standard EVM wallets.
• The SXT token, which uses standard ERC-20 mechanics and is held in Ethereum-compatible wallets secured by ECDSA.
• Off-chain data commitments anchored to on-chain hashes.

The quantum-safety question therefore has two separate layers worth examining independently: the proof system layer (Proof of SQL, commitments, ZK circuits) and the wallet/signature layer (how keys are generated, how transactions are signed, and how node operators authenticate).

---

The Cryptography Behind Proof of SQL

Proof of SQL is built on a polynomial commitment scheme using elliptic-curve groups, specifically a variant of the Hyrax-style inner-product argument or a similar structured-reference-string (SRS) based construction over BLS12-381 or comparable pairing-friendly curves, combined with Pedersen-style vector commitments.

Elliptic-Curve Commitments and the Discrete Log Problem

The security of these commitment schemes reduces to the elliptic-curve discrete logarithm problem (ECDLP). Classical computers cannot solve ECDLP in polynomial time, but a quantum computer running Shor's algorithm can. For a 256-bit elliptic curve, a cryptographically relevant quantum computer (CRQC) is estimated to require on the order of a few thousand logical qubits with full error correction to break ECDLP, down to practical attack timelines measured in hours rather than years.

This means that if a CRQC exists and the proof system's commitment parameters are exposed, an adversary could:

1. Forge proofs, making false SQL query results appear valid.
2. Reconstruct committed values from public commitments, leaking private data.

Hash-Based Components

Proof of SQL also uses SHA-256 or Keccak-256 in its Fiat-Shamir transcript to make interactive proofs non-interactive. Hash functions are generally considered quantum-resistant under Grover's algorithm, which provides only a quadratic speedup. A 256-bit hash retains roughly 128 bits of post-quantum security — adequate under current NIST guidelines. So the Fiat-Shamir component is not the weak link.

Summary of the Proof Layer

---

The Wallet and Signature Layer: Where SXT Inherits Ethereum's Exposure

Space and Time's token and staking infrastructure sits on Ethereum. This means every SXT holder, node operator, and smart contract interaction is secured by ECDSA on secp256k1 — the same signature scheme used across virtually all EVM chains.

How ECDSA Breaks Under a Quantum Attack

ECDSA security relies on the intractability of ECDLP. The attack model relevant for blockchain is specifically the "harvest now, decrypt later" scenario: a quantum-capable adversary records broadcast transactions today, and once a CRQC is available, extracts private keys from public keys that appeared in those signed transactions.

For Ethereum specifically, the vulnerability window is:

• Exposed public keys: Every address that has broadcast at least one transaction has its public key on-chain. From that public key, Shor's algorithm derives the private key.
• Unspent, never-transacted addresses: These expose only the hash of the public key (the Ethereum address). A CRQC cannot reverse a hash efficiently, so these are safer — until the owner transacts.
• Time-to-finality gap: Even in a post-Q-day world, an attacker would need to complete the Shor computation faster than a transaction is confirmed. On Ethereum, that window is 12 seconds per slot. Quantum hardware timelines suggest early CRQCs may require hours per key derivation, giving some grace period — but hardware improvement curves are not predictable.

EdDSA and BLS in Node Infrastructure

Node operators in decentralised infrastructure protocols frequently sign messages using EdDSA (Ed25519) for peer-to-peer authentication and BLS12-381 for aggregate signatures and staking proofs. Both are elliptic-curve constructions and both are broken by Shor's algorithm. Any node operator whose signing key is exposed on-chain or in a public gossip layer faces the same harvest-now-decrypt-later risk.

---

Does Space and Time Have a Quantum Migration Plan?

As of the time of writing, Space and Time has not published a formal post-quantum cryptography (PQC) migration roadmap. This is not unusual. The majority of blockchain-layer-1 and layer-2 infrastructure projects have not formalised PQC plans, largely because:

1. NIST only finalised its first PQC standards in 2024 (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium and FALCON for digital signatures, SPHINCS+ as a hash-based fallback).
2. PQC algorithms carry significant overhead — lattice-based signatures like CRYSTALS-Dilithium produce signatures roughly 10-40x larger than ECDSA equivalents, with performance trade-offs that complicate on-chain deployment.
3. Ethereum itself has not migrated, meaning EVM-dependent projects are effectively waiting on upstream infrastructure.

What a Migration Would Require for SXT

A genuine post-quantum upgrade for Space and Time would need to address three separate domains:

1. Proof system rebuild: Replace elliptic-curve polynomial commitment schemes with quantum-resistant alternatives. Candidates include lattice-based commitments (e.g., using Module-LWE hardness assumptions) or hash-based commitments (e.g., based on Merkle trees with SHA-3). Both exist in research literature but are significantly less mature in production ZK contexts than EC-based constructions.

1. Signature scheme replacement: Migrate node signing and user-facing wallet signing from ECDSA/EdDSA to CRYSTALS-Dilithium, FALCON, or SPHINCS+. This requires a coordinated hard fork or protocol upgrade and affects wallets, staking contracts, and node software simultaneously.

1. Smart contract layer: Ethereum smart contracts that verify signatures on-chain (e.g., for staking or governance) would need updated verifier logic. Until Ethereum itself adopts a PQC-safe address standard, any EVM-resident logic remains exposed at the base layer.

---

How Lattice-Based Post-Quantum Wallets Differ

The practical alternative to ECDSA-based wallet security is a lattice-based cryptographic scheme, specifically those built on the hardness of the Learning With Errors (LWE) or Module-LWE problem. These problems are believed to be resistant to both classical and quantum attacks, and they underpin the NIST-standardised CRYSTALS-Dilithium and CRYSTALS-Kyber schemes.

What Makes Lattice Schemes Quantum-Resistant?

Lattice problems involve finding short vectors in high-dimensional mathematical grids (lattices). The best known quantum algorithms, including Shor's and variants of the hidden subgroup problem algorithm, provide no meaningful speedup against lattice problems. The security reduction is to worst-case lattice problems, giving strong theoretical foundations.

Key properties of lattice-based wallet schemes:

• Key generation: Based on random lattice sampling rather than scalar multiplication on an elliptic curve.
• Signing: Produces a signature derived from a lattice trapdoor, not from ECDLP.
• Verification: Checks a norm condition on the signature vector rather than a curve equation.
• Signature size trade-off: CRYSTALS-Dilithium signatures are approximately 2.4 KB at security level 3, versus 64 bytes for ECDSA — a 37x overhead that matters for on-chain storage costs.

Projects building lattice-based wallet infrastructure from the ground up can align key generation, signing, and transaction verification with NIST PQC standards from the outset, rather than retrofitting them onto an ECDSA foundation. One example in the presale space is BMIC.ai, which is building a quantum-resistant wallet using lattice-based, NIST PQC-aligned cryptography specifically designed to protect holdings beyond Q-day.

---

Q-Day: Realistic Timelines and Risk Assessment for SXT Holders

"Q-day" refers to the point at which a cryptographically relevant quantum computer can break 256-bit elliptic-curve keys in a practically useful timeframe. Analyst views on timing vary considerably:

• Conservative estimates: NIST and NSA guidance suggests organisations should be migrating to PQC by 2030-2035, implying a CRQC could be viable in that window.
• Aggressive estimates: Some researchers at IBM, Google, and academic institutions suggest fault-tolerant quantum systems capable of running Shor's at scale could arrive before 2030 given recent error-correction milestones.
• Harvest-now scenarios: Adversaries with nation-state resources may already be archiving public blockchain data, including signed SXT transactions and node keys, for future decryption.

Risk Tiers for SXT Participants

---

What SXT Users Should Watch For

Until Space and Time or Ethereum publishes a concrete PQC migration plan, SXT participants can reduce risk through operational practices:

• Use fresh addresses for each transaction cycle rather than reusing wallets with long histories of signed transactions.
• Monitor NIST PQC adoption in the EVM ecosystem. Ethereum's roadmap includes account abstraction (EIP-4337) which could support PQC signature schemes without requiring a full base-layer fork.
• Watch for SXT governance proposals relating to cryptographic agility — the ability to swap signature schemes without a full protocol rebuild.
• Avoid storing large long-term holdings in wallets whose public keys have been broadcast, given harvest-now risk.
• Track post-quantum ZK proof research — frameworks like Ajtai commitments and hash-based accumulator trees are advancing and could eventually replace EC commitments in systems like Proof of SQL.

---

Conclusion

Space and Time is not quantum safe in its current form. Its Proof of SQL system relies on elliptic-curve polynomial commitments vulnerable to Shor's algorithm, its token infrastructure inherits Ethereum's ECDSA exposure, and its node signing infrastructure uses EdDSA and BLS schemes that share the same fundamental weakness. This does not make SXT uniquely dangerous compared to its peers — the vast majority of the crypto ecosystem faces identical exposure. The distinction lies in whether a project is actively developing a migration path and at what layer the dependencies sit. For SXT, both the proof layer and the wallet layer would require substantial re-engineering to reach genuine post-quantum security. Participants with long time horizons should treat this as a tracked risk, not an immediate crisis, but one that warrants a concrete mitigation plan before the quantum hardware window closes.