Security
Evidence you can check, so you don't have to trust us.
Stele is built so that the people with the most power over the record — the company, its employees, and Stele itself — cannot quietly change it. This page summarizes how.
Trust model
What you trust — and what you don't.
You rely on
- Solana consensus and the integrity of finalized blocks
- SHA-256 and Ed25519
- The Stele program at a build you can reproduce from source, with its upgrade authority held by a multisig
- The DNS attestor, only for the meaning of “verified domain”
You do not need to trust
- Stele's servers, database or indexer
- The relayer that pays transaction fees
- The website showing you a receipt — including this one
- Any single RPC provider, when you configure several
Threat coverage
Sixty-plus attack scenarios, each with a defense.
Every scenario in the threat model lists the attack, impact, defense, detection, recovery and residual risk. The main families:
Rewriting what was accepted
Versions are immutable accounts with no update or close instruction. Each commits to its predecessor; the text is bound by hash. A company cannot swap the document after the fact, backdate it, or publish one text while displaying another.
T01–T10, T56–T58
Forging or replaying acceptances
The program verifies the user's signature itself and rebuilds the signed message from chain state. Messages bind organization, document, version, fingerprint, signer, network, expiry and a single-use nonce. The relayer and the database cannot create, alter or replay one.
T15–T28, T53, A02–A04
Phishing and impersonation
Display names are never treated as identity. Domains are verified through DNS and attested on-chain with an expiry, the signed message states “verified” or “unverified”, and names the requesting site. Invisible and bidirectional control characters are rejected by the protocol, and domains must be plain ASCII (punycode).
T13, T14, T20, A05, A06, A23
Compromised keys and insiders
Scoped roles, multisig owners, two-step ownership transfer, a time-locked recovery authority, an emergency freeze, and key-compromise reports that flag later signatures by a revoked key.
T11, T12, T35–T41, A09
Compromised Stele infrastructure
Our database, API and indexer are conveniences, not trust anchors. The verifier, the SDK and the acceptance page check everything against Solana and content hashes; multiple RPC providers can be required to agree.
T29–T34, T42, T49–T51, T59
Abuse and denial of service
Relayer-gated nonce shards, per-organization caps on open challenges, rate limits, server-issued acceptance sessions, and transaction sizes that always fit Solana's packet limit.
T54, T55, A07, A08
Cryptography
Boring, well-understood primitives — composed carefully.
| Content commitment | SHA-256 over stele-canonical-v1 bytes (RFC 8785 JSON, NFC text, forbidden invisible and bidirectional characters) |
|---|---|
| Version fingerprint | SHA-256 over a canonical record of chain ID, program, organization, document, version number, predecessor, title, label, effective date and content hash — recomputed by the program |
| User signatures | Ed25519 over a human-readable, domain-separated message; verified on-chain through Solana's Ed25519 program with strict instruction introspection |
| Replay protection | Per-organization nonce bitmaps (65,536 single-use nonces per shard) and short validity windows (ten minutes by default) checked against cluster time |
| Network separation | CAIP-2 chain ID derived from the genesis hash is part of every fingerprint; the network name is part of every signed message |
| Acceptance identifiers | SHA-256 with a protocol tag over version, signer, message hash and signature; folded into an on-chain accumulator per shard |
Application security
The web layer is hardened too.
- Strict Content Security Policy: scripts run only with a per-request nonce; framing denied
- Wallet sign-in with single-use nonces; HttpOnly session cookies; CSRF tokens plus Origin checks
- Recent wallet re-authentication required for API keys, webhooks and settings
- API keys and session tokens stored only as hashes; webhook secrets encrypted at rest
- Outbound requests resolved and pinned to public IPs (SSRF protection)
- Append-only, hash-chained audit log enforced by a database trigger
Operations
Keys with the least possible power.
- The relayer key only pays fees; it cannot create or alter evidence
- The attestor key can only vouch for domains, with expiry, and can be rotated
- Program upgrades require a multisig; verifiable builds let anyone match the deployed bytecode
- The verifier detects post-upgrade tampering by cross-checking publication transactions
- No private keys or seed phrases are ever stored or requested
Found a vulnerability?
Please report it privately following our security policy. We acknowledge reports promptly, coordinate disclosure, and credit researchers who want to be credited.