> ## 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 Overview > Prepaid escrow and off-chain authorization for agentic payment flows. Flex is Faremeter's payment scheme for agentic and high-frequency workflows. Instead of a fresh on-chain transaction for every request, the client funds a prepaid escrow once, signs payment authorizations off-chain with a session key, and the facilitator settles actual usage on-chain in batches. **Scheme identifier**: `@faremeter/flex` ## Why Flex Per-request on-chain payment schemes have two fundamental problems for agentic workflows: 1. **Variable costs require upfront knowledge.** The client must know the exact payment amount before making a request. This works for fixed-price resources, but breaks down when the cost depends on request content (token count for AI inference), response content (data transfer size), or metered usage over time (streaming, long-running operations). The service either overcharges to cover the worst case or undercharges and absorbs the loss. 2. **On-chain confirmation adds latency to every request.** Each request requires a separate on-chain transaction that must confirm before the service responds. For high-frequency, low-value interactions, this per-request overhead dominates the total response time and makes the payment layer the bottleneck. Flex eliminates both problems. The payment hot path is pure compute: clients sign authorizations off-chain, the facilitator validates them in memory, and access is granted optimistically. Settlement happens asynchronously and can be batched across many requests. ## What you get * **No latency bottleneck.** Prepaid escrow accounts mean no on-chain transaction per request. Access is granted by settlement policy and actual usage is settled later. * **Pay only for what you use.** Costs are determined by real consumption, not estimates. An agent that burns 10k tokens pays for 10k tokens, not the 100k ceiling it authorized. * **Cheap at scale.** Authorizations are signed off-chain; settlements are batched on-chain. Transaction costs are amortized across many payments. * **Smart wallet native.** Session keys are registered on-chain, so smart wallets, multisigs, and custodial wallets work without per-request owner signatures. * **Split payments.** A single authorization can distribute funds across multiple recipients (platform fees, referral commissions, royalties) in one atomic settlement. * **Refund windows.** Every pending settlement has a configurable timeout before it finalizes. The facilitator can reduce or cancel during that window for failed deliveries or disputes. * **Deadman switch.** If the facilitator becomes unresponsive, the client can unilaterally recover all escrowed funds after a timeout. No trust required. ## Compared to per-request payment | Aspect | Per-Request (`exact`) | Flex (`@faremeter/flex`) | | --------------------- | ----------------------------- | ------------------------------------------ | | Payment timing | Per-request, upfront | Post-request, from prepaid balance | | Amount knowledge | Must know before request | Determined after request | | On-chain transactions | One per request | Batched settlements | | Service latency | Blocked on chain confirmation | Optimistic, settles asynchronously | | Client complexity | Build and sign transactions | Fund account once, sign authorizations | | Best fit | Fixed-price APIs | Metered usage, streaming, variable pricing | For fixed-price, low-frequency endpoints, the per-request `exact` scheme is simpler. Flex earns its complexity when costs are variable, request rates are high, or you need split payouts. ## Chain support Flex currently targets **Solana**. The on-chain program is implemented in Anchor and the client SDK is `@faremeter/flex-solana`. EVM support is planned. ## How it fits with x402 and MPP Flex is a settlement layer, not a wire protocol. It can serve as the backend for any negotiation protocol that can express a hold-and-settle flow with signed authorizations: * **x402** -- HTTP-native payment negotiation. Flex authorizations ride in the `X-PAYMENT` (v1) or `PAYMENT-SIGNATURE` (v2) header. * **MPP** -- agent-to-agent payment coordination. * Any protocol that can carry a signed authorization payload. See [How x402 works](/concepts/how-x402-works) for the negotiation flow and [Payment Schemes](/concepts/payment-schemes) for how Flex relates to the other schemes. ## Where to next Escrow accounts, session keys, splits, holds, settlement, refund window, deadman switch. Create an escrow, register a session key, sign an authorization with `@faremeter/flex-solana`. Hold lifecycle, accounting, and settlement on the operator side. On-chain program: instructions, accounts, PDAs, and timeouts.