Technical notes

How Stvor works, cryptographically.

The cryptographic primitives are not novel — ed25519 and SHA-256 are industry standard. What Stvor provides is the composition: a commitment anchoring scheme designed specifically 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 signs a structured intent object — destination, amount, method selector, agent identity, and TTL — using ed25519. The signature is the commitment. It cannot be changed after signing. When the transaction is ready to submit, stvor.verify() checks: does the live payload match the signed commitment? If yes, a Trust Receipt is issued. If no — field mismatch, method change, destination swap — a VerificationError is thrown and the transaction is NOT submitted. This is pre-execution verification. It runs after signing, before broadcast.

Canonical hash construction

To make the commitment hash deterministic across languages and platforms, Stvor canonicalizes the intent object before hashing: 1. Sort all keys alphabetically (RFC 8785) 2. Normalize amounts to 18 decimal places (no floating point) 3. Lowercase all address fields 4. Strip trailing whitespace 5. Serialize to UTF-8 JSON without whitespace 6. SHA-256 hash the result This prevents encoding-variant attacks: two different serializations of the same intent produce the same hash. The canonical spec is open and language-agnostic — any SDK implementation can be verified against a reference vector.

Trust Receipt format

A Trust Receipt is a signed JSON document issued by Stvor after a successful verification. It contains: • id — globally unique receipt identifier • hash — SHA-256 canonical hash of the committed intent • signature — ed25519 signature over the hash • fields — map of verified field names to their committed values • agent — identifier of the signing agent • issued_at — ISO 8601 timestamp • ttl — commitment time-to-live in seconds The receipt is verifiable offline using Stvor's published public key at /.well-known/jwks.json. No Stvor API call is required to verify a receipt — this is by design. An auditor, regulator, or counterparty can verify any historical receipt without a vendor relationship.

Threat model

Stvor addresses three attack classes in the AI agent finance context: Payload manipulation — the transaction payload is modified between intent and execution. Stvor's commitment comparison catches destination swaps, amount changes, and method selector changes before submission. Context injection — a malicious prompt or tool response causes an agent to authorize a different operation than intended. Stvor's commitment was signed before the injection can affect the payload. Authorization gap — an agent operates beyond its delegated scope. Stvor's policy gate compares the intent against a declared policy (maxAmount, allowedMethods, allowedRecipients) before anchoring the commitment. What Stvor does NOT address: private key compromise, malicious agent code, or attacks at the smart contract level. 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

References

Standards and prior work

ed25519: High-speed high-security signatures

Bernstein et al. (2011). The digital signature scheme Stvor uses for commitment signing. Chosen for speed (<2ms), small key size, and wide ecosystem support.

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.