Venice Crypto Rpc

Venice Crypto RPC (JSON-RPC proxy)

Venice exposes a multi-chain JSON-RPC proxy billed per call. Same request shape as Alchemy / Infura — change the base URL and pay per credit from your Venice balance (DIEM → earned credits → bundled credits → USD) or an x402 wallet.

Supported networks

curl https://api.venice.ai/api/v1/crypto/rpc/networks

It currently returns 27 slugs (always verify — the catalog grows):

arbitrum-mainnet    arbitrum-sepolia
avalanche-mainnet   avalanche-fuji
base-mainnet        base-sepolia
blast-mainnet       blast-sepolia
bsc-mainnet         bsc-testnet
ethereum-mainnet    ethereum-sepolia    ethereum-holesky
linea-mainnet       linea-sepolia
optimism-mainnet    optimism-sepolia
polygon-mainnet     polygon-amoy
robinhood-mainnet   robinhood-testnet
solana-mainnet      solana-devnet
starknet-mainnet    starknet-sepolia
zksync-mainnet      zksync-sepolia

Use the slug as {network} in the proxy path. An unknown slug is a 400. The spec's example list for /networks omits blast-mainnet / blast-sepolia, but the live endpoint and proxy include them — trust GET /crypto/rpc/networks, and don't hardcode a client-side allowlist.

Chain families

Each network speaks exactly one method family, and the allowlist is enforced per family. Sending an EVM method to a Solana network (or the reverse) is a 400, not a pass-through.

The allowlists are explicit method names, not prefixes: a method in a supported namespace that isn't on the list (e.g. an unlisted debug_* or trace_* method) is rejected. The EVM list is shared by every EVM network, so a chain-specific method (zks_*, linea_*, bor_*) passes Venice's check on any EVM chain but only works upstream on its own chain.

Send a JSON-RPC request

Single call

curl -X POST https://api.venice.ai/api/v1/crypto/rpc/ethereum-mainnet \
  -H "Authorization: Bearer $VENICE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

{ "jsonrpc": "2.0", "id": 1, "result": "0x1" }

Each request object must have a string method; otherwise 400.

Batch (up to 100 calls)

curl -X POST https://api.venice.ai/api/v1/crypto/rpc/base-mainnet \
  -H "Authorization: Bearer $VENICE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1},
    {"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":2}
  ]'

• An empty array or more than 100 items ⇒ 400.
• A single unsupported method in a batch ⇒ the entire batch fails with 400, and the message lists every offending method. (A WebSocket-only method fails the batch immediately with its own message naming just that method.)
• Give every item a unique id: billing pairs response items to requests by id.

Drop-in with viem

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://api.venice.ai/api/v1/crypto/rpc/ethereum-mainnet', {
    fetchOptions: { headers: { Authorization: `Bearer ${process.env.VENICE_API_KEY}` } },
  }),
})

Pricing

Credits per call = baseCredits[chain] × methodTier, at $0.0000007 (7e-7) per credit.

Examples:

• Standard EVM call (20 × 1 = 20 credits) = $0.000014
• Advanced trace on Ethereum (20 × 2) = $0.000028
• Large trace replay (20 × 4) = $0.000056
• zkSync or Solana standard call (30 × 1) = $0.000021
• Solana getLargestAccounts (30 × 4) = $0.000084

Error billing:

• An item that comes back with a JSON-RPC error (HTTP 200 — e.g. bad params, method not available on that chain) is billed a flat 5 credits instead of its tier. In a batch, a success item whose id doesn't match a request is also billed 5.
• If the upstream node returns HTTP 4xx, each item is billed 5 credits. Upstream 402, 429, and 5xx are billed 0.
• Requests Venice rejects itself (400, 401, 402, 429) are not billed.

Before forwarding, Venice checks that the balance of your current consumption currency covers the estimated full-tier cost; otherwise 402.

Response headers

Set on every response relayed from the node (any status) and on idempotent replays; responses Venice generates itself (validation errors, 402, 429, upstream-fetch 500) don't carry them.

On 2xx the Content-Type is always application/json; upstream error bodies are sanitized before being forwarded. The spec also lists X-Balance-Remaining for x402 callers, but the proxy does not set it — use GET /x402/balance/{walletAddress}.

Unsupported methods

These always return 400:

• Stateful filter methods — eth_newFilter, eth_newBlockFilter, eth_newPendingTransactionFilter, eth_getFilterChanges, eth_getFilterLogs, eth_uninstallFilter. Filter state is pinned to one backend and a load-balanced HTTP proxy can't keep it. Use eth_getLogs instead.
• WebSocket-only methods — EVM eth_subscribe / eth_unsubscribe and Solana *Subscribe / *Unsubscribe (account, block, logs, program, root, signature, slot, slotsUpdates, vote). This proxy is HTTP only.
• Wallet / miner methods — eth_sign, eth_accounts, eth_getWork, eth_submitWork, eth_mining, eth_hashrate.
• Solana add-ons and legacy aliases — getAsset* (DAS) and deprecated getConfirmed*.
• Cross-family methods — starknet_* or Solana getBalance on an EVM chain, eth_call on Solana, etc.
• Anything else not on the allowlist. The error message names the rejected methods.