@faremeter/flex
Why Flex
Per-request on-chain payment schemes have two fundamental problems for agentic workflows:- 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.
- 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.
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 |
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) orPAYMENT-SIGNATURE(v2) header. - MPP — agent-to-agent payment coordination.
- Any protocol that can carry a signed authorization payload.
Where to next
Concepts
Escrow accounts, session keys, splits, holds, settlement, refund window,
deadman switch.
Quickstart
Create an escrow, register a session key, sign an authorization with
@faremeter/flex-solana.Facilitator
Hold lifecycle, accounting, and settlement on the operator side.
Program Reference
On-chain program: instructions, accounts, PDAs, and timeouts.