What makes x402-development notable?

2.3K downloads. Trust evidence available

How should x402-development be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

x402-development

Build internet-native payments with x402 - HTTP 402 for on-chain micropayments, no accounts or API keys. Use for paid APIs, paywalled content, agent payment flows, or per-call MCP tools. TypeScript, Python, and Go SDKs across EVM and Solana.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.3k

Updated

Oct 9, 2026

Version

0.11.3

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.3K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.3K downloadsadoption · observed Oct 9, 2026
Latest release: 0.11.3release · observed Sep 9, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17bp3v1hm1dnkzey0c9tfh02183j0y5:x402-development

Install using `clawhub skill install s17bp3v1hm1dnkzey0c9tfh02183j0y5:x402-development` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/tenequm/x402-development before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-tenequm-x402-development/snapshot"

Documentation

CLAWHUB

151,498 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: x402
description: Build internet-native payments with x402 - HTTP 402 for on-chain micropayments, no accounts or API keys. Use for paid APIs, paywalled content, agent payment flows, or per-call MCP tools. TypeScript, Python, and Go SDKs across EVM and Solana.
metadata:
  version: "0.11.3"
  categories: "finance, development"
  topics: "x402, payments, http-402, micropayments, stablecoins"
  upstream: "@x402/[email protected], @x402/[email protected], [email protected], github.com/x402-foundation/x402/go/[email protected]"
  openclaw:
    homepage: https://github.com/tenequm/skills/tree/main/skills/x402
    emoji: "💰"
    primaryEnv: EVM_PRIVATE_KEY
    envVars:
      - name: EVM_PRIVATE_KEY
        required: false
        description: EVM signer key for x402 client/server.
      - name: SVM_PRIVATE_KEY
        required: false
        description: Solana signer key for x402 client/server.
      - name: APTOS_PRIVATE_KEY
        required: false
        description: Aptos signer for x402 on Aptos.
      - name: API_KEY
        required: false
        description: Example upstream bearer token used in lifecycle hook examples.
      - name: FACILITATOR_KEY
        required: false
        description: Self-hosted facilitator signing key.
      - name: FACILITATOR_URL
        required: false
        description: Facilitator endpoint URL override.
---

# x402 Protocol Development

