Spacy
Privy for post quantum world
About
The problem it solves ## What Spacy is Spacy is a Web3 wallet that lets users sign in with Google and immediately use crypto applications without a seed phrase, browser extension, or any prior wallet experience. Same product category as Privy or Dynamic, the embedded wallets behind tens of millions of consumer crypto accounts today. The difference is that Spacy is the only one in this category that lets anyone, on their own laptop and without trusting us, verify that every transaction was actually signed in the hardware we claim, with the safeguards we promise. ## The problem we are solving When a user signs into a Privy-backed app, their private key is generated and stored inside a Trusted Execution Environment, or TEE: a special area of a server's processor that is supposed to be sealed off from everyone, including Privy itself. The user is asked to trust three things: that the TEE is real, that the randomness used to make the key was unpredictable, and that the operator has not been compromised. None of those claims can be verified independently. You take Privy's word for it. This was always a fragile model. In 2026 it is breaking down on three fronts at once. **The hardware was broken in October 2025.** Researchers at Georgia Tech and Purdue published the TEE.Fail attack: using under $1,000 of equipment, they extracted the cryptographic keys that prove a TEE is genuine, then forged fake TEE attestations that pass Intel's own verifier. The same primitives protect tens of millions of consumer wallets today. Privy, Turnkey, and Dynamic have published nothing about how they are responding. **The cryptography has an expiration date that just moved closer.** In May 2025, a Google researcher showed that breaking RSA-2048 encryption now requires 20 times fewer quantum bits than estimated six years ago. Major roadmaps now point to capable quantum computers around 2030. Every embedded wallet today still signs transactions with ECDSA, the algorithm that quantum computers will break. None of the incumbents have a published migration plan. **The proofs do not survive Q-day.** When quantum hardware breaks today's TEE attestation keys, every TEE proof ever issued can be retroactively forged. The proof that your wallet's transaction was actually signed inside a real enclave by a real user becomes worthless overnight. Existing wallets have no durable, independent record that can survive this collapse. ## How Spacy solves it The signing key is held inside SpaceComputer's Orbitport KMS, a service running in Intel TDX (Intel's TEE technology). Our orchestration backend, the part that authenticates Google sessions and brokers the signing requests, runs on a real AWS EC2 instance with AMD SEV-SNP (AMD's TEE technology) enabled. This is not a roadmap claim, it is shipping today: every Spacy session produces a real SEV-SNP attestation report from real AMD silicon, exposed on a public health endpoint anyone can fetch and verify offline. Two different TEE vendors, two different operators, two different attestation roots. A single class of zero-day cannot reach both halves of the trust path. Every signing operation is timestamped against a fresh sample of cosmic randomness from SpaceComputer's cTRNG service, recorded in the receipt and matchable against an IPFS public beacon archive. Every transaction emits an attestation receipt: a JSON document containing the transaction details, the SEV-SNP self-attestation including its certificate chain, the KMS keyId, and the cosmic entropy witness. The receipt is pinned to IPFS through Pinata, and its content-addressed identifier is emitted to a Sepolia smart contract as an on-chain pointer. Real receipts, real on-chain events, today. To verify any Spacy transaction, you read the on-chain event, fetch the receipt from IPFS, walk the AMD certificate chain offline against AMD's root, and cross-check the cosmic entropy against SpaceComputer's public beacon. No step requires Spacy to be online. No step requires trusting us. When SpaceComputer ships their published roadmap (orbital KMS, ML-DSA dual signatures for post-quantum), our SDK adopts each upgrade with a single parameter change. The wallet a user onboards into in 2026 should be the wallet that still works in 2032. Today, that wallet does not exist. Spacy is the bet that it should, built on SpaceComputer's open infrastructure, licensed AGPL-3.0.
How it's made
Challenges we ran into ## We started building threshold ECDSA, then realized the KMS would not let us The original plan was a 2-of-3 threshold ECDSA wallet using cggmp21, with one share in the user's browser, one inside the SpaceComputer KMS, and one held by our coordinator. Full liveness across satellite, ground, and user, no single party able to forge a signature alone. We started wiring the protocol against the Orbitport KMS expecting it to participate in the threshold protocol. The KMS does not work that way. It is a black-box signer: you create a key, ask it to sign a digest, get a 65-byte ECDSA signature back. There is no API for participating in MPC, no way to produce a partial share, no hook for any threshold scheme. The signing key never leaves the TEE in any form, including as a share, which is exactly what makes it a strong signer and exactly what makes threshold cryptography on top of it impossible without rebuilding the KMS itself. We stopped, took stock, and rewrote the architecture around the actual primitive Orbitport ships. Instead of distributing trust cryptographically across multiple parties, distribute it structurally across multiple TEE vendors. Intel TDX for the signer (Orbitport), AMD SEV-SNP for the coordinator (our AWS instance), with the trust path crossing two heterogeneous hardware lineages. A single class of zero-day cannot reach both halves. The structural distribution we lost from threshold, we got back from vendor heterogeneity. SpaceComputer's roadmap moves to threshold KMS in phase 2, at which point the original plan slots in without architectural rewrite. ## The KMS attestation quote we expected was not exposed by the API Spacy's pitch is that every signature comes with a verifiable Intel TDX attestation quote from the KMS. The receipt schema reserves a signer.quoteHex field for this. SpaceComputer's spec describes it, the SDK type declares it, we wired the call expecting it to be populated. It was not. We tried kms.GetAttestation, kms.Attestation, plain GET and POST against /attestation and /kms/attestation, every variant the SDK type hinted at. All 404 or 405. The SDK's "expected one of" error listed every method it knew about and none was an attestation endpoint. The kms.sign response itself returned signature and metadata, but no quote. We could have populated the field with a placeholder. Instead we kept it as an empty string, marked quoteVerified as the honest result of attempting verification on nothing, documented the gap, and structured the schema so it accepts the quote the day SpaceComputer ships the endpoint. The TDX side is reserved, not faked. ## The cTRNG response is missing fields its SDK type promises Two related problems on the entropy side. First, the SDK type declares getRandom includes a signature object with value, pk, algo. We hit the raw ctrng.Get RPC directly and the wire payload was just src and value. No signature anywhere. The SDK was projecting a type the gateway does not currently fulfill. Second, cTRNG offers two source modes: rng for the live satellite roundtrip, derived for the BIP32-derived fallback. We asked for rng. The API returned derived, because the live source is gated and not active for our token tier during the hackathon. We left entropy.signatureHex empty and wrote the actual returned source value into the receipt verbatim. The verifier matches the entropy value against the IPFS public beacon archive, which is signed at the round level and is independent of our backend. The cosmic randomness witness still has a real verification anchor, just not the per-call satellite signature the SDK type promises. Nothing in the receipt claims a stronger source than the API actually provided. ## VLEK extraction from the kernel did not work, AMD KDS rescued us The SEV-SNP attestation report is only meaningful if you can verify it against AMD's certificate chain (VLEK to ASK to ARK). The obvious approach is to pull the chain from the kernel: sev-guest -x should hand it back. It did not. The command returned an Input/output error, because the host had not been pre-provisioned with sev-host-set-cert-chain and the guest kernel does not expose VLEK by default. We initially suspected a permissions issue and wasted time on chmod and dmesg. The actual fix was to bypass the kernel entirely. The SEV-SNP report contains a chip_id field at a documented offset. We read it out, fetched the VCEK directly from AMD's KDS at https://kdsintf.amd.com/vcek/v1/Milan/<chipId>, and concatenated it with the bundled ASK and ARK roots offline. Cleaner than the kernel path: verifiers need nothing from our host, only AMD and the trust anchor bundle we publish.