Security
How Stvor thinks about security
We are explicit about what's verified, what's pending, and where the limits are. If you're evaluating Stvor for a regulated workload, read this page and then talk to us.
ed25519 commitment signing
Every intent commitment is signed with ed25519 before the transaction payload is built. Signing is <2ms on commodity hardware. The public key is published at /.well-known/jwks.json — receipts are verifiable offline, no API call required.
SHA-256 canonical hashing
Commitment fields are canonicalized (sorted keys, trimmed whitespace, amounts normalized to 18 decimal places) before hashing. This prevents encoding-variant attacks where two different encodings produce the same payload but different hashes.
No payload data leaves your infra
Stvor never sees transaction content. The commitment hash and ed25519 signature are sent to the Stvor API. The actual payload stays on your infrastructure. BYOK mode (bring-your-own-key) keeps your private key entirely local.
Responsible disclosure
Found a vulnerability? Email founder@stvor.xyz with subject [security]. We respond within 24 hours. Bug bounty program launches with the first external audit.
External audit — planned, pending funding
We have not yet contracted an independent security audit. This is the gating constraint. Design partner engagements include the audit roadmap in the procurement conversation.
Post-quantum migration — roadmap 2027
Current signing uses ed25519 (classical). NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) migration tooling is planned for 2027. The SDK will provide a migration path that does not require re-anchoring existing commitments.
Disclosures
What you should know before deploying
We'd rather you know these upfront than discover them in a post-mortem. Reach out and we'll walk through your specific threat model.
No external audit yet
We have not contracted an independent code audit. We are explicit about this and roadmap it in every design partner conversation. The SDK is suitable for design partner integrations under our supervision — not production deployments handling regulated funds without coordination.
Commitment anchoring does not prevent all prompt injection
Policy gates reduce the blast radius of prompt injection attacks, but they cannot prevent a fully compromised agent from issuing a legitimate-looking commitment for a malicious operation that passes policy rules. Defense in depth is required — Stvor is one layer, not the entire security posture.
Offline receipt verification relies on key continuity
Receipts verified offline use the Stvor public key published at /.well-known/jwks.json. Key rotation is announced with 90-day notice. If you cache the public key, implement a rotation check.
BYOK mode is self-custody — key loss means receipt loss
In BYOK mode, your private key is not escrowed by Stvor. If you lose the private key, you cannot issue new receipts or verify existing ones. Use a KMS with backup — AWS KMS, GCP Cloud KMS, HashiCorp Vault.
Roadmap
Security roadmap
Dates marked as planned are aspirational. We don't hide that distinction.
Now
Shipping now- Apache 2.0 open-source SDK on GitHub
- ed25519 commitment signing + SHA-256 canonical hashing
- Policy gates: maxAmount, allowedRecipients, allowedChains
- Offline receipt verification via published JWKS
- BYOK mode — private key never leaves your infrastructure
- Design partner pilots under supervision
Q3–Q4 2026
Planned- First external code audit (pending funding)
- Formal threat model publication
- Bug bounty program launch
- SOC 2 Type II audit engagement
2027+
Long-term- NIST FIPS 203/204 migration tooling (ML-KEM + ML-DSA)
- Post-quantum commitment signing without re-anchoring
- FIPS 140-3 for hosted KMS option
- Continuous third-party security reviews