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.

V5 is the current production protocol. It supports permanent identities, bucketed participant and channel state, signed cumulative commitments, bundle settlement, and cooperative clearing rounds under BLS aggregation. The roadmap below describes directions that extend protocol reach without altering the separation of execution and settlement that makes the protocol work.

​
BLS signature aggregation

BLS aggregation is now live in cooperative clearing. It changes density, not settlement semantics:
  • Many participant signatures collapse into one aggregate signature.
  • The signed round body stays the same.
  • More participants and channels fit in a single cooperative transaction.
What BLS does not change:
  • Payment execution is still separate from settlement.
  • Unilateral commitments still work without cooperation.
  • Bundle settlement still works without cooperation.
  • Cooperation remains optional for any relationship.
Observed dense rounds include:
  • 20 unique participants advancing 84 unique payment channels
  • 32 unique participants advancing 32 unique payment channels
BLS increases cooperative settlement density while preserving cumulative channel advancement invariants.

​
Token-2022 and fixed-balance yield assets

The current deployment uses the original SPL Token program. Fixed-balance yield-bearing assets, Maple’s syrupUSDC and similar products, fit the protocol’s accounting model because stored balances stay constant while redemption value rises over time. Token-2022 interest-bearing mints are conceptually close to this model on-chain. First-class Token-2022 support would require token-interface work across the vault accounts, deposit flow, and withdrawal flow, but does not change the signed-message or settlement surface. See Yield-bearing assets for the current guidance on which token designs fit cleanly.

​
Additional settlement tokens

The token registry is designed to grow. New allowlisted tokens can be registered by the registry authority without changing the signed-message format or settlement surface. Each new token simply appears with its own token_id, vault token account, and decimals. The authority model for token registration is intentionally separate from the configuration authority, so ecosystem token rollout can follow its own operational process.

​
Operator and facilitator tooling

Ryvo’s base layer is intentionally minimal. Most of the usability improvements for real-world deployments belong outside the program:
  • Bundle-collection and relay services.
  • Clearing-round proposers.
  • Monitoring, alerting, and invoicing.
  • Compliance and KYT integrations built in operator tooling.
These are natural places for independent teams to build on top of the protocol without changing how settlement works.

​
What stays constant

Across these directions, the core protocol model does not change:
  • Balances live in program-owned accounts.
  • Signed cumulative commitments remain the unilateral settlement primitive.
  • Direct settlement is always available as a fallback.
  • Cooperation is signalled by shared signed messages, not by operator custody.
  • message_domain remains deployment-scoped and derived in-program.
Extensions should extend reach, more participants per round, more assets, better tooling, without relaxing those properties.