RelAI Facilitator
Explore gas-sponsored x402 v2 payments on SKALE Base, Avalanche, and Solana
The facilitation process in x402 — verification and settlement of payments — is critical to ensuring the resource is paid for properly.
Why use an x402 facilitator
- Consistent verification and settlement across schemes and networks
- Offload blockchain operations and complexity from resource servers
- Serve multiple merchants/apps via a stable
/verifyand/settleAPI - Help clients discover merchants via the
/listendpoint
Architecture at a glance
- Consistent verification and settlement across schemes and networks
- Offload blockchain operations and complexity from resource servers
- Serve multiple merchants/apps via a stable
/verifyand/settleAPI - Help clients discover merchants via the
/listendpoint
Architecture at a glance
Supported Networks
RelAI Facilitator currently supports the following blockchain networks:
skale-baseavalanchebasesolanaAvailable Facilitators
| Name | Endpoint | Demo |
|---|---|---|
| RelAI | https://facilitator.x402.fi | RelAI Demo |
How It Works
Standard x402 v2 flow with gas sponsoring:
- User requests resource - GET request to protected API endpoint
- Backend returns 402 - Payment required with x402 v2 response
- User signs permit - Off-chain EIP-2612 signature (free, no gas)
- Frontend sends payment - Payment payload with signed permit
- Backend calls facilitator - /settle endpoint to execute transaction
- Facilitator executes - permit() + transferFrom() (RelAI pays CREDIT/AVAX for gas)
- Backend returns resource - 200 OK with requested data
API Reference
GET/facilitator/supported
{
"kinds": [
{ "x402Version": 2, "scheme": "exact", "network": "skale-base", "feePayer": "0x1892f72..." },
{ "x402Version": 2, "scheme": "exact", "network": "avalanche", "feePayer": "0x1892f72..." },
{ "x402Version": 2, "scheme": "exact", "network": "base", "feePayer": "0x1892f72..." },
{ "x402Version": 2, "scheme": "svm-exact", "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp", "feePayer": "4x4Zhcqi..." }
],
"extensions": [],
"signers": {
"eip155:*": ["0x1892f72fdB3A966b2AD8595aA5f7741Ef72d6085"],
"solana:*": ["4x4ZhcqiT1FnirM8Ne97iVupkN4NcQgc2YYbE2jDZbZn"]
}
}POST/facilitator/verify
{ "success": true, "verified": true }POST/facilitator/settle
{ "success": true, "txHash": "0x123...", "blockNumber": 12345678 }GET/facilitator/discovery/resources
Bazaar discovery endpoint. This returns a catalog of discovered resources.
GET /facilitator/discovery/resources?type=http&limit=20&offset=0
{
"x402Version": 2,
"items": [],
"pagination": {
"limit": 20,
"offset": 0,
"total": 0
}
}Analytics & Leaderboard (Public)
These endpoints provide ecosystem visibility based on successful settle events. They are not part of the core x402 v2 facilitator interface.
GET/facilitator/activity
GET /facilitator/activity?window=24hGET/facilitator/live-settlements
GET /facilitator/live-settlements?limit=20GET/facilitator/leaderboard
GET /facilitator/leaderboard?window=24h&limit=50What is payer?
The leaderboard ranks user wallets (payers), not the RelAI sponsor fee payer.
- EVM networks: payer is the end-user address from the payment payload (userAddress).
- Solana: RelAI sponsors fees as feePayer, but payer is extracted as the user signer from the submitted transaction.
Zauth Protection
Zauth is a trust infrastructure layer that provides endpoint verification and agent-driven testing for x402 payments. It protects users from paying for non-working or malicious endpoints by validating them before payment processing.
Pre-Payment Validation
Zauth validates target endpoints before payment processing using HEAD/GET requests with the same headers and parameters as the actual request.
Payment Protection
If validation fails, Zauth blocks payment and returns a 402 response with detailed error information, preventing funds from being charged.
Smart Validation
Uses HEAD requests for GET endpoints (lighter) and same method for POST/PUT/PATCH with full headers, query params, and body validation.
Telemetry & Monitoring
Comprehensive event tracking and monitoring for endpoint health, validation results, and payment protection statistics.
How Zauth Works
Request Interception
Zauth middleware intercepts all x402 payment requests before processing.
Endpoint Validation
Validates target URL with same method, headers, query params, and body.
Payment Decision
Allows payment if validation passes, blocks with 402 if validation fails.
User Notification
Shows detailed error modal with validation results and protection status.
Error Response Format
{
"error": "Target endpoint validation failed",
"status": 404,
"statusText": "Not Found",
"message": "Endpoint returned error before payment - payment blocked",
"x402Version": 2,
"accepts": [{
"scheme": "exact",
"network": "solana",
"maxAmountRequired": "0",
"resource": "https://api.example.com/endpoint",
"description": "Endpoint validation failed (404) - payment blocked",
"payTo": ""
}]
}Benefits
100% Payment Protection
Users never pay for non-working endpoints
Real-time Validation
Instant endpoint health checking
Developer Friendly
Easy integration with existing x402 setup
Comprehensive Monitoring
Full telemetry and analytics dashboard
Zauth Extensions
Zauth extensions allow facilitators to perform endpoint validation before payment processing. Clients can optionally include target URLs in payment payloads for pre-payment validation.
Optional Validation
Clients can optionally include targetUrl in extensions.zauth for facilitator-side validation before payment settlement.
Payment Protection
If validation fails, facilitator blocks payment with maxAmountRequired: "0" and returns detailed error information.
Standard x402 v2
Uses official x402 v2 extensions format with proper schema validation and backward compatibility.
Flexible Implementation
Facilitators can choose to implement Zauth validation or ignore extensions based on their requirements.
How It Works
Client Receives 402 with Zauth Extensions
Facilitator returns payment requirements with zauth extension info and schema.
Client Includes targetUrl in Payment
Client adds targetUrl to extensions.zauth in payment payload for validation.
Facilitator Validates Endpoint
Facilitator performs HEAD request to targetUrl before payment processing.
Payment Decision
If validation passes, continue payment. If fails, block with maxAmountRequired: "0".
Example: Client Request with Zauth
POST /verify
Content-Type: application/json
{
"x402Version": 2,
"payload": {
"authorization": "0x...",
"signature": "0x...",
"from": "0x...",
"to": "0x...",
"value": "1000000"
},
"extensions": {
"zauth": {
"targetUrl": "https://api.example.com/protected-data"
}
}
}Example: Facilitator Response (Validation Failed)
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402Version": 2,
"error": "Target endpoint validation failed",
"status": 404,
"statusText": "Not Found",
"message": "Endpoint returned error before payment - payment blocked",
"accepts": [{
"scheme": "exact",
"network": "eip155:84532",
"maxAmountRequired": "0",
"asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
"payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
"description": "Endpoint validation failed (404) - payment blocked"
}]
}Implementation Guide
For Facilitator Developers:
Check for Zauth extensions
Look for paymentPayload.extensions?.zauth?.targetUrl
Perform validation
Use HEAD request with proper headers and timeout
Block on failure
Return 402 with maxAmountRequired: "0" and error details
Continue on success
Proceed with normal verify/settle flow
Supported Facilitators
RelAI SVM
Solana (SVM) networks with Zauth extensions and targetUrl validation
RelAI EVM
EVM networks (SKALE, Avalanche, Base) with Zauth extensions and targetUrl validation
© 2026 RelAI. Monetize APIs with x402 Protocol.