> ## Documentation Index
> Fetch the complete documentation index at: https://docs.faremeter.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Facilitators

> How facilitators verify and settle x402 payments on-chain.

A facilitator is a service that sits between the resource server and the blockchain. It verifies payment proofs and settles transactions on-chain so that merchants never need to manage blockchain infrastructure directly.

## Why facilitators exist

Without a facilitator, every merchant would need to:

* Run blockchain nodes or connect to RPCs
* Verify cryptographic signatures for each payment scheme
* Submit transactions and monitor confirmations
* Handle gas fees and failed transactions

Facilitators abstract all of this. The merchant sends the payment proof to the facilitator, and the facilitator handles verification and settlement.

## How they work

```
Client                    Server                  Facilitator        Blockchain
  |                         |                         |                  |
  |--- request + payment -->|                         |                  |
  |                         |--- verify + settle ---->|                  |
  |                         |                         |--- submit tx --->|
  |                         |                         |<-- confirmation -|
  |                         |<-- settlement result ---|                  |
  |<-- 200 + resource ------|                         |                  |
```

## Facilitator API

Facilitators expose four endpoints:

| Endpoint     | Method | Purpose                                                                  |
| ------------ | ------ | ------------------------------------------------------------------------ |
| `/accepts`   | POST   | Returns enriched payment requirements (adds facilitator-specific fields) |
| `/verify`    | POST   | Verifies a payment proof without settling                                |
| `/settle`    | POST   | Verifies and settles a payment on-chain                                  |
| `/supported` | GET    | Lists supported schemes, networks, and assets                            |

### `/accepts`

The middleware calls `/accepts` with partial payment requirements (scheme, network, asset, amount, recipient, resource URL). The facilitator enriches them with blockchain-specific details needed for the client to construct a valid payment:

**Solana enrichment:**

* Fee payer address (the facilitator co-signs and pays transaction fees)
* Token decimals
* Recent blockhash

**EVM enrichment:**

* EIP-712 domain parameters: `name`, `version`, `chainId`, `verifyingContract`

The enriched requirements are cached by the middleware and returned to clients in 402 responses.

### `/settle`

When a client sends a valid payment header (`X-PAYMENT` or `PAYMENT-SIGNATURE`), the middleware forwards it to `/settle` along with the original payment requirements. The facilitator:

1. Validates the payment payload structure
2. Verifies cryptographic signatures
3. Checks amounts, addresses, and nonces
4. Submits the transaction on-chain:
   * **Solana**: Co-signs the partially-signed transaction as fee payer and submits to Solana RPC
   * **EVM**: Calls `transferWithAuthorization` on the token contract and pays gas
5. Returns `{ success: true, transaction, network }`

<Note>
  Legacy v1 implementations may return these fields as `txHash` and `networkId`. Spec-compliant v1 and v2 both use `transaction` and `network`. See [Protocol Versions](/concepts/protocol-versions) for the full mapping.
</Note>

### `/verify`

Verifies a payment proof without settling it on-chain. Useful for pre-validation before committing to settlement:

```bash theme={null}
curl -X POST https://facilitator.corbits.dev/verify \
  -H "Content-Type: application/json" \
  -d '{"paymentRequirements": {...}, "paymentPayload": {...}}'
```

Returns `{ isValid: true, payer: "..." }` on success.

### `/supported`

Returns the list of schemes, networks, and assets the facilitator supports. Use this to confirm compatibility:

```bash theme={null}
curl https://facilitator.corbits.dev/supported
```

## Default facilitator

Corbits provides a free production-ready facilitator:

```
https://facilitator.corbits.dev
```

This is the default used in faremeter's middleware and examples. It supports:

| Chain  | Networks                                                                                  |
| ------ | ----------------------------------------------------------------------------------------- |
| Solana | devnet, mainnet-beta                                                                      |
| EVM    | Base, Base Sepolia, SKALE Europa Testnet, Polygon PoS, Polygon Amoy, Monad, Monad Testnet |

Query the `/supported` endpoint for the canonical list of supported schemes, networks, and assets:

```
GET https://facilitator.corbits.dev/supported
```

## Running your own

You can run a facilitator using `@faremeter/facilitator`. See the [Facilitator guide](/server/facilitator) for setup instructions.

## In-process handlers

Facilitator handlers can also run in-process, embedded directly in the middleware. Instead of configuring a `facilitatorURL`, you pass `FacilitatorHandler` instances to the middleware via `x402Handlers`. The middleware calls them locally to resolve requirements, verify, and settle payments.

Both modes use the same `FacilitatorHandler` interface, so handlers written for one mode work in the other. See the [Middleware Overview](/server/middleware-overview) for configuration details.

## Further reading

* [Payment Schemes](/concepts/payment-schemes) -- What happens inside the facilitator for each chain.
* [Middleware](/server/middleware-overview) -- How to configure the middleware to talk to a facilitator.