Check existing issues
Viem Version
2.31.7
Current Behavior
In the current hashStruct function to create a EIP-712 encoding, hashStruct calls a helper function encodeField in order to encode the data to match the EIP-712 standard. However, the handling of the bytes type is incorrect. The bytes type can accept both hex strings and UInt8Arrays as input, but the following snippet in encodeField improperly handles UInt8Array values through value.slice(2) and subsequent stringifying:
if (type === 'bytes') {
const prepend = value.length % 2 ? '0' : ''
value = `0x${prepend + value.slice(2)}`
return [{ type: 'bytes32' }, keccak256(value)]
}
There seems to be an implicit assumption here that the value should be a hex string. When a bytes field is passed as a Uint8Array into hashStruct, the resulting EIP-712 hash is not equivalent to hashing the raw bytes. Instead, it hashes a coerced string representation. This is also confusing, since viem does support passing in both hex or UInt8Arrays into other functions, such as keccak256.
Expected Behavior
The expected behavior should have some type guard / separate logic for properly handling UInt8Array types, instead of slicing the first two bytes off.
Steps To Reproduce
import { hashStruct, hexToBytes } from "viem"
// Minimal EIP-712 type definition
const types = {
Example: [
{ name: "data", type: "bytes" },
],
};
// Same data represented two ways:
const hexBytes = "0x010203";
const u8Bytes = hexToBytes(hexBytes);
// Hash using a hex string
const hashHex = hashStruct({
primaryType: "Example",
types,
data: { data: hexBytes },
});
// Hash using a Uint8Array
const hashU8 = hashStruct({
primaryType: "Example",
types,
data: { data: u8Bytes }, // viem accepts this without throwing
});
console.log({ hashHex, hashU8, equal: hashHex === hashU8 });
// keccak256, which also supports passing in hex or UInt8Array, doesn't have this issue:
const keccakHexHash = keccak256(hexBytes);
const keccakU8Hash = keccak256(u8Bytes);
console.log({ keccakHexHash, keccakU8Hash, equal: keccakHexHash === keccakU8Hash });
console output:
{
hashHex: "0x66283e3bdd0d3a5ae038dd9139268fe5055dcda22f357dd971a6e5d264ac0d3c",
hashU8: "0xd5eff98e5f9dc5c224151540b1402a2f33c6a5f1ccd8aba97eb35a467e54cc4d",
equal: false
}
{
keccakHexHash: "0xf1885eda54b7a053318cd41e2093220dab15d65381b1157a3633a83bfd5c9239",
keccakU8Hash: "0xf1885eda54b7a053318cd41e2093220dab15d65381b1157a3633a83bfd5c9239",
equal: true
}
Link to Minimal Reproducible Example
No response
Anything else?
This bug may also extend to hashTypedData, as it calls hashStruct if primaryType !== 'EIP712Domain'
Check existing issues
Viem Version
2.31.7
Current Behavior
In the current
hashStructfunction to create a EIP-712 encoding,hashStructcalls a helper functionencodeFieldin order to encode the data to match the EIP-712 standard. However, the handling of thebytestype is incorrect. Thebytestype can accept both hex strings and UInt8Arrays as input, but the following snippet inencodeFieldimproperly handles UInt8Array values throughvalue.slice(2)and subsequent stringifying:There seems to be an implicit assumption here that the value should be a hex string. When a bytes field is passed as a Uint8Array into
hashStruct, the resulting EIP-712 hash is not equivalent to hashing the raw bytes. Instead, it hashes a coerced string representation. This is also confusing, since viem does support passing in both hex or UInt8Arrays into other functions, such askeccak256.Expected Behavior
The expected behavior should have some type guard / separate logic for properly handling UInt8Array types, instead of slicing the first two bytes off.
Steps To Reproduce
console output:
Link to Minimal Reproducible Example
No response
Anything else?
This bug may also extend to
hashTypedData, as it callshashStructifprimaryType !== 'EIP712Domain'