X402 GOVERNANCE - THE POLICY LAYER FOR HTTP-NATIVE AGENT PAYMENTS

X402, BRIEFLY

x402 is an open payment protocol that reactivates HTTP status code 402 Payment Required. Pioneered by Coinbase, x402 lets any HTTP service request payment from an autonomous caller - typically an AI agent - and settle that payment in stablecoins over a supported chain.

It's a clean, chain-agnostic way to turn the web into a machine-to-machine marketplace: an agent hits an endpoint, gets a 402 back with payment details, pays, and retries with a proof.

What x402 solves:

• ▸Native, HTTP-level payment negotiation between agents and services
• ▸Stablecoin settlement with sub-cent fees (on Base and other rollups)
• ▸No accounts, no API keys, no pre-provisioned billing relationships

THE X402 STACK HAS A POLICY-SHAPED HOLE

x402 is intentionally minimal. It specifies the wire format, the payment header, and the proof - and stops there. The moment you ship an autonomous agent that can send x402 payments, you hit three problems it doesn't solve:

Hardcoding these checks into your agent works for one project and breaks the moment you scale to two. xBPP is the missing policy layer. It ships as a 600-line TypeScript SDK with zero runtime dependencies, and it works with x402 out of the box.

HOW THE TWO PROTOCOLS FIT TOGETHER

┌─────────────────────────────────────────────────────────┐
│                      AI AGENT                           │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                   xBPP evaluate()                       │
│             (policy as declarative JSON)                │
│                                                         │
│         ALLOW  ────►  continue                          │
│         BLOCK  ────►  stop + reason codes               │
│         ESCALATE ──►  pause + ask human                 │
└──────────────────────────┬──────────────────────────────┘
                           │ ALLOW
                           ▼
┌─────────────────────────────────────────────────────────┐
│                 x402 payment flow                       │
│        HTTP 402 → settle → proof → retry                │
└─────────────────────────────────────────────────────────┘

The division of concerns:

ADDING XBPP TO AN X402 FLOW

import { evaluate, balanced } from '@vanar/xbpp'

async function agentCall(url: string) {
  // 1. Evaluate the payment against your policy
  const verdict = evaluate(
    { amount: 50, currency: 'USDC', recipient: url },
    balanced
  )

  if (verdict.decision === 'BLOCK') {
    throw new Error(`Payment blocked: ${verdict.reasons.join(', ')}`)
  }

  if (verdict.decision === 'ESCALATE') {
    // Ask the user for approval
    return
  }

  // 2. ALLOW - proceed with the payment
  const response = await fetch(url)
  return response.json()
}

Three lines to add governance. Policy stays in JSON. No vendor lock-in.

12 CHECKS ACROSS 3 PRESETS

The reference SDK ships with 12 built-in policy checks and 3 opinionated presets you can use as-is or fork:

• ▸Hard cap per transaction - block anything above an absolute limit
• ▸Rolling budget window - cap spend per hour, day, or arbitrary window
• ▸Counterparty allowlist / blocklist - addresses, domains, or chain-specific patterns
• ▸Category spend limits - different budgets for different transaction types
• ▸Escalation thresholds - grey-zone amounts that require human approval
• ▸Recipient freshness - block or escalate never-seen-before recipients
• ▸Velocity limits - block suspicious bursts of activity
• ▸Currency allowlist - restrict which tokens can be spent
• ▸Chain allowlist - restrict which chains can settle
• ▸Time-of-day windows - block spending outside allowed hours
• ▸Minimum confidence - require explicit reasoning above a threshold
• ▸Signed intent verification - verify the agent's stated purpose matches the transaction

Combine any subset, version them, ship them.

WHY NOT JUST EXTEND X402?

x402 is doing one thing well - HTTP-native payment negotiation - and doing it in a way that stays minimal and widely implementable. Policy is a fundamentally different concern that varies wildly across deployments: the same x402 endpoint might be called by a $5/day consumer agent and a $50k/day enterprise agent with completely different risk profiles.

Pushing policy into x402 would either bloat the wire format or force one-size-fits-all defaults. Keeping them separate means:

X402 + XBPP FAQ