Skip to main content

Public RPC Endpoints

OXN Testnet exposes a single public RPC endpoint operated by the OXN team. It is intended for development and low-to-moderate application traffic. This page explains what it supports, how it is limited, and when you should host your own.

Endpoint​

ProtocolURL
HTTPShttps://rpc.bout.network

TLS terminates at the public edge. Behind it, requests are proxied to the OXN EVM gateway.

The endpoint accepts standard JSON-RPC over HTTP POST. Requests use content type application/json.

Availability​

The endpoint is intended to be available 24/7. Planned maintenance windows are announced through the Support channels. Unplanned incidents are triaged on a best-effort basis.

Uptime SLA is not published for testnet. Applications with production availability requirements should host their own RPC node, once that path is documented — see Running a Read-Only RPC Node.

Rate limits​

The public endpoint applies rate limits to prevent abuse. Concrete numbers may change; the current guidance is:

  • Rate limits apply per source IP address.
  • Heavy calls (eth_getLogs with wide block ranges, eth_call with expensive traces) may consume multiple quota units per request.
  • Bursting above the limit returns HTTP 429 Too Many Requests with a Retry-After header.

If your integration requires more headroom than the default allows, contact the team through the Support channels and describe your use case.

Supported methods​

The endpoint supports the standard Ethereum JSON-RPC surface:

  • eth_* — account and block queries, calls, transaction submission
  • net_* — network identification
  • web3_* — client identification
  • debug_traceTransaction — limited support (may be disabled under load)

It also supports OXN-specific extensions for encrypted call construction and signed queries. See JSON-RPC API Reference for the full method list.

CORS​

The endpoint responds to preflight OPTIONS requests with Access-Control-Allow-Origin: *. Browser-based dApps can call the endpoint directly.

Do not add duplicate CORS headers in your own proxy — the browser will reject responses with multiple Access-Control-Allow-Origin headers.

When to run your own node​

Reasons to run a private RPC node:

  • Sustained high request volume exceeding the public endpoint's rate limits
  • Custom archive requirements (indexing all historical events, replaying past state)
  • Latency sensitivity — a private node closer to your application infrastructure
  • Privacy from the OXN team — although the enclave protects call contents, request patterns to the public endpoint are visible to us

Node hosting is not fully open in the current testnet phase. See Running a Read-Only RPC Node for the current status.

Third-party providers​

There are no announced third-party OXN RPC providers as of this writing. When partners come online, they will be listed on Third-Party RPC Providers.

Next steps​