Networks and bring-your-own RPC endpoints

The networks a workspace starts with

Every workspace’s registry is seeded from the same ten built-in networks:

These slugs are what every network selector and defaultNetwork accepts. A well-formed slug that is not one of them — or one your operator removed — is a 404, not a 400.

Use a testnet while you are integrating. sepolia and solana-devnet carry no real value, and every example in these docs uses ethereum only because it is the obvious name. A first transaction on ethereum is a real mainnet transaction.

TEE Docker ships no RPC service. Anything that touches a chain — building, simulating, submitting, or checking a transaction — runs against an endpoint you or your operator supplied.

Resolution

An endpoint can come from three places. They are not searched in turn at request time — the workspace’s own network registry is read once, and each entry already carries the provenance it was given:

So a registry entry is necessary but not sufficient. A call fails with 409 and rpc_not_configured in two cases: the network has no URL at all, or it has a built-in one and allowDefaultRpc is off.

Provenance is about how an endpoint was set, not what it points at. An explicit PUT or an operator seed counts as tenant even when its URL happens to equal the one wative-core ships.

Every answer says where its endpoint came from

Resolution is never ambiguous. The reported source is one of three values:

GET /v1/workspace/networks reports it per network, and is the only place none appears — it is a description of configuration, not of a call.

The four transaction routes stamp the source on the response as the x-rpc-source header, so “why is this slow” or “which endpoint actually served this” is answerable from the response alone. The header only ever reads tenant or builtin: a network that would resolve to none fails with 409 before a response exists to stamp.

When a route needs an endpoint and resolution returns none, the call fails with 409 and code rpc_not_configured.

Setting an endpoint

curl -X PUT "$API_URL/workspace/networks/ethereum" \
  -H "Authorization: Bearer $TOKEN" \
  -H "content-type: application/json" \
  -d '{"rpcUrl":"https://your-endpoint.example.com/eth"}'

The URL is admitted through a boundary check before it is stored — an endpoint the service refuses to accept returns 400 with rpc_endpoint_rejected.

What the boundary accepts

Every rule below produces that same 400, so it is worth knowing them before you debug one:

There is no port restriction — a non-standard port is fine.

The name is resolved when you register it and on every request that uses it, and the resolved address is pinned for the connection. So an endpoint that starts resolving to a private address later begins failing, even though it was accepted at registration. The update is applied transactionally: if the new endpoint cannot be resolved after being written, the previous one is restored rather than leaving the workspace pointing at something unusable.

Requires the write scope. Reading the list requires read.

Failures you should expect

Chain-touching routes surface transport problems distinctly from on-chain outcomes:

A simulation that fails on-chain is a 200 with success: false and a revert reason. A simulation that could not complete at all is a transport error, and is never rendered as 200.

Related

• Networks endpoints — request and response shapes
• Send transactions — where RPC actually matters
• Errors — the full catalog