SANVEX logo SANVEX/ protocolv0.1.0 ↗
THE TRUST LAYER FOR AGENT COMMERCE

Secure settlement.
Unbroken trust.

SANVEX is an x402-compatible security layer that binds authorization, settlement, and service delivery into one verifiable flow.

OPEN SPECx402 COMPATIBLETESTNET
02

The verification gap

In a facilitator-mediated payment, /verify and /settle are separate operations. A valid response from the first does not guarantee that funds will move in the second.

verify(payload)  ==  valid
execute(service) ==  delivered
settle(payload)  ==  ???

SANVEX makes the unknown state explicit. A resource is released only against a bound settlement ticket and a confirmed receipt.

03

Protocol flow

STEPOPERATIONGUARANTEE
01AUTHORIZEIntent is bound to request, amount, asset, recipient, expiry.
02VERIFYConditions checked; nonce and context become single-use.
03SETTLEExact transaction simulated, bounded, and confirmed on-chain.
04DELIVERSigned receipt proves payment and service delivery.
04

Security rules

SR-01 Bind payment requirements to signed payload fields.

SR-02 Enforce freshness, nonce uniqueness, and idempotency.

SR-03 Never report success before settlement is confirmed.

SR-04 Reject zero-value and economically meaningless payments.

SR-05 Bound sponsor-paid gas and execution complexity.

SR-06 Revalidate time- and state-dependent conditions.

SR-07 Execute only allow-listed programs and instruction templates.

SR-08 Bind delivery to a signed settlement receipt.

05

Research basis

Motivated by When HTTP 402 Meets the Blockchain. The study tested 15 facilitators, found 49 rule violations and 31 previously unknown vulnerabilities.

arXiv:2607.19545 ↗
06

Implementation status

● SPECIFICATION  DRAFT
● FACILITATOR  IN DEVELOPMENT
● SDK / TEST SUITE  PLANNED
git clone https://github.com/GHOSTXrun/SANVEX.git
cd SANVEX
07

Why this project exists

x402 makes machine-to-machine commerce possible with an HTTP-native payment flow. But the facilitator sits between an HTTP request and an irreversible blockchain transaction. That boundary is where “valid” can diverge from “paid”.

Our goal is not to replace x402. SANVEX adds a verifiable safety layer that can be adopted incrementally by existing clients, resource servers, and facilitators.

08

What we reproduced

We built an isolated x402 test environment with our own merchant, client, facilitator, wallets, and testnet funds. We reproduced the failure modes described in the paper without touching third-party systems.

CASEOBSERVATIONIMPACT
A-01Replay raceOne authorization accepted by concurrent requests.
A-02Verify / settle gapService released before settlement finality.
A-03Gas abuseFailed or zero-value submissions burn sponsor fees.
A-04Payload mutationRecipient or instruction semantics diverge from intent.

Every experiment is reproducible on testnet. Attack traces, transaction hashes, and mitigations will be published with the implementation.

09

System architecture

agent ── payment intent ──▶ resource server
  │                              │
  │                         SANVEX policy
  │                              │
  └──────── settlement ticket ──▶ facilitator
                                 │
                          bounded on-chain call
                                 │
                         signed delivery receipt

SANVEX is designed as a protocol layer, not a new chain. It can run beside an existing x402 facilitator or as a self-hosted gateway. The compatibility boundary remains explicit: x402 handles negotiation; SANVEX handles proof, safety, and delivery.

10

Threat model

We model malicious clients, forged or mutated payment payloads, replay attempts, timing races, malformed chain-specific transactions, and abusive use of sponsor-paid execution.

We do not claim to solve compromised wallets, malicious merchants, colluding facilitators, or vulnerabilities in the underlying blockchain. Those are separate trust boundaries and are documented explicitly.

11

Open by design

The specification, reference facilitator, test vectors, and attack harness will be published for review. We want security researchers to challenge the rules before the protocol is used for valuable services.

● SPEC / PUBLIC DRAFT
● REPRODUCTION LAB / TESTNET
● IMPLEMENTATION / IN PROGRESS
Join the build ↗