For agents that move real money
Wrong address?
Stvor blocks the payment before it goes out.
Your AI agent commits to pay vendor A. Something swaps the destination to address B. Stvor catches the mismatch before any funds move and leaves a signed receipt you can show an auditor.
Monitoring tells you after. After is irreversible.
x402 on Base · Chainalysis
Share of value from payments $1+ rose 49% → 95% in one year. The 10¢–$1 band fell 46% → 4%. Agents are moving real money — now, not in three years.
No signup · No email · ~30 seconds
Try it now
Touch it before you email anyone.
Hash the payload yourself, commit with a fresh nonce, verify ALLOW with the same to, then swap to for DENY. Sandbox key below — no email required.
Offline verifier
Don't take our word for it — verify the signature.
One click loads a real DENY receipt from a blocked destination swap, checks ES256 (P-256) in your browser with only the published key. No network calls.
Same code as @stvor/core. Full page: /verifier
Public sandbox key
Test environment, rate-limited, revocable. Paste into Authorization: Bearer or STVOR_KEY. Production keys still require a message to @kun_sapog.
stvor_test_tdesrpqe9auRopdcA2Ab-bFzF2xylw9vStep through commit → verify
Pick a scenario: commit intent, tamper payload or destination, watch ALLOW vs signed DENY. Runs in your browser.
Open interactive demo →fixtures/Self-check with test vectors
Published fixtures in the core repo — run them against your client before you write a line against the API.
Browse fixtures →npm install @stvor/client
# Payment payload (RFC 8785 — hash the canonical bytes, not this comment block):
# {"amount":"50000.00","currency":"USDC","to":"0x4c1b82f71a9e3d0c8b5e6f2a1d4c7b9e0f3a8c1d"}
# payloadHash = SHA-256(canonical) = b36c8892571afafab33f0f389c62293948a7ff61f3064eca12700582756cda78
# (agentId, nonce) must be unique per commitment — use a fresh nonce every time.
curl -X POST https://api.stvor.xyz/commitments \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer stvor_test_tdesrpqe9auRopdcA2Ab-bFzF2xylw9v' \
-d '{
"agentId": "agt_sandbox_demo",
"payloadHash": "b36c8892571afafab33f0f389c62293948a7ff61f3064eca12700582756cda78",
"alg": "sha256",
"nonce": "<any-unique-string>",
"expiresAt": "2026-12-31T23:59:59.000Z"
}'# Same to / amount / currency as the committed payload → ALLOW (+ signed receipt inline)
curl -X POST https://api.stvor.xyz/verify \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer stvor_test_tdesrpqe9auRopdcA2Ab-bFzF2xylw9v' \
-d '{
"commitmentId": "cmt_FROM_COMMIT_RESPONSE",
"intent": {
"from": "agt_sandbox_demo",
"to": "0x4c1b82f71a9e3d0c8b5e6f2a1d4c7b9e0f3a8c1d",
"amount": "50000.00",
"currency": "USDC"
}
}'# Swap to after commit → PAYLOAD_MISMATCH → signed DENY
curl -X POST https://api.stvor.xyz/verify \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer stvor_test_tdesrpqe9auRopdcA2Ab-bFzF2xylw9v' \
-d '{
"commitmentId": "cmt_FROM_COMMIT_RESPONSE",
"intent": {
"from": "agt_sandbox_demo",
"to": "0x9d0000000000000000000000000000000000000001",
"amount": "50000.00",
"currency": "USDC"
}
}'Already happening
Agent payments stopped being pocket change.
On Base, x402 still processes huge numbers of sub-cent pings — but where the dollars sit moved. Transactions of $1 or more went from 49% of value transferred to 95% in one year. The 10¢–$1 band collapsed 46% → 4%. That is real economic weight, not a roadmap slide.
share of value transferred
Transactions $1+
Early 2025
49%
Early 2026
95%
early 2025 → early 2026
share of value transferred
10¢ – $1 band
Early 2025
46%
Early 2026
4%
early 2025 → early 2026
When agents move five-figure USDC, a destination swap is not a lab exercise. Stvor is the hash compare at execution — before the rail fires. Chainalysis · x402 on Base ↗
The Problem
Intent and execution diverge.
Monitoring only sees it after.
Stvor solves one class of failure with certainty: the live payment payload no longer matches what was committed. Not scope revocation. Not slow approval farming. A hash compare at execution time.
The destination changed. Nobody noticed.
Between commitment and execution, the recipient address was silently rewritten. The agent believed it was paying the right vendor. The audit log showed a successful transfer. The money went somewhere else. Stvor catches this with one gate: canonical payload hash compare.
// Agent committed to: to: "0x7a3f91cd...4e" amount: "50000.00" currency: "USDC"
// What arrived at execution: to: "0x4c1b82f7...3a7" ← amount: "50000.00" currency: "USDC"
Monitoring reports after execution. Stvor compares the hash before a dollar moves.
How it works
commit → verify → settle
One gate: canonical payload hash compare. Destination, amount, and currency are all in the digest — a swapped address changes the hash and produces a signed DENY.
commit
POST /commitments — payment payload canonicalized (RFC 8785) and hashed. Intent frozen before any transaction is built.
verify
POST /verify — live payload re-canonicalized and compared with timingSafeEqual on the hash. Destination swap or any field change → signed DENY.
settle
Your execution rail fires only after ALLOW. Signed Trust Receipt comes inline from POST /verify. POST /receipt is optional — attach txHash after settlement.
// commit → verify → settle
const commitment = await stvor.commit(payment, {
agentId,
nonce: crypto.randomUUID(),
});
const result = await stvor.verify(
{ from: agentId, ...payment },
{ commitmentId: commitment.commitmentId },
);
if (result.decision !== "ALLOW") {
// signed DENY in result.receipt — verify offline, do not settle
throw new Error(result.reason);
}
await settleOnYourRail(payment);// stvor-core/src/canonical.ts — RFC 8785 via canonicalize
import jcs from "canonicalize";
export function canonicalize(value: unknown): string {
const out = jcs(value);
if (typeof out !== "string") {
throw new Error("canonicalize: value is not JSON-serializable");
}
return out;
}
// verify compares SHA-256(canonical live) vs committed hash
// one check: { to, amount, currency, chain?, asset? } → single digestThis DENY receipt is real — load it in the verifier above. ES256 signature, full bytes, offline check with only the published key.
Who it's for
Builders whose agents already move real funds.
Written for a technical founder or eng lead — not a CISO buying a dashboard. If you are still in prototype with no live money, the pilot is probably early. If funds move today and you worry about a destination swap or tampering after commit, read on. Stvor compares hash at execution — not poisoned commits from prompt injection.
Agent-commerce products in production
You ship autonomous checkout, invoicing, or API-billed agents. Real user money moves on every successful tool call. One destination swap is a company-ending event.
- LangGraph / custom agent loops
- Stripe or on-chain settlement
- No human in the approval loop
DeFi / trading bots with treasury at risk
Your bot holds hot wallet balances and executes strategies 24/7. A destination swap between your strategy's decision and the broadcast is the failure mode Stvor catches — not slow approval farming or counterparty trust scoring.
- MEV / arb / market-making bots
- Multi-chain execution
- Swap between decision and broadcast
Agent platforms where customers bring their own keys
You provide the agent runtime; customers connect wallets or payment rails. You cannot see inside their custody stack — but you can require a Stvor checkpoint before their agents execute.
- B2B agent infrastructure
- Customer-owned keys
- Liability without visibility
Why custody-agnostic
A trust layer has to be neutral to be trusted.
Stripe did not become HTTPS. Cloudflare did not replace TLS. They sit on top of a neutral primitive and add value without owning the pipe. Stvor is the same shape: verification middleware that works whether you custody with Fireblocks, run your own hot wallet, or settle through Stripe manual-capture.
If the verifier only works inside one vendor's stack, every other stack treats it as that vendor's feature — not infrastructure. Neutrality is the moat. The Trust Receipt (ATS-1) is the portable proof that outlives any single integration.
Competitive Positioning
Custody tools act too late
or inside one provider.
Stvor is pre-execution verification with a signed receipt — not a custody product, not post-event monitoring. Comparison reflects publicly documented behavior; corrections welcome.
Scroll right
| Solution | Category | When it acts | AI agent native | Custody-agnostic | Cryptographic proof |
|---|---|---|---|---|---|
STVOR | Execution Trust Layer | Pre-execution | |||
Fireblocks | Custody + Policy Engine | Pre-execution | Policy engine only works within Fireblocks custody | ||
Blockaid | Transaction Simulation | Pre-sign (web3 only) | Simulates web3 transactions, no agent-native support | ||
Hypernative | Threat Monitoring | Post-event | Monitors on-chain events after execution | ||
Safe (Gnosis) | Multi-sig Governance | Pre-execution | Multi-sig governance, not AI agent verification | ||
Chainalysis / TRM | Compliance Analytics | Post-transaction | Forensics and compliance reporting after the fact |
The independent trust layer wins for the same reason SSL won: Trust infrastructure must be neutral to be trusted. A verification layer owned by a custody provider is not trusted by its custody competitors. STVOR is custody-agnostic by design — the only position from which it can become foundational infrastructure for the entire ecosystem.
Current stage
Honest about where this is.
Live production API, public repo, published test vectors, and a receipt you can verify in your browser right now. Hackathon Stripe demo on nous.stvor.xyz is a separate reference build — not the production surface.
Live today
Production- ·Production API at api.stvor.xyz — /commitments, /verify, /receipt
- ·Public @stvor/core + @stvor/client on GitHub (npm)
- ·Commit → verify gate: RFC 8785 canonical payload hash compare
- ·ES256 signed Trust Receipt for ALLOW and DENY
- ·Browser verifier + published demo fixture at stvor.xyz/verifier
In progress
Now- ·OrbServ / OrbWallet integration (design partner — orbserv.co)
- ·ATS-1 receipt format spec (draft, open)
- ·White-glove pilot integrations
Planned rails
Planned- ·x402 payment rail (2026)
- ·On-chain receipt registry (evaluating necessity)
Design partner
Already verified the receipt? Wire it in production.
I stand up a Stvor checkpoint in front of your execution flow — commit intent, verify at execution, settle only on ALLOW — plus a signed Trust Receipt for every decision. I do the integration. At the end it works and you keep going, or you pay nothing further.
- Checkpoint wired in front of your live execution flow
- Commit → verify gate with canonical payload hash compare on every payment
- Signed Trust Receipt (ALLOW and DENY) after each decision
- I do the integration — you bring the agent and the rail
Current design partners: OrbServ · OrbWallet
Technical crowd: ATS-1 spec · GitHub
Roadmap
Where this goes. Not where it starts.
Agent-money verification
- OrbServ / OrbWallet integration (in progress)
- x402 payment rail
- ATS-1 Trust Receipt spec publication
- Design partner integrations
Broader rails + registry
- Additional execution rails beyond payment verify
- Evaluate on-chain receipt registry for composability
Treasury & compliance scale
- Enterprise treasury automation receipts
- Regulatory audit trail exports (MiCA / stablecoin context)
- Post-quantum signature migration path (if warranted)