RPC error -32601: Method not found

Last updated: October 24, 2026

At a glance

Cause

-32601 is the code the JSON-RPC 2.0 specification reserves for a method that does not exist or is not available. The request itself was well-formed: the node parsed it, read the method string and found no handler registered under that exact name. Spelling and casing. Method names are matched as exact strings, so getAccountInfo and getaccountinfo are two different methods, and so are eth_getBalance and eth_getbalance. Leading or trailing spaces inside the string count as part of the name. The other chain's dialect. Solana methods such as getSlot or getSignaturesForAddress do not exist on an EVM node, and eth_ methods do not exist on a Solana node. A client library pointed at another network's endpoint fails with exactly this code. A namespace the node does not expose. EVM clients serve debug_, trace_ and txpool_ only when those namespaces are switched on, and vendor-specific extensions exist only on the nodes that implement them. The method is real; the node that answered simply does not offer it. On Triport the response tells you which layer refused. A method outside the published catalog for that chain is refused before it reaches any node, normally by the gate with HTTP 403 and "error": "method_unknown" plus the chain and method fields; the TON surface answers methods outside its 13-method read-only catalog, such as sendBoc, with -32601 itself. A method inside the catalog is forwarded, and if the node answers -32601, that code and message are passed through unchanged.

Solution

1. Copy the method name from its reference page instead of typing it, and compare it letter by letter, including case. Make sure method is a plain string with no surrounding spaces.
2. Check that the endpoint and the method belong to the same network: Solana methods go to a Solana endpoint, eth_* methods to an EVM endpoint. The method catalog at triport.io/docs/methods lists what each chain serves.
3. If the answer was HTTP 403 method_unknown rather than -32601, the method is not part of that chain's product. A plan upgrade does not change this; a plan problem is reported as 403 tier_insufficient with current_tier and required_tier.
4. If the method is in the catalog and the node still answers -32601, keep the full request and response and report them. Retrying the same call in a loop does not help: the name is what is rejected, not the timing.
5. In a batch, a node's -32601 belongs only to the element with that id — the other elements return their own results, so fix and resend just that one. If the whole batch came back as 403 method_unknown, one element named a method outside the catalog and none of the batch was executed.

Example

{
  "id": 1,
  "error": {
    "code": -32601,
    "message": "Method not found"
  },
  "jsonrpc": "2.0"
}