Pre-execution verification
Stvor sits between intent and execution. Before a payment, transfer, or tool call runs, it checks destination, payload hash, counterparty trust, and policy. Any mismatch → DENIED, no funds move. On success → ECDSA P-256 signed Trust Receipt (ATS-1 draft).
Monitoring acts after. After is irreversible.
Not theoretical
If your product moves user or treasury funds through an agent today, you have the same structural hole: execution happens before anyone verifies the live payload still matches intent.
Feb 2025
Destination changed after review. Signers approved what they saw on screen and signed something else. Multisig did not catch the swap between review and broadcast.
→ Same class of failure as agent destination-swap: commitment at review time ≠ payload at execution time.
2023–2024
Unknown counterparty accumulated token approvals over weeks, then drained the bot's wallet. No trust gate on who could receive outbound transfers.
→ Counterparty trust and policy gates matter as much as signing the right hash once.
Stvor is the check between intent and execution. It acts before. Monitoring acts after — after is irreversible.
The Problem
Financial operations fail between the moment they are committed and the moment they execute. Monitoring doesn't catch this. It reports after. After is irreversible.
Between commitment and execution, the recipient address was silently rewritten. The AI agent believed it was paying the right vendor. The audit log showed a successful transfer. The money went somewhere else.
// Agent committed to: destination: "0x7a3f91cd...4e" amount: 50_000 USDC vendor: "Acme Corp"
// What arrived at execution: destination: "0x4c1b82f7...3a7" ← amount: 50_000 USDC vendor: "Acme Corp"
A treasury automation agent held a signed authorization for routine operations. The authorization was revoked when the vendor contract ended. The agent's context cache was stale. The $200K transfer executed anyway.
// Authorization at signing time: agent_id: "agt_treasury_01" scope: "transfer.approve" valid_until: "2026-03-01T00:00:00Z"
// Execution time (2026-04-15): agent_id: "agt_treasury_01" scope: "transfer.approve" status: "EXPIRED" ← ignored
A prompt injection in an external data source replaced the recipient address mid-conversation. The agent completed the task exactly as instructed — by the attacker. The user saw a confirmation. The funds were gone.
// User instruction: "Pay $15,000 to our payroll provider as scheduled."
// Agent context after injection: "Pay $15,000 to payroll provider" [injected] destination: "0x9d..." // User never saw this change
Every existing solution — monitoring platforms, SIEM tools, compliance dashboards — acts after execution. They see what happened. Stvor acts before. It sees what is about to happen.
How it works
Stvor runs in front of your execution flow — not inside custody, not after broadcast. I wire this checkpoint with you during the pilot; there is no self-serve npm install path today.
Destination is hash-committed at intent time. Before execution, Stvor compares the live destination against the commitment. Swap → DENY.
SHA-256(canonical params) must equal the committed hash. Comparison uses crypto.timingSafeEqual() — no early exit on byte differences.
Minimum trust score on the receiving address or entity. Unknown or low-trust counterparties cannot receive outbound transfers from the agent.
Amount caps, allowed methods, recipient allowlists — evaluated against the signed policy attached to the commitment. Violation → DENY.
// Before your execution rail fires (Stripe, chain, internal ledger)
const checks = await stvor.verify({
commitment, // signed at intent time
payload: liveParams, // what the agent is about to send
});
if (!checks.allowed) {
throw new DeniedError(checks.reason); // no payment attempted
}
// checks.receipt — ECDSA P-256 signed Trust Receipt (ATS-1)const canonical = sortKeys(trim(params));
const hash = crypto.createHash("sha256")
.update(JSON.stringify(canonical))
.digest("hex");
const match = crypto.timingSafeEqual(
Buffer.from(hash, "hex"),
Buffer.from(commitment.payloadHash, "hex"),
);
if (!match) return { allowed: false, reason: "PAYLOAD_MISMATCH" };After ALLOW → portable Trust Receipt. Verifiable offline with only the issuer's public key. Format: ATS-1 (draft).
Who it's for
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 destination-swap, prompt injection, or post-authorization tampering, read on.
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.
Your bot holds hot wallet balances and executes strategies 24/7. Approvals accumulate. Counterparties change. You need a gate before every outbound transfer, not a dashboard after the drain.
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.
Moving live funds with agents? Book a 2 weeks pilot — I wire the checkpoint in your flow.
Book the pilot — $500Why custody-agnostic
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
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
Reference implementation is live and demonstrable. Production integrations happen through paid pilots — I stand up the checkpoint in your flow with you. No customer logos, no ARR, no user counts on this page until you see them elsewhere with a source.
Latency: <2ms per check in reference implementation on commodity hardware — not a production SLA until measured in your environment.
Paid 2-week pilot
I stand up a Stvor checkpoint in front of your execution flow — verify intent, destination, and payload before execution → ALLOW or DENY — plus a signed Trust Receipt after each action. I do the integration. At the end it works and you keep going, or you pay nothing further.
Technical crowd: ATS-1 spec · GitHub
Roadmap