Annoucing new public RPC nodes for Tezos Community

Community Updates
1

Hello All,

In order to provide additional support to Tezos community, the infra team at Trilitech has launched following public RPC nodes which could be used by Dapps and Wallets and other tools for free under rate limit, in addition to the list of RPC node already published here.

Tezos Mainnet: https://tezos-mainnet.octez.io
Tezos Shadownet: https://tezos-shadownet.octez.io

For technical questions or any RPC nodes related issue, you can raise an issue on our discord channel Tezos Blockchain

4 Likes
2

Please update this page.

2 Likes
3

this is a great update that developers deserved to have a month ago with guides on how to set these for redundancy or security so there won’t be problems in the future… but also deserved to have after setting up working SSL certificates. as of writing I am seeing handshake errors.

1 Like
4

@ajinkyaraj-23 and Trillitech team. Congratulations for securing the required resources at Trilitech to allow your team to operate more of the Tezos/X infrastructure!

Will you have a dedicated status page for your new RPC services? I will list the new services on Taquitos docs and APIs.

Best of luck!

2 Likes
5

Hi Ajinka and team,

Again, congrats on getting the new public octez nodes up. More community RPC infrastructure is genuinely good for the ecosystem, and it’s great to see Trilitech stepping in to run so much of it!

We went to wire tezos-mainnet.octez.io and tezos-shadownet.octez.io into the Taquito docs (which run live code examples in the browser) and hit a snag: the nodes aren’t currently usable from browser-based dapps. The CORS config looks half-applied rather than intentionally locked down, so I figured I’d save you the debugging.

Specifically, the preflight is the problem. An OPTIONS request returns:

access-control-allow-methods: GET
access-control-allow-headers: Content-Type

but no Access-Control-Allow-Origin header. Browsers treat the missing origin as a hard fail, so any dapp calling the RPC directly from front-end JS/Taquito gets blocked at the preflight. Server-side and CLI usage are unaffected, it’s purely the browser path.

If these nodes are meant for dapps and wallets (as the announcement suggests), you’ll want the preflight to return an allowed origin. Two options:

  1. Access-Control-Allow-Origin: * — open to all origins. This is what the other public Tezos RPCs do (SmartPy, TzKT, the teztnets nodes), and it’s the path of least friction for dapp devs. Pair it with IP-based rate limiting and you get abuse control without blocking browsers.
  2. Origin allowlist — reflect Origin against an approved list. More control, but every dapp has to register domains (including localhost and preview deploys), and since anyone can still hit the node from a script, it gates browsers without really gating access. Most public RPC operators land on option 1 for exactly that reason.

Once you fix your new RPC nodes, we can confirm the preflight from the Taquito side and add the endpoints to our docs’ RPC list.

Best,
Jev

3 Likes
6

@ajinkyaraj-23 Thanks for sorting the CORS headers,Access-Control-Allow-Origin: * is showing on the preflight and the responses now, so browser dapps are unblocked. Appreciated.

The bigger problem is still there, though: the nodes aren’t usable as a public RPC because the RPC interface is wide shut. They’re serving Octez’s default remote ACL, the whitelist you get when you bind --rpc-addr to a public interface and leave it at that. Anything outside that whitelist comes back 401 Unauthorized, and that covers a lot of what wallets and libraries actually call.

To be clear, that default is the right policy for a baker’s own node, it’s there to keep strangers off the expensive and dangerous surface. Which is kind of the point: these were announced as public RPC nodes for dapps, wallets and tools, but they’re configured like private baker nodes. The ACL never got adapted to the thing you’re advertising.

Concretely, against tezos-shadownet.octez.io today, and tezos-mainnet.octez.io is identical, same policy, so neither was looked at:

Blocked (401), all of it needed by dapps/wallets:

  • POST …/context/contracts/<addr>/ticket_balance
  • POST …/context/contracts/<addr>/script/normalized
  • GET …/context/delegates
  • GET …/context/destination/<addr>/index
  • GET /chains/main/protocols (and /protocols/<hash>)
  • GET …/helpers/baking_rights
  • GET …/helpers/attestation_rights
  • GET …/context/raw/bytes/**

The write/simulate path is fine, run_operation, simulate_operation, forge, preapply and injection/operation all work, as do the common reads, so estimation and injection are OK. It’s the query, metadata and normalization endpoints that are walled off. (The POSTs are the tell: the default whitelist only allows big_map_get, injection/operation and context/seed, so every other POST query 401s.)

The fix is on your side — it’s your ACL to scope — but the short version is the public listener needs a policy built for serving dapps, not the stock baker default. I’d steer clear of --allow-all-rpc though; you don’t want injection/block and the admin surface open to the world.

For reference, ~25 of Taquito’s integration tests fail against these nodes right now purely on the ACL.

3 Likes
7

Hi @jevonearth ,
thanks for raising these issues. They have been all fixed except
GET …/context/raw/bytes/**

1 Like