RVO Roadmap: Principles Before Features
RVO is being built with a deliberate bias toward correctness and predictability.
This page is not a delivery schedule.
It is a description of how RVO evolves, what is intentionally in scope today, and why certain features are deferred until the system has earned them.
We avoid publishing dates or short-term promises.
Direction matters more than speed at this stage.
Why RVO Exists
RVO exists to make infrastructure behavior explicit and predictable.
In decentralized systems, outright failure is often easier to handle than silent degradation.
Requests may still succeed — but slower, inconsistently, or just often enough to hide systemic issues.
RVO is built to surface these realities instead of masking them.
Current Focus
RVO is intentionally narrow today.
The system currently focuses on:
- A single, well-defined JSON-RPC interface
- Explicit limits and predictable request behavior
- Clear error semantics instead of opaque retries
- Reliability as an observable property, not a marketing claim
- Human accountability when degradation or failure occurs
This scope allows the system to remain understandable, debuggable, and safe under real usage.
About WebSockets, Streams, and Advanced Interfaces
Features like WebSocket subscriptions and streaming interfaces are planned.
They are not missing because of uncertainty about functionality —
they are deferred because of operational responsibility.
While the core request path is working reliably today, operating persistent connections at scale introduces a different class of failure modes, resource pressure, and recovery complexity.
Before exposing these interfaces, RVO needs:
- More operational experience under sustained load
- Clear guarantees around isolation and backpressure
- Confidence that failure and degradation can be surfaced explicitly
For these reasons, advanced interfaces are expected months out, not weeks — once the system has demonstrated stability and safety at scale.
What RVO Is Deliberately Not Doing (Yet)
At this stage, RVO is deliberately not:
- Expanding protocol surface prematurely
- Offering streaming or subscription interfaces before they can be operated safely
- Publishing usage numbers or simulated metrics
- Scaling infrastructure ahead of real, observed demand
- Optimizing for feature breadth over operational clarity
These are conscious constraints, not gaps.
How Decisions Are Made
Features are added only when real usage provides a clear signal.
Decisions are driven by:
- Repeated patterns observed in production traffic
- Limits that become visible under real load
- Failure modes that can be detected and explained
- The ability to extend the system without increasing ambiguity
If a feature cannot be justified by operational evidence, it does not belong on the roadmap yet.
What Progress Looks Like
Progress for RVO is not measured by velocity or feature count.
It looks like:
- Users depending on RVO for production workloads
- Degradation being detected and handled explicitly
- Behavior remaining boring and predictable under stress
- Scaling decisions becoming easier because the system has proven itself
Only once these conditions are met does broader expansion make sense.
Closing
RVO will expand when it is safe to do so.
Until then, correctness comes first.