When calling a method on a smartcontract, the first 4 bytes of input-data encompass the methodId.

For instance the methodId 0xa9059cbb (4 bytes => 8 hex characters) is the hash of the well-known transfer(address to, uint256 value) signature of a ERC-20 contract.

As is the case with these short hashes, multiple method-signatures may map to the same hash. In fact, the above hash 0xa9059cbb has 4 known (and probably more unregistered) method-signatures as can be seen here

Question: If I have both the methodId (e.g.: 0xa9059cbb) as well as the contract sourcecode (courtesy of a etherscan download for example), how would I derive the unambiguous method-signature?

This seems to be possible since it's exactly what etherscan is doing. For example have a look at this transaction. Listing the methodId and corresponding (very pretty) method signature:

Function: shitClaim(uint256[] tokenIds)
MethodID: 0x767cf6ee

How does Etherscan do the translation 0x767cf6ee -> shitClaim(uint256[] tokenIds) ?

2 Answers 2


At some point someone must have verified a contract that had a shitClaim(uint256[]) function.

Using ethers.utils.* functions:

hexDataSlice(keccak256(toUtf8Bytes('shitClaim(uint256[])')), 0, 4) => 0x767cf6ee

So now every time a transaction is made to a function 0x767cf6ee, even if that contract’s source code has not been verified, Etherscan presumes it’s shitClaim(uint256[]).

If you actually verify a contract with a different function that happens to also produce 0x767cf6ee, I don’t know whether Etherscan will “correct its ways” and start displaying the correct function, or else persist with using shitClaim(uint256[]). I guess you’ll have to try it out in order to know.

Also relevant to this topic: 4byte.directory, and there are other services too.


Since it's a hash function, it can't be reversed. So you can't figure out the original string directly based on its hash (especially true for a truncated hash).

However, it's rather trivial to keep a database of such known hash transformations, or to query an existing one. Have a look here for example: https://www.4byte.directory/

So, when Etherscan sees a method ID, it checks its database and displays some of the matching function signatures. Unsure how it chooses which one to display - probably the most common one.

  • Yeah I realise that a hash can't be reversed. Given that I have the original source, it should be possible to - derive all method-signatures in said contract (part 1 of solution). - Then the method-signatures need to be hashed. Not sure about the hash function here (part 2 of the solution) Then just check for a hash-match. Do you happen to know how to do any of these steps? Pretty certain Etherscan won't rely on that opensource DB to be honest. It must be along the lines I've described. Question is how
    – Geert-Jan
    Commented Jun 11, 2022 at 17:07
  • Well if the source code is available, then of course you can calculate the IDs. Actually it's much easier from ABI, but they can use whatever search pattern to extract the ABI from source code - they'll need the ABI anyway. Not sure how exactly it's done, but I don't think the details are too interesting anyway Commented Jun 11, 2022 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.