Native support for data type of `Address`

[dotansimha]

[dotansimha]

@azf20 can you please share more info on how it should be parsed on the client and how should it be represented as TS type?

[azf20]

Ethereum addresses are checksummed, but graph-node returns address fields lowercased. This can lead to confusion on the client side (e.g. if users try to match lowercased with checksummed based on string matching).

We could use something like https://docs.ethers.io/v5/api/utils/address/#utils-getAddress to checksum addresses appropriately

[matthewlilley]

Ethereum addresses are checksummed, but graph-node returns address fields lowercased. This can lead to confusion on the client side (e.g. if users try to match lowercased with checksummed based on string matching).

We could use something like https://docs.ethers.io/v5/api/utils/address/#utils-getAddress to checksum addresses appropriately

Yes, this has definitely been confusing. I always wondered if there was a reason for enforcing lowercased addresses since the common convention is the opposite, to use checksummed addresses.

[matthewlilley]

Ethereum addresses are checksummed, but graph-node returns address fields lowercased. This can lead to confusion on the client side (e.g. if users try to match lowercased with checksummed based on string matching).

We could use something like https://docs.ethers.io/v5/api/utils/address/#utils-getAddress to checksum addresses appropriately

There is one reason they may have decided to do this that I can think of, for sorting... I know that at least in JS, you cannot sort checksummed addresses correctly, they have to be lowercased.