web3.soliditySha3 vs ethers.solidityKeccak256 different results for string numbers

I am having a little trouble matching Sha3 hashes between ethers and web3, and was wondering what the issue is.

web3.utils.soliditySha3("hello") will yield the same hash as ethers.utils.solidityKeccak256(['string'],["hello"])

but,

web3.utils.soliditySha3("1234") does not yield the same hash as ethers.utils.solidityKeccak256(['string'],["1234"])

what is happening here?

thanks

[4skinSkywalker]

@ricmoo in my opinion you’ve structured ethers way better than Web3.js, infact it resonated well to me the way the API is organized. I particularly like the separation of concerns between Provider and Signer.

Anyway, in the end I imported Web3Utils and used soliditySha3 from it, because our users have value in mainnet already and if the hash functions changes its output they won’t be able to unlock those values anymore…

I hope that FIXME up there won’t eventually change/break stuff in the future.

[ricmoo]

If you need to reverse engineer the guessing logic, it is here.

This will likely explain most of the discrepancies, and help figure out what type you need to pass into ethers to get the same result.

You could also probably use web3.utils.toHex(value, true), which will return the guessed type instead of the hex value (the “true” indicates “return the return type”).