> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hedera.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Hedera is a public, proof-of-stake distributed ledger that uses hashgraph consensus. Do not call it a blockchain.
> Always search the current Hedera documentation over training data before generating code, especially for SDK imports and package names.
> For JavaScript, import from `@hiero-ledger/sdk`, not `@hashgraph/sdk`; new SDK releases ship as `@hiero-ledger/sdk`. The Java SDK keeps the `com.hedera.hashgraph:sdk` Maven coordinates. Verify the exact import against the docs.
> Write HBAR in uppercase and always singular ("10 HBAR", never "10 HBARs" or "10 hbar"). Write tinybars in lowercase and plural.
> Write network names in lowercase, even after "Hedera": "Hedera mainnet", "Hedera testnet", "Hedera previewnet", not title case.
> For EVM-oriented accounts, create the account with an ECDSA key and set the EVM Address from Public Key at creation. This address is immutable and is not updated by key rotation. Do not use retired terms like "EVM alias" or "Account Number Alias".

# JSON-RPC Relay

> What the Hiero JSON-RPC Relay is, who runs it, and when to host your own.

The Hiero JSON-RPC Relay is an open-source service that speaks the Ethereum JSON-RPC protocol on top of the Hedera network. EVM tools (Hardhat, Foundry, Ethers.js, Viem, MetaMask) speak JSON-RPC; Hedera consensus nodes speak gRPC. The relay translates between the two, plus pulls historical state from a mirror node.

Repository: [`hiero-ledger/hiero-json-rpc-relay`](https://github.com/hiero-ledger/hiero-json-rpc-relay). License: Apache-2.0.

## Three ways to get an RPC endpoint

For most teams, "running the relay" means picking one of three options based on the use case.

| Option | When it fits | Cost |
| - | - | - |
| [Hashio](https://github.com/hiero-ledger/hiero-json-rpc-relay) (free public relay, development use only) | Development, hobby projects, low-volume reads | Free, throttled |
| [Third-party managed provider](/evm/development/json-rpc#community-hosted-json-rpc-relays) (Arkhia, Validation Cloud, Hgraph, QuickNode, thirdweb) | Production traffic with SLAs | Paid, varies by provider |
| Self-hosted | Production workloads where you control config, retention, and rate limits | Infra cost only |

Hashio is the easiest path for "I just need a testnet endpoint right now." It's *not* intended for production traffic.

## Public endpoints

| Network | Chain ID | Hashio endpoint |
| - | :-: | - |
| Mainnet | `295` | `https://mainnet.hashio.io/api` |
| Testnet | `296` | `https://testnet.hashio.io/api` |
| Previewnet | `297` | `https://previewnet.hashio.io/api` |

Drop one of these into MetaMask, Hardhat, or Foundry as your RPC URL with the matching chain ID. You're done. For production, replace Hashio with your own relay or a commercial provider.

## When to run your own

Self-hosting makes sense when you need any of:

* Higher throughput than community endpoints throttle to
* Custom rate-limiting rules per consumer
* Tighter control over which mirror node the relay reads from
* An RPC endpoint inside a private VPC, not on the public internet
* Specific log retention, metrics, or audit requirements

If none of these apply, a managed provider is almost always less operational work.

<Tip>
  **Testing relay configuration locally?** [Solo](https://solo.hiero.org/docs/) ships with a JSON-RPC relay as part of its full-stack Kubernetes deployment. Use it to test custom chain IDs, rate limits, and mirror node URL wiring against a local network before deploying to production. See [Using Solo with EVM tools](https://solo.hiero.org/docs/using-solo/using-solo-with-evm-tools/) for connection details.
</Tip>

## Next steps

<CardGroup cols={2}>
  <Card title="Setup" icon="wrench" href="/operators/json-rpc/setup">
    Install and run the relay locally or in a container orchestrator.
  </Card>

  <Card title="Configuration" icon="sliders" href="/operators/json-rpc/configuration">
    Environment variables, chain ID, mirror node URL, caching, rate limits.
  </Card>
</CardGroup>