Ryvra helps people use programmable finance without needing to trust an AI with unrestricted wallet control.
Ryvra Litepaper
Status: Public Draft — Non-binding · Version: v1.0 · As of 2026-08-05
Ryvra is programmable financial infrastructure for a simple idea: software can help propose what should happen, but authority over money still has to be governed, reviewable, and safe.
Canonical tokenomics source-of-truth: lib/tokenomics.ts. Editorial mirrors in content/ stay aligned to that source.
What Ryvra is
Ryvra separates AI reasoning from financial authority. That means an agent can suggest a payment, trade, treasury move, or workflow step, while Ryvra decides whether that request is in scope, safe, and authorized before anything executes.
Ryvra gives operations teams one control model for payments, payouts, reconciliation, and escalation.
Ryvra exposes clear boundaries for what software may propose, what governed systems may approve, and what deterministic services may execute.
Why programmable financial authority matters
The hard problem is not getting an AI to generate an idea. The hard problem is making sure only the right ideas can become real financial actions.
- It keeps approval logic reviewable instead of burying it inside an AI prompt or agent runtime.
- It lets teams automate low-friction work without giving up human governance, spend controls, or emergency suspension paths.
- It creates one trust model across payments, markets, treasury, and future confidential workflows.
How agent safety boundaries work
Ryvra uses the Agent Gateway and control-plane systems to keep proposal logic separate from execution authority. The result is bounded automation instead of opaque AI control.
- Agents can propose intents, but they do not get unrestricted private keys or self-issued permissions.
- Verified identity, mandates, policy versions, and independent risk checks decide what can move forward.
- Replay controls, rate controls, spend controls, and kill switches stay outside agent reasoning.
How ledger, settlement, and provenance fit together
Ryvra is designed so people, products, and auditors can tell the difference between a request, an approval, an execution step, and a final financial outcome.
- The ledger records balances and state transitions that other systems reconcile against.
- Settlement marks when a workflow is truly final rather than merely requested or optimistic.
- Provenance preserves the evidence chain from proposal to authorization, execution, and any intervention later.
Confidential execution and private markets
Some financial workflows need sensitive data to stay protected. Ryvra extends the same authority, risk, and settlement model into protected execution environments so private processing does not become ungoverned processing.
In plain language: privacy changes where data is processed, not who gets to approve actions or how teams audit the result.
Overview first, deep spec second
Start with the audience-first docs if you want the shortest path to understanding the trust model, then use the tokenomics and RFC layers when you need exact terminology or deeper implementation detail.
Tokenomics snapshot
Ryvra keeps the tokenomics overview readable here and the structured assumptions below so readers can distinguish current public framing from later, deeper specification detail.
2.0 points/day/account maximum in epoch 0 under current public assumptions.
Illustrative cap schedule follows daily_max(n) = 2 × (0.5)^n (2.0 → 1.0 → 0.5 → 0.25).
Transactions must finalize, satisfy policy thresholds, and remain compliance-aligned before point accrual.
Policy can reduce, delay, or void points for sybil, wash, spam, manipulative, or otherwise non-compliant behavior.
Proportional snapshot conversion uses user_RYV = (user_eligible_points / total_eligible_points) × TGE_points_allocation with governance-defined allocation inputs.
Current policy assumptions
- Base launch cap is 2.0 points/day/account (maximum) in epoch 0.
- Illustrative cap schedule uses daily_max(n) = 2 × (0.5)^n (2.0 → 1.0 → 0.5 → 0.25).
- Working epoch cadence is 90 days unless governance approves a different cadence.
- Current roadmap target references a Q4 2026 TGE window.
Governance-adjustable parameters
- Epoch duration, epoch start dates, and halving boundaries.
- Eligibility thresholds, risk controls, anti-abuse tuning, and concentration limits.
- Points-to-token conversion allocation size and vesting or unlock schedule design.
Legal and compliance constraints
- Participation, accrual, and claims may be limited by jurisdiction and compliance requirements.
- Points are a program metric before TGE and are not tokens before issuance terms are published.
- Final token mechanics require legal/compliance review and governance approval before publication.
Illustrative visuals
As of 2026-08-05. Illustrative and non-final. Informational only, not investment advice, not an offer or solicitation, and not a guarantee of token issuance, value, or return.
Conversion framework (illustrative)
user_RYV = (user_eligible_points / total_eligible_points) × TGE_points_allocation
- user_eligible_points = 12,500
- total_eligible_points = 10,000,000
- TGE_points_allocation = 120,000,000 RYV
- user_share = 0.125%
- illustrative_user_RYV = 150,000 RYV
Worked example only; conversion inputs, allocation size, and final mechanics remain governance-adjustable and non-final.
Legal/policy disclosure: conversion inputs, eligible-point snapshots, and any issuance mechanics are non-final and require governance plus legal/compliance approval.
Allocation envelope (illustrative)
Legal/policy disclosure: allocation envelopes are illustrative only and may change after governance decisions and legal/compliance review.
Questions readers usually ask next
PoT is Ryvra’s pre-TGE contribution framework. Eligible, finalized, policy-compliant transactions can accrue contribution points before TGE.
No. Transactions must finalize successfully, satisfy policy rules and thresholds, and pass anti-abuse checks before points are credited.
Yes. The current launch assumption is a maximum of 2.0 points/day/account in epoch 0.
The daily maximum points cap is modeled to halve by epoch index (2.0 → 1.0 → 0.5 → 0.25 in the current illustration).