BlockPay

Autonomous payment infrastructure for AI agents, machines, and humans — built on the x402 standard and Sui Network.

Version: 1.0 — March 2026 Network: Sui Mainnet Standard: x402 (HTTP 402 Payment Required) Facilitator: BlockPay Facilitator Settlement Asset: USDC, SUI, USDSUI, suiUSDT


triangle-exclamation

1. Introduction & Vision

What is BlockPay?

BlockPay is an autonomous payment infrastructure built on the x402 open standard. It enables AI agents, machines (IoT, software bots), and human users to transact over plain HTTP — without accounts, API keys, subscriptions, or traditional payment processors.

The core thesis is simple: HTTP can already carry data. BlockPay makes it carry value.

Since the early 1990s, HTTP has reserved status code 402 Payment Required for "future use." That future is now. The x402 protocol reactivates this dormant code so that any HTTP endpoint can demand and receive cryptographic payment in a single request cycle — settling on-chain in under one second.

Who is BlockPay for?

Why BlockPay exists

The legacy payment stack was built for humans. It fails for machines:

Problem
Legacy Rails
BlockPay / x402

Minimum viable payment

~$0.30 (credit card floor fee)

$0.0001 (limited only by gas)

Account / signup required

Yes

No

Machine-to-machine support

No

Yes — first-class

Settlement time

1–3 business days

< 1 second

Chargeback risk

Yes

No (blockchain finality)

Global access

Restricted by country

Permissionless

API key management

Required

Not needed — payment IS authorization


2. Core Concepts & Terminology

2.1 Glossary

Term
Definition

x402

An open payment protocol that reactivates HTTP status code 402 Payment Required. Servers reply with payment terms; clients pay with a signed blockchain transaction and retry.

HTTP 402

HTTP status code reserved in 1991 for "Payment Required." x402 finally implements it.

Facilitator

A service that verifies signed x402 payment payloads and settles transactions on-chain. It never holds funds. BlockPay ships its own built-in facilitator (@blockpay/facilitator).

Merchant (Resource Server)

Any HTTP server that has added x402 payment middleware to one or more endpoints.

Client (Buyer)

The agent, machine, or human making the HTTP request and paying for the resource.

ERC-8004

An on-chain agent identity standard (ERC-721 NFT) providing verifiable identity, reputation, and capability metadata for AI agents.

BlockPay Facilitator

BlockPay's own facilitator service — handles x402 payment verification, nonce tracking, and USDC settlement on Sui and other supported networks.

USDC

USD Coin — the primary settlement asset. A regulated, audited stablecoin issued by Circle.

Sui Object

The fundamental unit of state on Sui blockchain. Every asset, credential, and agent identity is an independent owned object — enabling parallel transaction execution.

PTB

Programmable Transaction Block — Sui's atomic multi-step transaction primitive. Multiple operations in a single on-chain transaction.

EIP-712

Ethereum Improvement Proposal for typed structured data signing. Used by x402 payment payloads to create cryptographically verifiable payment intents.

EIP-3009 / TransferWithAuthorization

Token transfer method enabling gasless USDC transfers via an off-chain cryptographic signature. The foundation of x402's exact payment scheme.

CAIP-2

Chain Agnostic Improvement Proposal for standard chain identifiers (e.g., sui:mainnet, eip155:8453 for Base).

Scheme

In x402, the payment method type. exact = fixed amount per request. upto = consume up to a maximum. session = pre-pay for a time window.

MCP

Model Context Protocol — an open standard for connecting LLMs to external tools. BlockPay services can be exposed as MCP tools.

A2A

Agent-to-Agent — direct, autonomous transactions between two AI agents with no human in the loop.

2.2 Protocol Stack


3. System Architecture

3.1 High-Level Architecture

3.2 Component Roles

Component
Role
Technology

BlockPay Middleware

Intercepts HTTP requests; returns 402 if no payment; verifies payment response

@blockpay/middleware (Express / Hono / Next.js / Flask)

BlockPay Client SDK

Handles 402 detection, payload signing, and retry automatically

@blockpay/client (TS / Python / Go)

BlockPay Facilitator

Verifies payment payload signatures; broadcasts USDC transfer on-chain

@blockpay/facilitator

ERC-8004 Registry

On-chain agent identity NFTs — verifiable credentials for agents

Sui Move smart contract

BlockPay Dashboard

Merchant analytics: payment volume, per-endpoint revenue, agent activity

React + TimescaleDB


4. x402 Payment Protocol — Deep Dive

4.1 The Origin Story

