The Facilitator is the component in the Recur stack responsible for bridging the HTTP payment layer with on-chain settlement. It sits between agents and the Solana programs, handling verification, transaction submission, and (in the future) payment session management.

What the Facilitator does

When an agent authorizes a payment or subscription, the Facilitator:

1. Receives the signed authorization from the agent
2. Verifies the agent’s wallet has sufficient balance for the requested operation
3. Submits and confirms the Solana transaction
4. Returns a signed confirmation header to the service provider
5. The service provider validates this header before serving the resource

For subscriptions, the Facilitator also handles automatic collection at each billing cycle — calling the Solana Subscriptions and Allowances Program to pull funds from subscriber wallets.

Beta: centralized operation

During beta, Recur operates the Facilitator as a single, centralized service. This is explicitly acknowledged as a trust dependency and is disclosed clearly in the protocol documentation.

Centralizing the Facilitator during beta allows Recur to:

• Ship faster and iterate on the protocol mechanics
• Maintain reliable uptime SLAs without the complexity of a decentralized network
• Monitor for abuse patterns and respond quickly

The tradeoffs are real: a centralized Facilitator is a single point of failure and requires trusting Recur as an operator. Recur does not take custody of funds — the Facilitator submits transactions on behalf of agents, but the Solana programs enforce authorization rules. The Facilitator cannot move funds without valid on-chain authorization.

Post-beta: permissionless Facilitator Network

The roadmap for Phase 3 (Q1 2027) introduces a permissionless Facilitator Network. Any operator will be able to run a Facilitator node by staking collateral on-chain. The staking requirement creates economic accountability — a Facilitator that behaves maliciously or goes offline loses its stake.

Recur agents and service providers will be able to specify which Facilitator(s) they trust, or accept any Facilitator from the approved set. The protocol layer remains the same; only the operator of the Facilitator changes.

Failure modes

Facilitator is unavailable

If the Facilitator is unreachable, payment requests return an error at the SDK layer. Active subscriptions are not affected — their on-chain authorizations remain valid and can be collected against directly via the Solana program when the Facilitator comes back online.

Facilitator submits an incorrect transaction

The Solana programs enforce authorization rules independently of the Facilitator. A Facilitator cannot authorize a transfer that exceeds the on-chain authorized amount, cannot collect from a cancelled subscription, and cannot fabricate a payment proof that a service provider’s verification would accept. The on-chain program is the enforcer.

Recur as an operator goes away

Because all subscription and allowance authorizations are on-chain, the Solana programs remain operational regardless of Recur’s status as a company. Funds can still be collected by service providers by calling the Solana program directly, without going through Recur’s Facilitator. The on-chain state is the source of truth.

Interacting with the Facilitator directly

Most integrations will not need to interact with the Facilitator directly — the SDK handles it. If you are building a custom integration or an alternative SDK implementation, the Facilitator API is documented at https://facilitator.recurprotocol.com/docs.