type uint and int in TypeDataEncoder

[NIC619]

Are types uint and int valid types in the EIP712?

Hi, in EIP712 spec section, in the atomic types paragraph:

Definition: The atomic types are bytes1 to bytes32, uint8 to uint256, int8 to int256, bool and address. These correspond to their definition in Solidity. Note that there are no aliases uint and int. Note that contract addresses are always plain address. Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.

It mentions that there are no aliases uint and int. If I understand correctly, it means type uint and type int should not be allowed in the type definition?

I was not sure if my understanding is correct but I try using uint and uint256 separately for TypeDataEncoder and they seem to produce different hashes.

uint and uint256 types result in different hashes, which could create confusion

    const exampleDomain = {
        name: "Example",
        version: "1",
        chainId: 1,
        verifyingContract: "0x" + "1234".repeat(10),
    }

    const types1 = {
        Example: [
            { name: "tokenAmount", type: "uint" },
        ]
    }

    const types2 = {
        Example: [
            { name: "tokenAmount", type: "uint256" },
        ]
    }

    const values = {
        tokenAmount: ethers.BigNumber.from(123)
    }

    // 0x74a71fc690722bec75301db097706003c965859b866b8a0873fee59d1ca1fdbe
    const hashed = ethers.utils._TypedDataEncoder.hash(exampleDomain, types1, values)
    // 0x1f2bfdfb9005cfe1e72eb4654dc31903f9aa709b85ecc502833ce0e90de1114d
    const hashed2 = ethers.utils._TypedDataEncoder.hash(exampleDomain, types2, values)

I wonder if this is an expected behavior.

[ricmoo]

That is a good question. I would expect them to be visible only in the API logic; underneath, they should be normalized. I’ll look into this shortly. For now, I’d recommend sticking with uint256 and int256.