Security
Stratum is designed so that trust is minimized and verification is maximized. This page explains what is trusted, what is verified, and what is anchored on-chain.
Trust Model
TEE-Secured (Hardware)
The Stratum node runs inside an Intel TDX enclave on Phala Cloud. Cryptographic attestation (TDX Quote) proves exactly what code executed the netting computation. Even the operator cannot tamper with execution or extract keys.
Verified
Every receipt signature is independently verifiable. Merkle inclusion proofs confirm receipt existence. The sum-to-zero netting invariant is mathematically guaranteed.
On-Chain
Only Merkle roots are anchored on-chain — one 32-byte hash per settlement window. This is a data commitment, not a payment. Anyone can verify.
Threat Model
Malicious Agent (replay attack)
Every receipt contains an idempotency key: SHA-256(payer + payee + resource_hash + amount + nonce). Duplicate keys are rejected at ingestion. An agent cannot replay a receipt to extract extra value.
Compromised Facilitator
Stratum's Merkle proofs are independently verifiable. If a facilitator claims a receipt does not exist, any party can produce the inclusion proof from the on-chain root. The facilitator cannot deny settlements that Stratum has committed to.
Stratum Node Failure
The write-ahead log (WAL) ensures crash recovery. All mutations are logged before execution. On restart, pending operations replay from the last checkpoint. No funds are at risk because Stratum never holds custody — unfinalized windows simply resume.
Receipt Forgery
Receipts are Ed25519 signed by the Stratum node. Forging a receipt requires the node's private key. Verification requires only the public key, which is published. Canonical encoding ensures signatures cannot be transferred between different receipt data.
Cryptographic Primitives
| Primitive | Usage | Library |
|---|---|---|
| Ed25519 | Receipt signing, window head signing | @noble/ed25519 |
| SHA-256 | Merkle tree hashing, receipt hashing, idempotency keys | @noble/hashes |
| SHA-512 | Ed25519 internal hashing | @noble/hashes |
| RFC 6962 | Merkle tree structure (0x00 leaf, 0x01 node prefixes) | Custom implementation |
| Canonical Encoding | Deterministic JSON serialization for signing | Custom (sorted keys, BigInt/Uint8Array encoding) |
| Intel TDX Quote | TEE attestation, netting computation integrity | @phala/dstack-sdk |
Audit Trail
Any receipt can be independently verified through the following chain:
The on-chain Merkle root is the ultimate source of truth. Given a receipt and its inclusion proof, anyone can recompute the path to the root and verify it matches the on-chain commitment. No trust in Stratum is required for verification.
Three Layers of Trust
Layer 1: Hardware Attestation
Intel TDX enclave proves the code ran correctly and was not tampered with. Attestation quotes are publicly verifiable at proof.phala.network.
Layer 2: Mathematical Proof
Every receipt is hashed into an RFC 6962 Merkle tree. Inclusion proofs let anyone verify a receipt exists in a settlement window without trusting the operator.
Layer 3: On-Chain Finality
Merkle roots are anchored on Solana. The chain is the ultimate source of truth. Anyone can verify any receipt against the on-chain commitment.
Most payment systems offer one of these. Stratum offers all three.
Verify a receipt now
The Stratum Explorer lets you paste any receipt hash and see the full Merkle proof path, verified against the on-chain anchor.
Open Explorer →