James Bachini

Solidity Error Codes | Not Always What They Seem

Solidity Errors

I get a lot of comments from Solidity tutorial videos and in Github issues asking how to resolve common solidity error codes. In this article I’ll go through some of the most frequent solidity issues, what they mean and how to resolve them.


This is the most common and confusing error in Solidity

  • ‘UNPREDICTABLE_GAS_LIMIT’ reason: cannot estimate gas
  • cannot estimate gas; transaction may fail or may require manual gas limit

The error doesn’t actually relate to gas or paying transaction fees which is the most confusing and frustrating thing in Solidity.

The error is popped whenever a transaction will fail. So if you have a wrong contract address or are doing something stupid you’ll get this generic gas error.

Most common causes I see are related to moving contracts from testnets to mainnets. The token contract addresses will often change or there wont be a version of Uniswap on their local testnet which causes the deployment or transaction to fail.

Another absolute classic is copying the contract address from the URL in etherscan which converts it to all lowercase, which then fails the checksum, resulting in a gas error which is about as useful as a chocolate tea pot. You’ll often see gas limit and errors like this:

Error: invalid address (argument=”address”, value=””, code=INVALID_ARGUMENT

If you are getting the upredicatable_gas_limit error and have checked the stupid stuff then I’d recommend running it on a public testnet and putting the transaction hash into Tenderly to debug it from there.


The error ‘TransferHelper: TRANSFER_FROM_FAILED’ or safeTransferFrom compile error is related to the contract function not being able to move tokens on your behalf. Somewhere in the code there will be a transferFrom() or safeTransferFrom() function which will attempt to move tokens from a 3rd party account.

The most common cause for this error is not calling token.approve() prior to calling transferFrom()

Note that you need to call approve() from the holders wallet. I’ve got stuck many times trying to transferFrom the contract address or approving the wrong account. Use msg.sender for the user address calling the function and address(this) for the contract.

The common approach is to approve the transaction first as a separate transaction from the users wallet, then the contract will call transferFrom(msg.sender, receiverAddress, amount); which will send the tokens from the users wallet that called the function.

This can also go wrong when devs get confused on the frontend between ETH and WEI. Both these functions take a WEI value including the decimals. Note that most but not all tokens have 18 decimals and USDC is the common exception with 6. If you approve 1 and then try to transferFrom 1000000000000000000 it wont work and you’ll get the a TRANSFER_FROM_FAILED error.


The TypeError: “send” and “transfer” are only available for objects of type “address payable”, not “address” error occurs when we try to send ETH from an address without declaring it payable.

This is a simple fix where we just need to encapsulate the address in a payable wrapper before calling transfer.


If you get an error along the lines of:
Note: The called function should be payable if you send value and the value you send should be less than your current balance.

Then you may also need to add payable to the function modifiers so it can receive ETH.


This is something you’ll see if you forget to pass a constructor argument to a contract when deploying or call a function with the wrong amount of arguments.

Error (6160): Wrong argument count for function call: 0 arguments given but expected 1

Check the inputs and anything on the frontend which might have caused the wrong number of function inputs to be sent with the function call.


This is a type error and usually comes from trying to send variables from a loosely typed language in Javascript to a strongly typed language in Solidity.

The most common one is

Error encoding arguments: Error: invalid BigNumber string

The BigNumber library takes inputs as a string because Maths in Javascript is hit and miss. Try doing 0.8 - 0.1 in a browser console window

Javascript is fun

The error relates to being unable to convert between types or missing a function input or getting the function inputs the wrong way around.


EIP1474 sets out standardised error codes for RPC nodes and Solidity devs and web3 frontend devs will often come across these.

-32700Parse errorInvalid JSON
-32600Invalid requestJSON is not a valid request object
-32601Method not foundMethod does not exist
-32602Invalid paramsInvalid method parameters
-32603Internal errorInternal JSON-RPC error
-32000Invalid inputMissing or invalid parameters
-32001Resource not foundRequested resource not found
-32002Resource unavailableRequested resource not available
-32003Transaction rejectedTransaction creation failed
-32004Method not supportedMethod is not implemented
-32005Limit exceededRequest exceeds defined limit
-32006JSON-RPC version not supportedVersion of JSON-RPC protocol is not supported
have you tried using a database rather than a blockchain?

Get The Blockchain Sector Newsletter, binge the YouTube channel and connect with me on Twitter

The Blockchain Sector newsletter goes out a few times a month when there is breaking news or interesting developments to discuss. All the content I produce is free, if you’d like to help please share this content on social media.

Thank you.

James Bachini

Disclaimer: Not a financial advisor, not financial advice. The content I create is to document my journey and for educational and entertainment purposes only. It is not under any circumstances investment advice. I am not an investment or trading professional and am learning myself while still making plenty of mistakes along the way. Any code published is experimental and not production ready to be used for financial transactions. Do your own research and do not play with funds you do not want to lose.



, , , ,