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.
ES256 (P-256) receipt signing
Trust Receipts are signed with ES256 (secp256r1, IEEE-P1363) at verify time. The public key is published at /.well-known/public-key — receipts are verifiable offline with no API call.
SHA-256 + RFC 8785 canonical hashing
Payment payloads are canonicalized with RFC 8785 (JCS) before SHA-256 hashing. Verify compares committed hash to live hash with timingSafeEqual — one gate for destination, amount, and currency.
What the API sees
POST /commitments sends payloadHash (not raw payment fields). POST /verify sends the full intent object (from, to, amount, currency) for hash comparison. Stvor does not hold funds or private keys.
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 ES256 / P-256 (classical). NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) migration tooling is planned for 2027 — not shipping today.
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. The SDK is suitable for design partner integrations under our supervision — not production deployments handling regulated funds without coordination.
Hash compare does not prevent all prompt injection
If a compromised agent commits to a malicious destination upfront, verify will ALLOW a payment you did not intend. Stvor catches payload swaps between commit and execution — not bad intent at commit time. Defense in depth is required.
Offline receipt verification relies on key continuity
Receipts verified offline use the Stvor public key at /.well-known/stvor-keys.json. Key rotation is announced with notice. If you cache the public key, implement a rotation check.
No policy gates in v0.2
maxAmount, allowedRecipients, and method-selector policy gates are not shipped in the current API. The only enforcement gate is canonical payload hash compare.
Roadmap
Security roadmap
Dates marked as planned are aspirational. We don't hide that distinction.
Now
Shipping now- MIT-licensed @stvor/client + @stvor/core on GitHub
- ES256 (P-256) receipt signing + SHA-256 / RFC 8785 hashing
- commit → verify → settle with inline signed receipts
- Offline receipt verification via published well-known keys
- Design partner pilots under supervision
Q3–Q4 2026
Planned- First external code audit (pending funding)
- Formal threat model publication
- Bug bounty program launch
- Policy gates (maxAmount, allowlists) — not shipped yet
2027+
Long-term- NIST FIPS 203/204 migration tooling (ML-KEM + ML-DSA)
- Post-quantum commitment signing without re-anchoring
- Continuous third-party security reviews