The Facilitator connects HTTP payments to settlement on-chain. It sits between agents and the Opus Protocol contracts deployed on Robinhood Chain, taking care of verification, transaction submission, and (after payment sessions launch) session management.

The Facilitator’s job

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

1. Takes in the signed authorization from the agent
2. Checks that the agent’s wallet holds enough to cover it
3. Sends the transaction to Robinhood Chain and waits until it confirms
4. Hands the service provider a signed confirmation header
5. The provider checks that header, then serves the resource

Subscription collection is automatic and also runs through the Facilitator: at every billing cycle it calls the Opus Protocol Subscriptions contract to pull payment from subscriber wallets.

In beta: one centralized operator

For the duration of the beta, the Facilitator is a single centralized service run by Opus Protocol. That is a trust dependency, and this documentation does not hide it.

Keeping it central for now lets Opus Protocol:

• Change protocol mechanics fast
• Keep dependable uptime SLAs without also running a decentralized network
• Spot abuse and act on it at once

The cost of this is genuine. One Facilitator is one point of failure, and depending on it means trusting Opus Protocol to operate it. It does not mean handing Opus Protocol your funds. The Facilitator takes no custody. It submits transactions for agents, but the Opus Protocol contracts on-chain enforce every authorization rule, so without a valid authorization recorded on-chain the Facilitator cannot move a thing.

Post-beta: a permissionless network

Roadmap Phase 3, scheduled for Q1 2027, lets anyone run a Facilitator. An operator stakes collateral on-chain to run a node, and the stake is what keeps operators honest: a node that misbehaves or goes down forfeits it.

From then on, agents and service providers pick the Facilitator(s) they trust, whether a named set or any node in the approved pool. Nothing changes in the protocol itself; what opens up is the operator layer.

Failure modes

When the Facilitator cannot be reached

New payment requests fail with an error at the SDK layer. Existing subscriptions keep working, because their authorizations are stored on-chain and stay valid; until the Facilitator is back, collections can be made directly against the Opus Protocol Subscriptions contract.

When the Facilitator sends a bad transaction

Authorization rules live in the contracts, and the contracts apply them without input from the Facilitator. It has no power to approve a transfer above the amount authorized on-chain, to collect on a subscription that was cancelled, or to fabricate a payment proof that would pass a service provider’s verification. The chain’s record decides; the Facilitator only carries the transaction.

If Opus Protocol shuts down

The deployed Opus Protocol contracts do not depend on the company, and every subscription and allowance authorization sits on-chain. A provider can call the contracts directly to collect, with no Facilitator involved. The chain is the authoritative record.

Calling the Facilitator yourself

Most integrations never speak to the Facilitator, because the SDK does it for them. If you are building a custom integration or an alternative SDK, the Facilitator API reference is published at https://facilitator.opusprotocol.org/docs.