developers/networks says of the two Bradbury endpoints:
"The GenLayer RPC also passes through all eth_* and zks_* calls to the
underlying chain, so you can use either endpoint for standard wallet
operations."
That is not true for MetaMask, because MetaMask's Add network validation
calls net_version, which is neither an eth_* nor a zks_* method, and the
GenLayer RPC does not implement it (checked 2026-09-04):
$ curl -s -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"net_version","params":[]}' \
https://rpc-bradbury.genlayer.com
{"jsonrpc":"2.0","result":null,"error":{"code":-32601,"message":"method not found: net_version"},"id":1}
$ curl -s -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \
https://rpc-bradbury.genlayer.com
{"jsonrpc":"2.0","result":"0x107d","id":1}
eth_chainId answers 0x107d (4221) perfectly well, so the network is
reachable and correct — but MetaMask refuses it with "Could not fetch chain
ID. Is your RPC URL correct?". That error sends you hunting for a typo in a
URL that is right, and there is nothing on the page to suggest the URL is the
problem.
The GenLayer Chain RPC on the same page does implement it, and works:
$ curl -s -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"net_version","params":[]}' \
https://rpc.testnet-chain.genlayer.com
{"jsonrpc":"2.0","id":1,"result":"0x107d"}
Both report the same block height, so this is one chain behind two endpoints,
not two networks. CORS is permissive on both.
Two things would fix this for readers, and they are independent:
- Docs: say which endpoint goes in the wallet and which goes in the CLI.
The "use either endpoint for standard wallet operations" sentence is the one
that misleads; the tables already carry both URLs.
- RPC: implement
net_version on the GenLayer RPC. It is a one-line alias
for eth_chainId and it is what the most common wallet validates with.
One note if you take (2): the Chain RPC returns net_version as "0x107d".
The JSON-RPC spec has net_version returning the chain id as a decimal
string ("4221"). MetaMask tolerates the hex form today; other tooling may
not, so it is worth returning "4221" from any new implementation.
developers/networkssays of the two Bradbury endpoints:That is not true for MetaMask, because MetaMask's Add network validation
calls
net_version, which is neither aneth_*nor azks_*method, and theGenLayer RPC does not implement it (checked 2026-09-04):
eth_chainIdanswers0x107d(4221) perfectly well, so the network isreachable and correct — but MetaMask refuses it with "Could not fetch chain
ID. Is your RPC URL correct?". That error sends you hunting for a typo in a
URL that is right, and there is nothing on the page to suggest the URL is the
problem.
The GenLayer Chain RPC on the same page does implement it, and works:
Both report the same block height, so this is one chain behind two endpoints,
not two networks. CORS is permissive on both.
Two things would fix this for readers, and they are independent:
The "use either endpoint for standard wallet operations" sentence is the one
that misleads; the tables already carry both URLs.
net_versionon the GenLayer RPC. It is a one-line aliasfor
eth_chainIdand it is what the most common wallet validates with.One note if you take (2): the Chain RPC returns
net_versionas"0x107d".The JSON-RPC spec has
net_versionreturning the chain id as a decimalstring (
"4221"). MetaMask tolerates the hex form today; other tooling maynot, so it is worth returning
"4221"from any new implementation.