HTTP status code 402 Payment Required was reserved in RFC 1945 (1996). For 30 years it sat unused — a placeholder for a payment layer that never arrived because digital money infrastructure didn't exist.

In May 2025, Coinbase revived it through the x402 protocol, backed by Cloudflare, Anthropic, Google, and AWS. By August 2025, x402 had processed over 100 million transactions. BlockPay is built on this open standard.

4.2 The Full Payment Handshake

1

STEP 1 — Client makes a normal HTTP request

────────────────────────────────────────────

GET /api/data HTTP/1.1 Host: merchant.example.com

2

STEP 2 — Server responds with HTTP 402 + payment terms

────────────────────────────────────────────────────────

HTTP/1.1 402 Payment Required Content-Type: application/json X-PAYMENT-REQUIRED:

Decoded X-PAYMENT-REQUIRED: { "x402Version": 1, "accepts": [{ "scheme": "exact", "network": "sui:mainnet", "maxAmountRequired": "1000", "asset": "0xUSCD_CONTRACT_ADDRESS", "payTo": "0xMERCHANT_WALLET", "description": "Market data — per request", "resource": "/api/data", "mimeType": "application/json" }] }

↑ Client now knows: exactly how much, in what token, on which network, to which wallet.

3

STEP 3 — Client signs a payment authorization (EIP-712 / Ed25519)

────────────────────────────────────────────────────────────────────

⚠️ This is a SIGNATURE, not a broadcast. No gas is spent yet. No transaction on-chain yet. It is a cryptographic promise: "I authorize this transfer."

4

STEP 4 — Client retries the request with the signed payload

─────────────────────────────────────────────────────────────

GET /api/data HTTP/1.1 Host: merchant.example.com X-PAYMENT:

Decoded X-PAYMENT: { "x402Version": 1, "scheme": "exact", "network": "sui:mainnet", "payload": { "signature": "0x...", "authorization": { "from": "0xCLIENT_WALLET", "to": "0xMERCHANT_WALLET", "value": "1000", "validAfter": "1710000000", "validBefore": "1710000060", "nonce": "0x" } } }

5

STEP 5 — Merchant forwards to BlockPay Facilitator for verification

────────────────────────────────────────────────────────────────────

POST https://facilitator.blockpay.xyz/verify { "paymentPayload": , "paymentRequirements": <from step 2> }

BlockPay Facilitator checks: ✓ Signature is valid ✓ Amount matches requirement ✓ Nonce has not been used before ✓ Authorization window is still valid (validAfter / validBefore) ✓ Recipient address matches payTo

6

STEP 6 — Facilitator settles on-chain

────────────────────────────────────────

BlockPay Facilitator broadcasts the USDC TransferWithAuthorization transaction to the Sui network.

Settlement time: ~400ms Result: { valid: true, txHash: "0x...", network: "sui:mainnet" }

7

STEP 7 — Merchant delivers the resource

──────────────────────────────────────────

HTTP/1.1 200 OK X-PAYMENT-RESPONSE:

{ "marketData": { ... } }

4.3 Data Types

Payment Requirements Response (402)

Payment Payload (X-PAYMENT header)

Settlement Response (X-PAYMENT-RESPONSE header)

4.4 Payment Schemes

Scheme
Description
Best for

exact

Fixed USDC amount per request

API calls, content access, per-use services

upto

Up to a maximum — actual amount based on consumption

LLM token billing, variable-cost compute

session

Pay once, get a reusable session token

Repeated calls within a time window

batch

Bundle multiple requests in a single payment authorization

High-frequency agent pipelines

4.5 Error Codes

Error Code
Meaning

insufficient_funds

Client wallet has insufficient USDC

invalid_exact_evm_payload_signature

Signature is malformed or wrong signer

invalid_exact_evm_payload_authorization_valid_before

Payment authorization has expired

invalid_exact_evm_payload_authorization_valid_after

Payment not yet valid

invalid_exact_evm_payload_authorization_value

Amount is below requirement

invalid_exact_evm_payload_recipient_mismatch

to address does not match payTo

unsupported_scheme

Facilitator does not support the requested payment scheme

invalid_x402_version

Protocol version mismatch

unexpected_verify_error

Internal facilitator error during verification

4.6 Replay Attack Protection

x402 implements multiple defense layers:


5. ERC-8004 Agent Identity Standard

5.1 Overview

ERC-8004 is an open standard for trustless AI agent identity on blockchain. Published by the Ethereum Foundation and Consensys in October 2025, it provides three on-chain registries that together give AI agents a verifiable, portable, censorship-resistant identity — the equivalent of a passport and credit history for software.

