RPC error -32602: Invalid params
Last updated:
At a glance
| Property | Value |
|---|---|
| Code | -32602 |
| Message | Invalid params |
| Category | jsonrpc |
Cause
The method exists but the parameters are wrong: missing required args, wrong order/types, an invalid encoding, or an out-of-range value.
Solution
- Match the parameter order and types to the method signature.
- Use the correct encoding (base58/base64/jsonParsed).
- Validate ranges (slot/limit) before sending.
Read the message: the node usually names the problem
-32602 comes from the JSON-RPC 2.0 specification, so every chain uses it, but the useful part is the text after the code. It tells you whether the problem is the shape of the request or one value in it.
| Message contains | Network | What is wrong |
|---|---|---|
| invalid length, invalid type | Solana | Params is the wrong shape: count or JSON type |
| Invalid param | Solana | A value failed validation, such as a base58 address that does not decode to 32 bytes |
| invalid block range params | EVM (geth) | fromBlock is after toBlock |
| exceed maximum block range | EVM (geth) | The node caps eth_getLogs range: narrow it |
| block range extends beyond current head block | EVM (geth) | toBlock is in the future |
| beyond_retention | Stellar, TON | History is older than the retained window |
The mistakes that account for most of it
On Solana, params is a positional array, and the config object comes last: [address, {commitment}]. Passing an object where the method expects a string is the most common form. Numeric encodings are the second: slots are numbers, while EVM block numbers are hex strings. Sending 1000 instead of "0x3e8" to an EVM node, or "0x3e8" to Solana, fails with the same code. Another frequent cause is a value from the wrong chain: an EVM 0x address sent to a Solana method. Check the base as well: a transaction encoded in base64 fails if encoding still says base58.
Some methods take an object rather than an array. DAS methods such as getAsset use named params, so copying a positional example fails.
How to find the bad parameter
Start from the working example on the method's reference page and change one thing at a time toward your request. A failing request usually differs in one place: an extra array level, a number sent as a string, or a config key the method does not take. Sending the request with curl removes your client library from the picture. Libraries often wrap or rename parameters, so the bytes they send may not be what your code suggests.
Validate what you can before you send. Check that a Solana address decodes to 32 bytes, that an EVM address has 40 hex characters, and that a block range runs forward. These checks are cheap, and they turn a late, confusing node error into a clear message in your own code. Log the full request body on failure as well: without it, the error tells you that a parameter was wrong but not what you actually sent, and the value that failed is often one your code built at runtime.
-32602 or HTTP 400?
If the error arrives on HTTP 200 with an error object, a node answered it. If the status is HTTP 400, the gateway refused the request before any node saw it. The fix is the same kind of work, but only the first one is worth comparing against the node's documentation.
Example
{
"id": 1,
"error": {
"code": -32602,
"message": "Invalid params: invalid length"
},
"jsonrpc": "2.0"
}FAQ
- Why does "Invalid params" happen?
- The method exists but the parameters are wrong: missing required args, wrong order/types, an invalid encoding, or an out-of-range value.
- How do I fix "Invalid params"?
- Match the parameter order and types to the method signature. Use the correct encoding (base58/base64/jsonParsed). Validate ranges (slot/limit) before sending.
- Is -32602 retryable?
- No, unless the value depends on time, such as a block range ending past the head. The same params fail the same way.
- What is the difference between -32602 and -32601?
- -32601 means the method does not exist on that endpoint. -32602 means it exists and your arguments are wrong.