venice_ai.resources.crypto

Venice AI Crypto RPC proxy resource.

Wraps the two /crypto/rpc/* endpoints documented at api-reference/endpoint/crypto/:

• GET /crypto/rpc/networks — public list of supported network slugs
• POST /crypto/rpc/{network} — JSON-RPC 2.0 forwarder (single + batch)

The proxy bills per credit (baseCredits[chain] x methodTier); credit and rate-limit detail lives in the endpoint docs. This resource is a thin pass-through — params and result are forwarded to / from the upstream chain unchanged.

Idempotency: Pass idempotency_key on rpc() / batch_rpc() to enable safe retries. Replaying within 24h with the same key + same body returns the cached response with the Idempotent-Replayed: true header. Same key + different body returns 400.

Crypto Objects

class Crypto(APIResource["VeniceClient"])

Crypto RPC proxy: discovery + JSON-RPC 2.0 forwarder.

Example:

async with VeniceClient() as client:
# Discover supported networks
slugs = await client.crypto.networks()

# Single call
resp = await client.crypto.rpc(
network="ethereum-mainnet",
method="eth_chainId",
params=[],
id=1,
)
chain_id = resp.result  # "0x1"

# Batch call (up to 100 items)
results = await client.crypto.batch_rpc(
network="ethereum-mainnet",
requests=[
{"method": "eth_chainId", "params": [], "id": 1},
{"method": "eth_blockNumber", "params": [], "id": 2},
],
)

Crypto.networks

async def networks() -> list[str]

List supported crypto RPC network slugs.

Public endpoint — does not require authentication. The list is authoritative: slugs not in it return 400 Unsupported RPC network from rpc().

Returns:

list[str]: Sorted Venice-side network slugs (e.g. "ethereum-mainnet").

Crypto.rpc

async def rpc(*,
              network: str,
              method: str,
              params: list[Any] | dict[str, Any] | None = None,
              id: int | str | None = 1,
              idempotency_key: str | None = None) -> JsonRpcResponse

Forward a single JSON-RPC 2.0 call to a supported chain.

Arguments:

• network (str): Venice-side network slug (e.g. "ethereum-mainnet"). See :meth:networks for the live list.
• method (str): JSON-RPC method name (e.g. "eth_chainId").
• params (list[Any] | dict[str, Any] | None): Method parameters. Shape is method-dependent and forwarded to the upstream chain unchanged.
• id (int | str | None): Caller-supplied request ID echoed back in the response. Defaults to 1.
• idempotency_key (str | None): Optional idempotency key for safe retries ([A-Za-z0-9_-]{1,255}). Same key + same body within 24h replays the cached response.

Raises:

• ValueError: If idempotency_key violates the proxy pattern.
• venice_ai.exceptions.APIError: For HTTP-level failures (e.g. 400 unsupported network, 429 rate-limited).

Returns:

JsonRpcResponse: :class:JsonRpcResponse. On per-request failure, error is populated and HTTP status is still 200 — check response.error.

Crypto.batch_rpc

async def batch_rpc(
        *,
        network: str,
        requests: Sequence[JsonRpcRequest | dict[str, Any]],
        idempotency_key: str | None = None) -> BatchJsonRpcResponse

Forward a JSON-RPC 2.0 batch (1–100 items) to a supported chain.

Each item is validated independently; if any method is unsupported the entire batch is rejected with 400 and every offending name is listed in the error message.

Per-item RPC errors do NOT fail the batch — successful items still return result, failed items return error. Per the docs, RPC-level errors in batch responses bill at 5 credits each rather than the full method tier.

Arguments:

• network (str): Venice-side network slug.
• requests (Sequence[JsonRpcRequest | dict[str, Any]]): Up to 100 JSON-RPC requests. Each may be a :class:JsonRpcRequest instance or a plain dict — dicts are validated through :class:JsonRpcRequest before being sent.
• idempotency_key (str | None): Optional idempotency key, same semantics as :meth:rpc.

Raises:

• ValueError: If requests is empty, exceeds 100 items, or idempotency_key violates the proxy pattern.

Returns:

BatchJsonRpcResponse: :class:BatchJsonRpcResponse whose responses list mirrors the input order at the wire level. JSON-RPC does not guarantee response ordering — use each item's id field to correlate. HTTP-level billing headers (rpc_credits, rpc_cost_usd, venice_request_id, idempotent_replayed) are exposed on the wrapper since they cover the whole batch.