What happened
While integrating the Permissionless Relayer for the MetaMask Dev Cook-Off, we called:
{ "method": "relayer_getCapabilities", "params": ["84532"] }…and got back an empty object {}. No error, no message. We spent a debugging session checking our request shape, the chain-id encoding (string vs number), and whether the relayer was down — before concluding by elimination that the permissionless relayer simply doesn't serve Base Sepolia, and redesigning our demo around an opt-in mainnet leg that night.
Related: 1Shot-API/1Shot-API-Examples#1 asks for a clear testnet vs mainnet endpoint matrix in the docs — fully agree, and this issue proposes the complementary API-level fix so integrators get the answer at runtime too.
Suggestion
Make "unsupported chain" an explicit signal rather than an empty object:
{
"84532": { "supported": false, "reason": "the permissionless relayer serves mainnet chains only" }
}or a top-level supportedChains: ["8453", …] field in the capabilities response. Either is a small change, and it converts a half-day of head-scratching into a one-glance answer — especially for hackathon teams who reach for testnets first by reflex.
Context: the integration this came from (mainnet castVote relay, 7702 burner upgrade through the relayer, webhook status receiver with Ed25519/JWKS verification) is open source here: https://github.com/beautifulrem/regent (live demo: https://mandate-app-murex.vercel.app)
What happened
While integrating the Permissionless Relayer for the MetaMask Dev Cook-Off, we called:
{ "method": "relayer_getCapabilities", "params": ["84532"] }…and got back an empty object
{}. No error, no message. We spent a debugging session checking our request shape, the chain-id encoding (string vs number), and whether the relayer was down — before concluding by elimination that the permissionless relayer simply doesn't serve Base Sepolia, and redesigning our demo around an opt-in mainnet leg that night.Related: 1Shot-API/1Shot-API-Examples#1 asks for a clear testnet vs mainnet endpoint matrix in the docs — fully agree, and this issue proposes the complementary API-level fix so integrators get the answer at runtime too.
Suggestion
Make "unsupported chain" an explicit signal rather than an empty object:
{ "84532": { "supported": false, "reason": "the permissionless relayer serves mainnet chains only" } }or a top-level
supportedChains: ["8453", …]field in the capabilities response. Either is a small change, and it converts a half-day of head-scratching into a one-glance answer — especially for hackathon teams who reach for testnets first by reflex.Context: the integration this came from (mainnet
castVoterelay, 7702 burner upgrade through the relayer, webhook status receiver with Ed25519/JWKS verification) is open source here: https://github.com/beautifulrem/regent (live demo: https://mandate-app-murex.vercel.app)