x402 is an open standard (Apache-2.0) that activates the HTTP `402 Payment Required` status code for programmatic, on-chain payments. Originally created by Coinbase, now maintained by the [x402 Foundation](https://github.com/x402-foundation/x402). No accounts, sessions, or API keys required - clients pay with signed crypto transactions directly over HTTP.

## When to Use

- Building a **paid API** that accepts crypto micropayments
- Adding **paywall** to web content or endpoints
- Enabling **AI agents** to autonomously pay for resources
- Integrating **MCP tools** that require payment
- Building **agent-to-agent** (A2A) payment flows
- Working with **EVM** (Base, Ethereum, MegaETH, Monad, Polygon, Stable, Arbitrum), **Solana**, **Stellar**, **Aptos**, **NEAR**, or **XRPL** payment settlement
- Implementing **usage-based billing** with the `upto` scheme (LLM tokens, bandwidth, compute)
- Running an **in-process facilitator** (self-facilitation) without external facilitator dependency

## Core Architecture

Three roles in every x402 payment:

1. **Resource Server** - protects endpoints, returns 402 with payment requirements
2. **Client** - signs payment authorization, retries request with payment header
3. **Facilitator** - verifies signatures, settles transactions on-chain

Payment flow (HTTP transport):
```
Client -> GET /resource -> Server returns 402 + PAYMENT-REQUIRED header
Client -> signs payment -> retries with PAYMENT-SIGNATURE header
Server -> POST /verify to Facilitator -> POST /settle to Facilitator
Server -> returns 200 + PAYMENT-RESPONSE header + resource data
```

## Quick Start:

_meta.json

{
  "ownerId": "kn76gpsgjw5chv0xvzbzcb8cxn81x46r",
  "slug": "x402-development",
  "version": "0.11.3",
  "publishedAt": 1788948930133
}

references/aptos-scheme.md

# Aptos Exact Scheme Reference

The `exact` scheme on Aptos uses native Fungible Asset transfers with optional fee payer (gas) sponsorship by the facilitator.

## SDK Support

| SDK | Status |
|-----|--------|
| TypeScript (`@x402/aptos`) | Full support (client, server, facilitator) |
| Go | Not supported |
| Python | Not supported |

Install: `npm install @x402/aptos`

## Network Identifiers

| Network | CAIP-2 ID | Chain ID |
|---------|-----------|----------|
| Aptos Mainnet | `aptos:1` | 1 |
| Aptos Testnet | `aptos:2` | 2 |

## Supported Tokens

Any Aptos fungible asset. Default: USDC (6 decimals). Use the USDC contract address for the target network.

Address format: 64 hex characters with `0x` prefix (regex: `/^0x[a-fA-F0-9]{64}$/`).

## Protocol Flow

1. Client requests protected resource
2. Server returns `402` with PaymentRequirements (includes `extra.feePayer` if gas sponsored)
3. Client builds fee payer transaction using `0x1::primary_fungible_store::transfer` (or `0x1::fungible_asset::transfer`)
4. Client signs transaction (signature covers payload only, NOT fee payer address)
5. Client serializes via BCS encoding, Base64 encodes, sends in `PAYMENT-SIGNATURE` header
6. Server forwards to facilitator for verification
7. Facilitator validates structure, signature, and payment details
8. Server performs work, then requests settlement from facilitator
9. Facilitator adds fee payer signature (if sponsored) and submits to Aptos
10. Server returns response with `PAYMENT-RESPONSE` header

## PaymentRequirements

```json
{
  "scheme": "exact",
  "network": "aptos:1",
  "amount": "1000000",
  "asset": "<APTOS_USDC_MAINNET>",
  "payTo": "<APTOS_RECIPIENT_ADDRESS>",
  "maxTimeoutSeconds": 60,
  "extra": {
    "feePayer": "<APTOS_FEE_PAYER_ADDRESS>"
  }
}
```

- `extra.feePayer`: If present, facilitator pays gas. If absent, client pays own gas.

## Verification Rules

Facilitator verification:
1. Verify x402Version is 2
2. Verify scheme is "exact"
3. Verify network matches (CAIP-2)
4. For sponsored tx: verify fee payer is managed by facilitator
5. Deserialize BCS-encoded transaction and verify the signature **cryptographically**. This MUST NOT rely on transaction simulation, which substitutes an invalid dummy signature and never checks the submitted one
6. Verify chain ID matches expected network
7. Verify sender's public key matches derived address
8. For sponsored tx: verify max gas <= 500,000 units (prevent gas drain)
9. For sponsored tx: verify fee payer address matches
10. Verify sender != fee payer
11. Verify transaction not expired (5-second buffer)
12. Verify contains fungible asset transfer (`0x1::primary_fungible_store::transfer` or `0x1::fungible_asset::transfer`)
13. Verify transfer targets correct asset address
14. Verify transfer amount matches exactly
15. Verify transfer recipient matches exactly
16. Verify sender has sufficient balance
17. Simulate transaction

## Supported Signature Schemes

- Ed25519 (single, most common)
- Mult

references/core-concepts.md

# Core Concepts

## HTTP 402 - The Foundation

HTTP 402 Payment Required is a standard but historically dormant HTTP status code. x402 activates it to enable frictionless, API-native payments for:

- Machine-to-machine (M2M) payments (AI agents)
- Pay-per-use models (API calls, paywalled content)
- Micropayments without account creation or traditional payment rails

Using 402 keeps the protocol natively web-compatible and easy to integrate into any HTTP-based service. No new protocols, no special infrastructure - just HTTP.

### V2 Payment Headers

| Header | Direction | Encoding | Content |
|--------|-----------|----------|---------|
| `PAYMENT-REQUIRED` | Server to Client | Base64 JSON | PaymentRequired object |
| `PAYMENT-SIGNATURE` | Client to Server | Base64 JSON | PaymentPayload with signed authorization |
| `PAYMENT-RESPONSE` | Server to Client | Base64 JSON | SettlementResponse with tx hash |

Both headers must be valid Base64-encoded JSON strings for cross-implementation compatibility.

### V1 to V2 Header Migration

| V1 Header | V2 Header |
|-----------|-----------|
| `X-PAYMENT` | `PAYMENT-SIGNATURE` |
| `X-PAYMENT-RESPONSE` | `PAYMENT-RESPONSE` |

## Client / Server Roles

### Client (Buyer)

The entity requesting access to a paid resource. Can be:
- Human-operated applications
- Autonomous AI agents
- Programmatic services acting on behalf of users

**Responsibilities:**
1. Send HTTP request to resource server
2. Handle 402 response and extract payment details
3. Construct a valid payment payload (sign authorization)
4. Retry request with `PAYMENT-SIGNATURE` header

Clients do not need accounts, credentials, or session tokens beyond their crypto wallet. All interactions are stateless and occur over standard HTTP.

### Server (Seller)

The resource provider enforcing payment for access. Can be:
- API services
- Content providers
- Any HTTP-accessible resource requiring monetization

**Responsibilities:**
1. Define payment requirements per route
2. Respond with 402 + `PAYMENT-REQUIRED` header when no valid payment is attached
3. Verify incoming payment payloads (locally or via facilitator)
4. Settle transactions on-chain
5. Return the resource on successful payment

Servers do not need to manage client identities or maintain session state. Verification and settlement are handled per request.

#### Duplicate Settlement on Solana

If your server settles payments directly on Solana (without a facilitator), a race condition exists: the same signed payment can be submitted multiple times before on-chain confirmation. Solana's RPC returns "success" for each submission.

Mitigation: maintain a short-lived in-memory cache of transaction payloads being settled. Reject duplicates with `"duplicate_settlement"` error. Evict entries after 120 seconds. If using a facilitator, the SVM libraries include built-in `SettlementCache` protection.

#### Optimistic Settlement: Data Served Before On-Chain Confirmation

x402 is optimistic by design: the serve

references/evm-scheme.md

# EVM Scheme Reference

## Schemes Overview

| Scheme | Description |
|--------|-------------|
| **exact** | Transfers a fixed amount; facilitator pays gas, client controls fund flow via signatures |
| **upto** | Usage-based; client authorizes a max, facilitator settles actual amount consumed |

Both schemes use Permit2 as their foundation. The `exact` scheme additionally supports EIP-3009 for compatible tokens.

## Asset Transfer Methods (Exact Scheme)

| Method | Use Case | Recommendation |
|--------|----------|----------------|
| **EIP-3009** | Tokens with native `transferWithAuthorization` (e.g., USDC) | Recommended (simplest, truly gasless) |
| **Permit2** | Any ERC-20 token | Universal fallback |
| **ERC-7710** | Smart accounts with delegation support | Smart account option |

If no `assetTransferMethod` is specified in payload `extra`, implementations prioritize `eip3009` first, then `permit2`.

## Proxy Contracts

Both schemes use deterministic CREATE2-deployed proxy contracts:

| Contract | Address | Purpose |
|----------|---------|---------|
| `x402ExactPermit2Proxy` | `0x402085c248EeA27D92E8b30b2C58ed07f9E20001` | Exact-amount Permit2 settlement |
| `x402UptoPermit2Proxy` | `0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002` | Variable-amount Permit2 settlement |
| Permit2 (canonical) | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | Uniswap Permit2 |
| Multicall3 | `0xcA11bde05977b3631167028862bE2a173976CA11` | Batched reads |

Both proxy contracts inherit `x402BasePermit2Proxy` which provides shared logic: reentrancy guard, `_settle()` internal, `_executePermit()` for EIP-2612, and common error types (`InvalidAmount`, `InvalidDestination`, `InvalidOwner`, `PaymentTooEarly`, `Permit2612AmountMismatch`).

### Exact Proxy Witness

```solidity
struct Witness { address to; uint256 validAfter; }
```

Always transfers the exact `permit.permitted.amount`.

### Upto Proxy Witness

```solidity
struct Witness { address to; address facilitator; uint256 validAfter; }
```

Adds `facilitator` field - only `msg.sender == witness.facilitator` can settle. Settles for any `amount <= permit.permitted.amount`.

## Method 1: EIP-3009 (Exact Only)

Uses `transferWithAuthorization` directly on compatible token contracts (like USDC).

### EIP-712 Authorization Types

```javascript
const authorizationTypes = {
  TransferWithAuthorization: [
    { name: "from", type: "address" },
    { name: "to", type: "address" },
    { name: "value", type: "uint256" },
    { name: "validAfter", type: "uint256" },
    { name: "validBefore", type: "uint256" },
    { name: "nonce", type: "bytes32" },
  ],
};
```

### EIP-3009 Verification

1. Verify EIP-712 signature recovers to `authorization.from` (supports EOA, EIP-1271 smart wallets, ERC-6492 counterfactual)
2. Verify payer has sufficient token balance
3. Verify `authorization.value` exactly matches required amount
4. Verify `validBefore > now + 6s` and `validAfter <= now`
5. Verify recipient and token/network match requirements
6

Github ReposUpdated 4h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.