Blockchain RPC lets your application call supported blockchain networks without running its own nodes. Connect over HTTP JSON-RPC or native gRPC using a workspace RPC key; the protocol and chain routing depend on the network.
HTTP rpc.vilna.io gRPC grpc.vilna.io:443 vilna_rpc_ · workspace One key, every chain
Two protocols, chosen by chain:
- JSON-RPC over HTTP - EVM chains, Solana and Bitcoin. Standard JSON-RPC 2.0 over HTTPS.
- gRPC - Tron. Native gRPC with metadata-based chain routing.
Every authenticated request carries an RPC key (vilna_rpc_ prefix), created in your workspace settings. The header depends on the protocol:
| Protocol | Header | Value |
|---|---|---|
| HTTP | X-Api-Key | Your RPC key |
| gRPC | x-api-key (metadata) | Your RPC key |
RPC keys are workspace-scoped and reach every chain. See Authentication for key types and scopes.
Eleven networks, every one served over JSON-RPC except Tron, which speaks gRPC. The networks table lists each CAIP-2 id and alias, and shows which of them the Platform API monitors as well.
Use the CAIP-2 ID or alias in the HTTP path for JSON-RPC, or in gRPC x-chain-id metadata for Tron. The Tron and Solana CAIP-2 IDs in the network table are supported alongside aliases and identifiers such as tron:mainnet and solana:mainnet. See Standards for the CAIP-2 format.
The GET /chains endpoint needs no key and lists the chains the proxy currently serves - a quick way to confirm the service is reachable:
curl https://rpc.vilna.io/chainsVilna HTTP idempotency guarantees do not apply to RPC. Requests may repeat, including through automatic proxy retries. After a timeout or lost broadcast response, look up the transaction by its ID and check its network state before deciding whether to rebroadcast. Do not automatically sign a new transaction: the original may already have reached the network.