> ## 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.

# Flex and x402 Schemes

> How Flex maps onto the payment schemes defined by x402-foundation/x402.

Flex is a Solana protocol with a single underlying primitive: a pre-funded escrow with off-chain signed authorizations that a registered facilitator finalizes on-chain. That one primitive projects cleanly onto several of the payment schemes defined by [x402-foundation/x402](https://github.com/x402-foundation/x402), which is the question facilitator integrators tend to ask first: "which x402 scheme is Flex?"

The short answer is that Flex covers four of them. The longer answer is below.

## Mapping

### `exact` -- Full fit

[Spec](https://github.com/x402-foundation/x402/tree/main/specs/schemes/exact)

Flex: `submit_authorization` with a single-recipient split `[{recipient, 10000bps}]` and `settleAmount == maxAmount`. Trivial degenerate case of the more general Flex authorization.

### `upto` -- Full fit

[Spec](https://github.com/x402-foundation/x402/tree/main/specs/schemes/upto)

Flex: the client signs `maxAmount`, the facilitator sets `settleAmount ≤ maxAmount` at submit time. No re-signature is needed to settle for less. Direct semantic match -- this is what Flex was built for.

### `auth-capture` -- Full fit (closest structural match)

[Spec](https://github.com/x402-foundation/x402/tree/main/specs/schemes/auth-capture)

Flex: `submit_authorization` is the auth, `finalize` is the capture, `void_pending` is the void, and `refund` reduces the captured amount within the refund window. The `captureAuthorizer` role is filled by the registered facilitator on the escrow. `captureDeadline` corresponds to `expiresAtSlot` on the authorization; `refundDeadline` corresponds to the escrow's `refund_timeout_slots`.

### `batch-settlement` -- Full fit

[Spec](https://github.com/x402-foundation/x402/tree/main/specs/schemes/batch-settlement)

Flex: pre-funded escrow PDA + Ed25519-signed `PaymentAuthorization`s acting as vouchers + multiple `submit_authorization` / `finalize` calls packed into a single Solana transaction for amortized cost. Capital-backed trust model -- the escrow is the capital.

## What Flex offers beyond x402's current schemes

* **Native multi-recipient splits** -- up to 5 recipients per authorization, basis-point weighted, signed by the client. No x402 scheme specs this today; a facilitator can expose it as a Flex-specific extension.
* **Deadman switch** -- the client can unilaterally reclaim escrowed funds after a facilitator-inactivity timeout. No x402 equivalent; this is a trust-minimization safety net.
* **Dual-sig escrow close** -- the normal close path requires both the owner and the facilitator to sign.
* **Per-escrow caps** -- `max_pending` and `max_session_keys` bound the blast radius of a compromised session key or runaway facilitator.

## Why one primitive covers four schemes

All four x402 schemes above are HTTP-layer projections of the same underlying shape: a client commits to a payment, a service does work, and a facilitator finalizes on-chain. They differ in the *timing* and *cardinality* of that finalization, not in the cryptographic substrate.

Flex's primitive -- pre-funded escrow, off-chain signed authorization, on-chain `submit_authorization` + `finalize`, with `refund` and `void_pending` as escape valves -- is rich enough that each of those schemes is a specific way of using it:

* `exact` constrains `splits` to one recipient and `settleAmount` to `maxAmount`.
* `upto` exercises the `settleAmount ≤ maxAmount` degree of freedom.
* `auth-capture` exercises the full `submit → finalize / refund / void` state machine.
* `batch-settlement` exercises packing multiple authorizations into a single transaction.

A facilitator integrating Flex into an x402 stack does not pick one mapping; it advertises whichever schemes it wants to offer and routes each to the appropriate Flex call pattern.

## See also

* [Flex Overview](/flex/overview) -- what Flex is and when to use it.
* [Flex Concepts](/flex/concepts) -- escrows, session keys, splits, holds, settlement, refund window, deadman switch.
* [Flex Facilitator](/flex/facilitator) -- hold lifecycle and accounting on the operator side.
* [Payment Schemes](/concepts/payment-schemes) -- where Flex sits among Faremeter's other schemes.