Research

The math is the product.

SCSA's guarantees are written down and peer-reviewable. Full papers and validation reports are available to qualified partners under briefing.

Conventional vaults vs SCSA
PropertyConventionalSCSA
Key managementA single operator holds the keyt-of-n threshold MPC: no single party can decrypt
Time-locking“Trust us” policy enforcementSequential time-locks: iterated hashing that cannot be parallelized
Tamper evidenceEditable access logsHash-chained audit log under Merkle commitment
Forward secrecyStatic keys persistState ratchet: old keys securely zeroed
Post-quantumRSA / ECC onlyML-KEM-768 hybrid key establishment (formally verified implementation) · ML-DSA-65 + SLH-DSA (FIPS 204/205) signing · hash-based STARK
Hardware bindingNone: keys are portableGPU attestation · TPM2 · TEE measurement-derived keys
Access privacyProvider sees every accessPath ORAM: patterns indistinguishable from random
Build provenance“Trust our build server”Reproducible builds: byte-identical from source, published SBOM and measurements
Deletion“We deleted it,” assertedProvable erasure: key destruction with signed receipts — retained ciphertext is permanently unrecoverable
Ceremony transcripts

Distributed key generation produces a canonical, signed transcript — participants, commitments, disqualifications, and the group key — that every party countersigns. Custody starts with a document anyone can verify, not a ritual anyone must trust.

Machine-checkable protocol models

Our authenticated key-establishment protocol ships with machine-checkable models of its security properties. The design is written to be verified, not just reviewed.

No trusted setup and no lattice assumption in the proof system: security rests on collision-resistant hashing, so the transparency proofs stand against quantum adversaries. Signatures are ML-DSA-65 and SLH-DSA hybrids and key establishment is an ML-KEM-768 hybrid, aligned to FIPS 203/204/205 — with a formally verified ML-KEM implementation.