BlockPay uses ERC-8004 as the identity layer for all AI agents transacting on the platform.

5.2 Three-Registry Architecture

5.3 Agent Identity Object (Sui Move)

On BlockPay's Sui deployment, ERC-8004 identity maps to a native Sui owned object:

5.4 Off-Chain Agent Descriptor (agent.json)

Each agent hosts a /.well-known/agent.json file linked from the on-chain identity:

5.5 Reputation Flow


6. BlockPay Facilitator — The Settlement Layer

6.1 What a Facilitator Does

In the x402 protocol, a facilitator is the trust infrastructure that sits between merchant and blockchain. It is a stateless verification and settlement service — not a custody provider:

  1. Receives the signed payment payload forwarded by the merchant's server

  2. Verifies all cryptographic signatures and constraints

  3. Confirms the nonce has not been used before (replay protection)

  4. Broadcasts the TransferWithAuthorization call to the target chain

  5. Returns a settlement receipt containing the on-chain transaction hash

Critically: the facilitator never holds, custodies, or controls funds. It only validates the client's pre-authorized intent and triggers the corresponding on-chain transfer.

6.2 BlockPay Facilitator Architecture

6.3 Facilitator API

The BlockPay Facilitator exposes two endpoints that the x402 middleware calls automatically:

POST /verify — Validate a payment payload without settling

POST /settle — Verify and broadcast the on-chain transaction

6.4 Supported Networks

Network
Chain ID
Status
Notes

Sui

sui:mainnet

✅ Primary

BlockPay's default network

Sui Testnet

sui:testnet

✅ Testnet

Development / testing

Solana

solana:mainnet

✅ Live

SVM USDC

Solana Devnet

solana:devnet

✅ Testnet

Development / testing

Base

eip155:8453

✅ Live

EVM USDC

Base Sepolia

eip155:84532

✅ Testnet

Development / testing

Polygon

eip155:137

✅ Live

Avalanche

eip155:43114

✅ Live

6.5 BlockPay Echo Merchant — Test Without Deploying

BlockPay ships a live Echo Merchant for end-to-end integration testing. It behaves exactly like a real merchant — advertising payment requirements, verifying your payload, settling on-chain — but refunds all payments immediately so testing costs nothing.

6.6 Facilitator Credentials

Tier
Volume
Facilitator fee

Free tier

First 1,000 settlements

$0

Standard

> 1,000 settlements

$0.001 per settlement

Note: Facilitator fees are separate from on-chain gas (Sui gas ≈ $0.0001 per transaction).


7. Why Sui Network

7.1 The Fundamental Problem with Account-Based Chains

Traditional blockchains (Ethereum, Solana) serialize transactions against a global state tree. Every transaction — even if it touches completely different assets — must be ordered and sequenced through consensus. This creates a throughput ceiling that is fundamentally incompatible with millions of daily AI agent micropayments.

7.2 Sui's Object-Centric Model

Sui's breakthrough is treating every asset as an independent owned Object. If two transactions touch different objects, they can execute in parallel — no waiting, no bottleneck.

7.3 Why This Matters for BlockPay

Property
Sui Value
BlockPay Impact

Transaction finality

~400ms

HTTP request round-trip completes before client timeout

Throughput

100,000+ TPS

Supports platform-scale A2A payment volume

Gas fee

< $0.001 per tx

Makes $0.001 micropayments economically viable

Parallel execution

Native object model

Thousands of agent payments execute simultaneously

PTBs

Atomic multi-step tx

Split payments + state update + NFT mint in one tx

Move language

Linear type system

Double-spend impossible at compile time

Owned objects

First-class

Agent identity NFT + stake live in one owned object

7.4 Move Language — Safety by Design

Move's linear type system makes digital assets behave like physical resources: they cannot be accidentally copied, duplicated, or destroyed. This directly prevents an entire class of re-entrancy and double-spend bugs.

Compare to Solidity, where a missing reentrancy guard caused the DAO hack ($60M, 2016) and numerous subsequent exploits.

7.5 Comparison Table


8. BlockPay Modules

8.1 Module Map

8.2 Payment Flow States

8.3 Revenue Splitting (Sui PTB)

BlockPay supports configurable revenue splitting — a single payment is atomically distributed to multiple recipients in one on-chain transaction:


9. SDK & Integration Guide

9.1 Installation

9.2 Quick Start — Merchant (Sell a service)

Express.js

Hono (Edge / Cloudflare Workers)

Flask (Python)

