Case sensitive token addresses

hey it looks like safe API is case sensitive on token addresses. Since ETH addresses are not case sensitive I would propose to fix this. our application has tons of bugs because of it and we don’t know how to fix them properly since our code should guess case of each symbol before calling api

valid:

curl -X ‘GET’
https://safe-transaction-goerli.safe.global/api/v1/tokens/0x11fE4B6AE13d2a6055C8D9cF65c55bac32B5d844/
-H ‘accept: application/json’
-H ‘X-CSRFToken: HjGRQc3BS64B0Io3A4lsw1rZGg48AYI9nJpCNwOGLCOM7vxqA0Z6GqmYfTUnSsMU’

invalid:

curl -X ‘GET’
https://safe-transaction-goerli.safe.global/api/v1/tokens/0x11fE4B6AE13d2a6055C8D9cF65c55Bac32B5d844/
-H ‘accept: application/json’
-H ‘X-CSRFToken: wneM95mjEQ4zyp7R8fHJPBhyhoKsCCrGZ6vhUL23nQReLSWlz0dRr8owCgawp5Ob’

2 Likes

I agree the API should probably fix this, but in the meantime, I have a fix for you :slightly_smiling_face:

It’s not actually random, it follows EIP-55: Mixed-case checksum address encoding
The rationale for this EIP was to prevent mistyped or mis-copied addresses, if the letters weren’t capitalized correctly according to this standard, the idea was for the wallet to throw an error, but wallets often just ignore the capitalization nowadays.

So you can just convert addresses on your system to their “checksummed” form.
Example for Ethers.js: Addresses
Example for Web3.js: web3.utils — web3.js 1.0.0 documentation

oh I see now… never knew about this particular EIP, very interesting…

Any way I don’t see any reasons why it should be implemented in the gnosis API, since there is a list of supported tokens and we can validate address simply by checking that provided address is known by gnosis and thats it. Also I cannot imagine smart contract address that differs from other smart contract address by a single character…

dev should definitely remove this from the API since its a bit of overengineering

@SanLeo461 thank you a lot! My team are started to set this up this everywhere across the project.

1 Like