Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ryvo.network/llms.txt

Use this file to discover all available pages before exploring further.

Ryvo is non-custodial, but it is not built on the idea that every machine-payment relationship should look fully trustless at every moment. The protocol separates hard on-chain guarantees from soft product-level choices that integrations make for themselves.

​
What the protocol guarantees

On-chain, Ryvo guarantees:
  1. Balances live in protocol state, not in an operator database.
  2. Only allowlisted tokens can be used for settlement.
  3. Signed settlement messages are checked against the deployment message_domain, which is derived in-program from a fixed Ryvo tag, the program ID, and the chain ID.
  4. Channels and participants are checked against canonical PDAs, even when they arrive through remaining_accounts.
  5. Settlement only moves cumulative state forward - any message that does not increase settled_cumulative is rejected.
  6. Withdrawals, channel unlocks, and signer rotations follow configured timelocks.
  7. Self-channels are explicitly rejected to prevent using settlement to bypass unlock timing.
If a valid settlement message is submitted with the right accounts, the program enforces these rules regardless of who submits the transaction.

​
What still depends on the relationship

Ryvo does not try to remove every real-world tradeoff between participants. For example:
  • One payee may require enough locked funds to make signed value effectively guaranteed; another may accept partial lockup or periodic settlement.
  • One integration may settle every few seconds; another may settle in larger batches.
  • One team may run settlement directly; another may use an operator for relay and coordination.
These are product and relationship choices on top of the same protocol. See Trust and collateral for the three levers each integration picks from.

​
What “trust” means in Ryvo

In most Ryvo integrations, trust means one or more of:
  1. how much unsettled usage a payee is willing to tolerate
  2. how much locked balance a payer is willing to dedicate to a specific channel
  3. how much the parties rely on off-chain monitoring, retries, and operator tooling
It does not mean the user has handed custody of protocol balances to a centralized ledger.

​
Operators and coordination

Ryvo supports optional operator layers. An operator can:
  • relay settlements
  • batch and schedule submissions
  • retry and monitor
  • handle invoicing
  • apply compliance checks

​
Authorities and upgrades

Two administrative roles exist, each with a two-step handoff:
RoleControlsHandoff
Config authorityFee recipient, fee basis points, registration fee, pending authorityupdate_config → accept_config_authority
Registry authorityAdding new allowlisted tokens, pending registry authorityupdate_registry_authority → accept_registry_authority
Neither authority can:
  • change message_domain
  • change chain_id
  • drain vault balances
  • bypass withdrawal, unlock, or signer timelocks
  • modify participant or channel state outside the normal instruction surface
The program upgrade authority on Solana retains the standard ability to upgrade the program binary, which is outside the protocol’s on-chain guarantees. Immutability of the signing domain and the non-custodial invariants are enforced inside the program as long as the deployed binary enforces them.

​
Summary

Ryvo is a public settlement and clearing protocol for repeated machine-payment relationships. It gives those relationships room to choose their own point on the locked-capital / settlement-frequency / operational-trust spectrum, while holding a small set of properties constant: balances stay in protocol state, messages are bound to the deployment, settlement only moves forward, and channel maintenance is timelocked.

​
See also