Skip to main content
Ryvo 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 Ryvo’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 Ryvo settlement
The hub is doing payment coordination. Balances still live in protocol state.

​
Why it fits Ryvo

Ryvo 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 Ryvo settlement.

​
Providers must trust hub balance accounting

The protocol enforces locked balance when a channel settles on-chain. Between settlements, the hub decides whether to honor each inbound commitment. That means providers must trust the hub to track remaining capacity correctly on every inbound channel. If a participant locked 10∗∗tothehublaneandhasalreadyconsumed∗∗10** to the hub lane and has already consumed **5, the hub must treat only $5 as still available. If the hub’s ledger is wrong, it can accept new commitments that exceed what the participant actually has locked. The participant overspends relative to that channel, and the provider may see outbound commitments from the hub that cannot be fully backed when inbound channels settle. This is not a protocol failure. It is the trust surface of routing through a coordinator. Providers can mitigate it by:
  1. requiring frequent inbound settlement from the hub
  2. capping exposure per hub relationship
  3. monitoring inbound settled_cumulative against on-chain locked_balance themselves
  4. opening direct channels to participants they care about most

​
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 or withhold forwarding
  3. require additional lockup
  4. choose which providers it will work with
In practice, a hub can censor payments at the service layer by refusing or stalling requests even when the participant has locked liquidity and a valid commitment. 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.

​
Exit paths for participants

Participants are not trapped in a censored hub relationship. A buyer or agent can:
  1. request a channel unlock to release locked liquidity from that hub lane (subject to the configured timelock)
  2. open a direct channel to the provider and pay without the hub
  3. lock to a different hub and route through a competing operator
Funds stay in protocol state throughout. The hub can block its own service, but it cannot prevent the participant from withdrawing shared balance or unlocking channel funds through normal protocol instructions once timelocks expire. Users and providers can also choose different hubs, use direct channels, or mix both from the start.

​
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.

​
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 Ryvo 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