Skip to main content
Agon supports an operator hub model on top of the base protocol. In this model, users open payment channels to a hub, providers open payment channels with that same hub, and the hub handles payment flow between both sides. The hub can enforce its own pricing, compliance, and routing logic, while settlement still happens through Agon’s protocol state.

​
The shape

Instead of every user opening a direct channel to every provider, the payment graph looks like this: 
user → hub
hub  → provider
This is useful when one operator wants to coordinate access, billing, and settlement for many users and many providers.

​
How a hub works

The hub becomes the party that:
  1. receives signed payment updates from users
  2. decides whether to honor or reject a request
  3. serves the request directly or forwards it to a provider
  4. signs outbound payment updates to providers
  5. settles both sides later through normal Agon settlement
The hub is doing payment coordination. Balances still live in protocol state.

​
Why it fits Agon

Agon does not do Lightning-style multi-hop routing. It does have the primitives that a hub needs:
  1. permanent participant identities
  2. permanent one-way payment channels
  3. cumulative commitments
  4. payee-side bundle settlement
  5. cooperative clearing when several participants want to co-sign one shared update
A hub can be built entirely on top of these primitives — no protocol changes required.

​
Worked example

Alice wants to pay an RPC provider through a hub.
  1. Alice has a channel to the hub.
  2. The provider has a channel from the hub.
  3. Alice signs a cumulative commitment increasing what she owes the hub.
  4. The hub checks Alice’s balance, channel lock, policy rules, and rate limits.
  5. The hub serves the RPC call (or forwards it to the provider).
  6. The hub signs a cumulative commitment increasing what it owes the provider.
  7. Later, the hub settles inbound and outbound channels through normal Agon settlement.

​
Operating models

​
Guaranteed-capacity

If the spending side locks enough funds to the channel, the receiving side has guaranteed payment capacity on that relationship. The hub operates the service layer, but it does not need off-chain custody to make the payment valid.

​
Trust-minimized

If only partial expected usage is locked — or if balances are mostly shared rather than locked per channel — the model becomes trust-minimized. The payee takes more timing and credit risk between settlements, but the protocol is still non-custodial.

​
Credit

If the hub extends credit in either direction, the trust surface grows. Balances continue to live non-custodially in protocol state, but the hub’s business logic is now bearing risk and liquidity exposure.

​
What the hub controls (and what it does not)

A hub can still control service access. It can:
  1. deny service
  2. delay forwarding
  3. require additional lockup
  4. choose which providers it will work with
That is not a protocol bug — it is the service-layer business model of the hub. The important distinction is that service control and settlement control are no longer the same thing. A hub can be picky about who it serves without becoming the only path to settle. Users and providers can choose different hubs, use direct channels, or mix both.

​
Operator payment is separate

A hub is an economic participant like any other. If a hub should be paid, that payment should be modeled as its own ordinary channel commitment — typically:
  • payer → hub for access
  • hub → provider for fulfillment
This keeps hub compensation cumulative and durable instead of stuffing a fee into a unilateral commitment meant for a different relationship. It also lets the hub’s inbound balance participate in bundle or cooperative settlement.

​
Relationship to authorized_settler

authorized_settler helps a hub with relaying and payment operations, but it is not the main reason the hub model works. The main reason is simpler:
  1. Users owe the hub on one set of channels.
  2. The hub owes providers on another set of channels.
authorized_settler is useful around the edges; the channel graph is the core.

​
Why this is different from a single managed rail

At the product layer, a hub can look similar to a centralized micropayment rail:
  1. one operator coordinates payment flow
  2. one operator can gate access or apply policy
  3. users and providers do not need a full mesh of direct channels
The difference is that Agon does not require one global operator.
  • Any team can build a hub on top of the protocol.
  • Users and providers are not bound to one payment company just to access the settlement rail.
  • Multiple hubs can coexist and compete, or a team can bypass hubs entirely with direct channels.
See vs. Managed rails for the explicit side-by-side.

​
See also