Flex and x402 Schemes

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 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, 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 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 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 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 Flex: pre-funded escrow PDA + Ed25519-signed PaymentAuthorizations 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 — what Flex is and when to use it.
• Flex Concepts — escrows, session keys, splits, holds, settlement, refund window, deadman switch.
• Flex Facilitator — hold lifecycle and accounting on the operator side.
• Payment Schemes — where Flex sits among Faremeter’s other schemes.