Payment verification is not payment authorization.

A cryptographically valid payment can still be unauthorized. x402Shield exists to make the authorization decision — deterministically, before a signing key is used — and to keep evidence of it afterwards. This page covers how that decision is structured and how it has been tested.

Layered architecture

The gateway reaches an authorization decision but holds no signing key. A separate authorization issuer mints a signed permit only against a durably committed authorization record. A separate external payment signer verifies that permit and re-verifies the exact transaction before producing an EIP-3009 signature. Compromising any single one of these is not sufficient to move money.

Request ↔ payment binding

Authorization is bound to the exact request it was issued for — recipient, amount, network and exact asset contract all enter the request-binding digest. A mutated or substituted field breaks the binding and the decision resolves to DENY before signing.

Deterministic policy

Authorization decisions are deterministic and auditable. No LLM sits in the decision path. Delegated authority, allowed recipients, exact asset and network, per-payment and session budgets, approval thresholds and replay state are all evaluated as deterministic checks; each produces a bounded reason code.

Measured validation

The validation campaign repeatedly found and closed real distributed-systems and isolation defects before launch. These are controlled results, not an SLA.

#TestStatusWorkloadResult
01Multi-Tenant IsolationPASS1,000,000 adversarial HTTP requests0 cross-tenant isolation violations
02Approval ConcurrencyPASS100,000 concurrent approval-resume attemptsExactly one valid consumption
03Replay ProtectionPASS1,000,000 replay attempts0 duplicate replay acceptance
04Multi-Replica IdentityPASSRestart cycles + concurrency sweep to 1,0000 internal identifier collisions
05Trust-Boundary ClosurePASS52 real separate-process boundary assertions52 / 52 checks pass, including delegation, permit and evidence integrity
06Broker Failure RecoveryIN PROGRESSReal broker outage/recovery under live trafficResults publish on completion

Protocol status

Direct x402TESTNET VERIFIED
A2A + x402TESTNET VERIFIED
AADP (delegated payment)TESTNET VERIFIED
MPPREFERENCE INTEROPERABLE

Known limitations

  • Settlement is observed as server-reported evidence only in the current build; it is never conflated with on-chain confirmation, and the evidence layer labels it as such.
  • Delegation trust is anchored at the root of a presented chain via a configured HMAC trust anchor; intermediate hops are validated structurally (subject continuity and attenuation) and can never exceed the signed root ceiling.
  • Broker failure-recovery validation under sustained live traffic is still in progress.
  • Published throughput and concurrency figures are controlled test-environment results, not a production capacity guarantee or SLA.

Full benchmark methodology →