Technical notes

How Stvor works, cryptographically.

The cryptographic primitives are not novel — ES256 (P-256) and SHA-256 are industry standard. What Stvor provides is the composition: commit → verify → settle binding designed for the AI agent execution context, with a portable, offline-verifiable receipt format.

Architecture

Core concepts

Commitment anchoring

The core primitive. Before any transaction is built, the caller commits a payment payload hash via POST /commitments — destination, amount, currency frozen as SHA-256(RFC 8785 canonical JSON). When execution is ready, POST /verify re-canonicalizes the live payment and compares hashes. Match → decision ALLOW + signed receipt. Destination swap or field change → decision DENY + signed receipt. Settlement fires only on ALLOW. This is pre-execution verification: commit → verify → settle.

Canonical hash construction

To make the commitment hash deterministic across languages and platforms, Stvor canonicalizes the payment object before hashing: 1. RFC 8785 (JCS) canonical JSON serialization 2. SHA-256 hash of the canonical bytes 3. Compare with crypto.timingSafeEqual at verify time Payment fields: { to, amount?, currency?, chain?, asset? } — only to is required. The canonical spec is open — verify against published fixtures in stvor-hq/core.

Trust Receipt format

A Trust Receipt is a signed JSON document returned inline from POST /verify (ALLOW and DENY). It contains: • decision — ALLOW or DENY • reason — e.g. PAYLOAD_MISMATCH on DENY • payload hash and verified fields • agent identity and timestamps • signature — ES256 (P-256) over the canonical body The receipt is verifiable offline using Stvor's published public key at /.well-known/public-key (or the keyset at /.well-known/stvor-keys.json). No Stvor API call is required to verify a receipt.

Threat model

Stvor addresses payload manipulation in the AI agent finance context: Payload swap — the payment destination or amount is modified between commit and execution. Stvor's hash compare catches this before settlement. What Stvor does NOT address today: policy gates (maxAmount, allowlists — planned, not shipped), private key compromise, malicious agent code, or smart contract-level attacks. These require additional controls. See the security page for the full honest scope.

ATS-1

Trust Receipt format (draft)

ATS-1 is the open Trust Receipt format Stvor is drafting: a portable JSON document signed with ECDSA P-256 over a canonical payload hash. Any verifier with the issuer's public key can validate a receipt offline — no Stvor API call required.

Fields include commitment hash, verified checks, decision (ALLOW / DENY), agent identity, and timestamp. The draft spec and reference verifier ship with pilot engagements and on GitHub as they stabilize.

Read ATS-1 docs Request draft on Telegram

References

Standards and prior work

ECDSA P-256 / ES256 (IEEE P1363)

NIST-approved elliptic curve signature scheme. Stvor uses ES256 (secp256r1) for commitment and Trust Receipt signing — WebCrypto-native, widely supported in browsers and HSMs.

SHA-2 (FIPS 180-4)

NIST standard for the SHA-256 hash function used in Stvor's canonical commitment hash construction.

JSON Canonicalization Scheme (RFC 8785)

The serialization standard Stvor follows for deterministic canonical hashing of commitment fields before signing.

ERC-4337: Account Abstraction

The smart account standard Stvor integrates with for on-chain execution. Stvor's commitment anchoring can gate UserOperation submission.

NIST IR 8505: AI Agentic Systems

NIST's emerging framework for trust and security in agentic AI systems — the policy context Stvor's compliance audit trail targets.

MiCA Regulation (EU) 2023/1114

Markets in Crypto Assets regulation. Stvor's Trust Receipt format is designed with MiCA's traceability and audit trail requirements in mind.

GENIUS Act (U.S., 2025)

Proposed U.S. stablecoin framework requiring traceable execution and compliance audit trails. Stvor receipts are structured to support GENIUS Act compliance reporting.

ML-KEM (NIST FIPS 203) — Post-quantum roadmap

Lattice-based key encapsulation standard. Stvor's 2027 post-quantum migration roadmap targets ML-DSA (FIPS 204) for commitment signatures.