Opaque JSON
Balances, storage, and eth_call results arrive without cryptographic receipts. You inherit the operator's honesty and their view of the tip.
Verifiable RPC
vRPC is the future of RPC
Data and proofs in one response. Verify locally. Stop trusting operators for correctness.
Traditional RPC returns opaque JSON. vRPC keeps the familiar developer experience and attaches cryptographic proofs so Colibri can verify every answer in-process. Infrastructure stays useful for speed and availability — not for truth.
The problem
RPC that you cannot audit
Most wallets, dApps, and agents still read the chain through hosted RPC. That is fast, but correctness is an act of faith. TLS protects the transport. It does not prove that the payload matches the canonical chain.
Single-operator trust
A compromised endpoint, a stale fork, or a manipulated response can look like a normal reply. Applications have no independent check.
No proof standard
Providers compete on regions and uptime, not on verifiable responses. Opaque RPC remains the default contract with developers.
vRPC changes the contract: same RPC-shaped interface, proof-bound answers, local verification with Colibri.
Three modes
Local. Prover service. vRPC.
Colibri supports three deployment modes. All are equally trustless. They differ only in where proofs are generated and how they reach the verifier. A compromised prover or provider cannot invent a valid proof for false data.
Local
Proofs on device
The app fetches data from a normal RPC (and beacon sources as needed) and generates proofs in-process. Maximum self-containment; more work and bandwidth on the client.
Best fit · Independent and constrained stacks
Prover service
Dedicated proof generation
The app still talks to ordinary RPC for data, while a dedicated prover builds proofs. Better performance; the prover remains untrusted because Colibri verifies every proof locally.
Best fit · Mobile, web, and backends that want speed
vRPC
Proofs at the endpoint
One endpoint returns data and proofs together. Simplest integration and typically the best latency path for apps that already expect an RPC URL.
Best fit · Drop-in replacement for hosted RPC
Industry path
Every RPC provider should offer vRPC
RPC is not going away. Applications still need low-latency access to chain data. What must change is the guarantee: responses should be proof-bound by default.
- Drop-in migration for existing JSON-RPC consumers
- Compete on verifiability, not only uptime and regions
- Pair with Colibri (and other verifiers) as the local check
- Make opaque RPC the legacy mode
When providers ship vRPC, wallets and dApps keep a familiar URL while removing blind trust. That is the upgrade path for the industry.
Collaborate
Build the verifiable RPC future with us
Corpus Core builds Colibri and the prover stack that makes vRPC practical. We want RPC providers, wallet teams, infra operators, and protocol builders to help make proof-bound RPC the default.
- Reference integrations and endpoint design
- Proof formats and production rollout
- Shared expectations for proof-bound JSON-RPC
FAQ
Questions about vRPC
Does vRPC mean I no longer need Colibri?
You still need a verifier. vRPC delivers proofs; Colibri (or another compatible verifier) checks them. Without local verification, a proof-bound response is just another blob you might trust blindly.
Is a prover service trusted?
No. A compromised prover cannot produce a valid proof for manipulated data. Colibri verifies every proof locally, whether it came from a local generator, a remote prover, or a vRPC endpoint.
Is vRPC the same as running a full node?
No. vRPC is a hosted or self-hosted RPC-shaped service that attaches proofs. You get verifiable answers without operating a full node yourself.
Can existing RPC providers adopt vRPC?
Yes. That is the point: keep the developer experience of JSON-RPC, add proofs, and let clients verify. We collaborate with providers who want to ship that path.
How does PAP relate to vRPC?
Verification solves correctness. PAP addresses read-path privacy (what query patterns leak to infrastructure). They complement each other; they are not the same problem.
Proof-bound by default.
Don't trust the operator. Verify the proof — locally, with Colibri.