9.3 Quick Start — Client (Pay for a service)

TypeScript

Python (httpx)

Go

9.4 Agent Registration (ERC-8004 Identity)

9.5 MCP Server Integration

Expose BlockPay-protected services as MCP tools — discoverable by Claude, GPT-4, and any other MCP-compatible agent:

9.6 Environment Variables Reference


10. End-to-End Flow Examples

10.1 AI Agent Calls a Paid API

10.2 IoT Device Auto-Pays for Data Feed

10.3 Human Pays to Access Premium Content

10.4 Agent Hires Another Agent (A2A)


11. Deployment & Infrastructure

11.2 Docker Compose (Local Development)

11.3 Database Schema — Payment Ledger


12. Security Model

12.1 Payment Security

Threat
Attack Vector
Defense

Replay attack

Re-submitting a captured payment payload

Unique nonce per payment; validBefore TTL (typically 60s); BlockPay Facilitator nonce registry

Overpayment extraction

Merchant demands more than stated

maxAmountRequired is in the signed payload; client SDK enforces maxBudget

Underpayment

Client signs for less than required

Facilitator validates value >= maxAmountRequired before settling

Man-in-the-middle

Intercept and swap payTo address

payTo address is embedded in the EIP-712 signature; any modification invalidates the signature

Double-spend

Try to use the same signed payload twice

Nonce uniqueness enforced at Sui contract level (EIP-3009 TransferWithAuthorization)

Facilitator compromise

Facilitator goes rogue

Facilitator never holds funds; it only calls pre-authorized transfers the client already signed

Signature forgery

Create a valid-looking payload

Ed25519 / ECDSA — computationally infeasible without private key

12.2 Agent Safety Controls

AI agents operating autonomously with access to a funded wallet require explicit spending guardrails:

12.3 Network Security

  • All x402 communication occurs over HTTPS (TLS 1.3+)

  • Payment payloads are cryptographically signed — cannot be tampered with in transit

  • Facilitator endpoints are rate-limited and authenticated via API key in production

  • Redis nonce cache TTL = validBefore timestamp + 5 minute buffer

12.4 Operational Security

  • Merchant private keys should be stored in HSM or secrets manager (AWS Secrets Manager, HashiCorp Vault)

  • Agent wallet keys on edge hardware should use secure enclaves where available

  • Rotate facilitator API keys on a scheduled basis

  • Monitor payment volume anomalies — unexpected spikes may indicate compromised agent wallets


13. Roadmap

Phase 1 — Foundation (Q2 2026)

Phase 2 — Agents & Machines (Q3 2026)

Phase 3 — Ecosystem (Q4 2026)


Resource
URL

x402 Protocol Spec

https://x402.org

x402 GitHub (Coinbase)

https://github.com/coinbase/x402

x402 V2 Announcement

https://www.x402.org/writing/x402-v2-launch

| ERC-8004 Specification | https://eips.ethereum.org/EIPS/eip-8004 | | Sui Documentation | https://docs.sui.io | | Sui Move Book | https://move-book.com | | Mysten Labs | https://mystenlabs.com | | Coinbase CDP x402 Docs | https://docs.cdp.coinbase.com/x402/welcome | | EIP-3009 Specification | https://eips.ethereum.org/EIPS/eip-3009 |


Appendix A: Quick Reference — HTTP Status Codes

Code
Meaning in x402 context

200 OK

Payment verified and resource delivered

402 Payment Required

Resource requires payment — includes X-PAYMENT-REQUIRED header

400 Bad Request

Malformed payment payload

401 Unauthorized

Invalid payment signature

402 + error body

Payment failed — see error field for specific error code

500 Internal Server Error

Facilitator or settlement error

Appendix B: Glossary Quick Reference

Abbreviation
Full Term

A2A

Agent-to-Agent

CAIP

Chain Agnostic Improvement Proposal

EIP

Ethereum Improvement Proposal

HSM

Hardware Security Module

IoT

Internet of Things

M2M

Machine-to-Machine

MCP

Model Context Protocol

PTB

Programmable Transaction Block (Sui)

TPS

Transactions Per Second

TTL

Time To Live

USDC

USD Coin (Circle stablecoin)

zkML

Zero-Knowledge Machine Learning


circle-info

BlockPay is open-source infrastructure. Contributions, issue reports, and feedback are welcome. The x402 standard is maintained by the x402 Foundation. BlockPay is an independent implementation built on top of it.


BlockPay Technical Documentation — v1.0 — March 2026 Built on x402 open standard · Settled on Sui

Last updated