> ## 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. # Protocol Overview > A builder-first tour of protocol accounts, messages, and settlement paths. Ryvo decouples payment execution from settlement. Participants make many payments first through signed cumulative commitments, and settle them later on-chain. Each wallet registers once as a participant and keeps the same `participant_id` for the life of the deployment. Participants deposit allowlisted tokens into protocol balances. When one participant pays another, they create one permanent one-way payment channel for that token. The payer may optionally lock funds to that channel if the relationship needs guaranteed payment capacity. ## On-chain objects The current architecture uses global singletons plus bucketed participant and channel state: | Account | What it stores | Why it exists | | ---------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- | | `GlobalConfig` | Authority, fee settings, chain ID, derived `message_domain`, timelock policy | Defines the deployment and the signing domain | | `TokenRegistry` | Allowlisted settlement tokens | Makes token support explicit rather than implicit | | `ParticipantBucket` + `OwnerIndexBucket` | Participant slots, balances, policy, BLS key metadata, owner->participant mapping | Scales participant state while preserving deterministic lookup | | `ChannelBucket` | Directional lane state for participant pairs per token | Tracks cumulative settlement, locks, and signer state per lane | Full field-level layouts are on the [Account layouts](/reference/accounts) reference. ## Signed messages Ryvo uses two signed message formats: * **`ryvo-cmt-v5`** - the unilateral cumulative commitment for one channel * **`Ryvo-round`** - the cooperative clearing-round body for several participants Both messages embed the deployment-scoped `message_domain`, so a signature for one environment does not verify on another. Full byte-level layouts are on the [Message formats](/reference/messages) reference. ## Settlement paths Those two messages feed three settlement instructions: | Mode | Instruction | When to use | | -------------------- | -------------------------- | ------------------------------------------------------------------------------- | | Direct | `settle_individual` | One payer, one payee - the simplest path | | Bundle | `settle_commitment_bundle` | One payee aggregating many payers' commitments in one token | | Cooperative clearing | `settle_clearing_round` | Several participants co-signing one shared round so many lanes advance together | All three settle into the same shared vault and the same participant balances. ## End-to-end flow In the common case, an integration goes through these steps: 1. Register the payer and payee as participants. 2. Deposit an allowlisted token. 3. Create a one-way payment channel. 4. Optionally lock funds to that channel for guaranteed capacity. 5. Sign cumulative commitments off-chain as usage grows. 6. Settle the newest valid state later. [Your first payment](/getting-started/first-payment) walks through each step with working code. ## What stays off-chain Ryvo keeps signed payment updates off-chain until settlement. Most integrations store: * the latest signed `ryvo-cmt-v5` per channel * usage or metering state * bundle assembly logic * cooperative round construction logic Only the newest valid state needs to reach the chain. ## Why Ryvo uses permanent identities and persistent lanes Ryvo intentionally uses stable identities and permanent channels. The tradeoff is more long-lived on-chain state, but the protocol becomes much easier to work with: * `participant_id` values do not recycle. * Off-chain services can index users without worrying about identity reuse. * Channels do not close and reopen, so there is no reopened-channel replay surface. * Replay protection is simpler. * Payment channels stay stable for clients and operators. For the rationale, see [Design principles](/thesis/design-principles). ## Choosing a settlement mode * Use **direct settlement** when one payer and one payee need the smallest possible surface and each lane can settle on its own. * Use **bundle settlement** when one payee collects signed commitments from many payers in the same token and wants one transaction instead of many. * Use **cooperative clearing** when several parties are willing to co-sign one shared round so many lanes can be advanced in one transaction. See [Settlement modes](/settlement-modes/overview) for the tradeoffs side by side. ## Current deployment | Field | Value | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Program ID | `3UyUFeNsUYPpM6hMRf7H8wg3MKEXQ82rqnsXhZrUwgSD` | | Cluster | `devnet` | | Message domain | `a58a109a38f14cc27ef174135176cab3` | | Gateway-channel settlement token | Official devnet USDC, mint `4zMMC9srt5Ri5X14GAgXhaHii3GnPAEERYPJgZJDncDU`; resolve `token_id` from `TokenRegistry` or `RYVO_PROTOCOL_DEVNET_USDC_TOKEN_ID` | See [Deployment](/reference/deployment) for environment-specific chain IDs and timelocks. ## Where to go next Build the smallest useful Ryvo integration with real Anchor calls. How one-way, permanent channels are modeled and maintained. How cumulative signed messages work and why they are cheap to update. The full on-chain instruction surface.