Stvor

Technical deep dive

How Stvor works

The $1.5B Bybit hack was a tampered payload. The $7.5M JaredFromSubway drain was an unverified counterparty. Same root cause: execution happened before anyone verified the live operation still matched intent. Stvor closes both gaps at the checkpoint — before the payment rail fires.

Overview

Stvor is middleware between intent and execution. It does not replace custody, monitoring, or signing infrastructure. It answers: does what is about to run still match what was committed? Any check fails → DENIED, no payment attempted.

01 · Four checks

01

Destination match

Destination is hash-committed at intent time. Before execution, compare live destination against commitment. UI swaps, injected addresses, and delegatecall redirects all fail here.
02

Payload integrity

SHA-256(canonical params) must equal committed hash. Comparison uses crypto.timingSafeEqual().
03

Counterparty trust

Minimum trust score on receiving address or entity. Unknown counterparties cannot receive outbound transfers — blocks slow-accumulation approval attacks.
04

Policy check

Amount caps, method allowlists, recipient lists — evaluated against signed policy attached to the commitment.

02 · Payload attestation

Commit–reveal pattern: hash the canonical task payload at intent time. Before execution, re-hash the live payload and compare. A single byte change produces a different digest.

Attack

Bybit — $1.5B — Feb 2025

  1. 1.Safe{Wallet} developer workstation compromised
  2. 2.Malicious JS injected: UI shows correct destination, tx silently swapped
  3. 3.Signers approve what they see — sign something else

✗ $1.5B transferred in one routine-looking operation

Stvor

Blocked at attestation

  1. 1.SHA-256(task_payload) committed at intent — immutable before UI renders
  2. 2.timingSafeEqual(received_hash, committed_hash) before execution
  3. 3.Mismatch → DENIED. Stripe PaymentIntent.cancel() if escrowed.

✓ Attacker gets nothing. No manual review required.

payload-compare.ts
import crypto from "node:crypto";

function canonicalize(params: Record<string, unknown>) {
  return JSON.stringify(params, Object.keys(params).sort());
}

function verifyPayload(
  liveParams: Record<string, unknown>,
  commitment: { payloadHash: string },
) {
  const hash = crypto.createHash("sha256")
    .update(canonicalize(liveParams))
    .digest("hex");

  const a = Buffer.from(hash, "hex");
  const b = Buffer.from(commitment.payloadHash, "hex");
  if (a.length !== b.length) return { allowed: false, reason: "PAYLOAD_MISMATCH" };
  if (!crypto.timingSafeEqual(a, b)) return { allowed: false, reason: "PAYLOAD_MISMATCH" };
  return { allowed: true };
}

03 · Counterparty trust

Signing authority is not the same as counterparty safety. Bots and agents can accumulate approvals to unknown addresses over weeks without any single transaction looking suspicious.

Attack

JaredFromSubway — $7.5M — 2024

  1. 1.66 fake token contracts mimicking WETH/USDC/USDT
  2. 2.MEV bot approved helper contracts over weeks
  3. 3.Single sweep tx drained all real balances

✗ $7.5M drained in one block

Stvor

Blocked at trust gate

  1. 1.Counterparty trust score below threshold → interaction denied
  2. 2.Outbound transfer to unverified address → DENIED before approval path
  3. 3.Every attempt logged with agent identity

✓ Bot never interacts with unverified counterparty

04 · Stripe reference flow

The live reference implementation uses Stripe capture_method: manual. Funds authorize at funding but do not capture until attestation passes. This is one rail — not the product.

OPEN→FUNDED→SUBMITTED→VERIFIED→COMPLETE
Note
See the interactive reference at nous.stvor.xyz/demo. x402 and OrbWallet integrations are planned, not live on stvor.xyz.

05 · Trust Receipt

After ALLOW, Stvor issues an ECDSA P-256 signed Trust Receipt (ATS-1 draft). Verifiable offline with only the issuer's public key. No Stvor API call required to verify a receipt you already hold.

receipt-sample.json
{
  "ats_version": "0.1.0-draft",
  "receipt_id": "ats1_01HXYZ...",
  "agent_id": "agt_finance_agent_v1",
  "decision": "ALLOWED",
  "checks": ["destination", "payload", "trust", "policy"],
  "payload_hash": "sha256:a3f7c291...",
  "committed_at": "2026-07-12T09:41:02Z",
  "executed_at": "2026-07-12T09:41:03Z",
  "signature": "ecdsa-p256:3mK9pqR2..."
}

06 · Threat model

Payload manipulation

Attacker modifies destination, amount, or calldata between intent and submission. Stvor catches this because the modified payload produces a different SHA-256 digest.

Authorization gap

Agent was authorized for operation A, submits operation B, or runs on stale authorization. Commitment binds specific fields — different operation → different hash → DENIED.

Context injection

Prompt injection causes agent to commit to a malicious operation. Policy gates and counterparty trust reduce blast radius; they do not replace human review for high-value flows.

Warning
Stvor does not solve key compromise, compromised signing infrastructure, or social engineering of human approvers who bypass the checkpoint entirely.

07 · References