If a param of type address is included in a function call, it appears that the function stack used to encode TX data is as follows:
Contract.php->getData
Ethabi.php->encodeParameters
IntegerFormatter.php->format
At the point of integer formatting, a padding function is used to ensure the length of the hex encoded string reaches 64 chars by padding it with zeroes. However, for some reason if the address starts with f, then the character 'f' is used to pad the string.
The activity of padding it with f causes transaction execution to fail, and appears to differ from encoding of the same transaction by Metamask.
If padding is changed to be 0 in all cases, transaction execution appears to work as expected, and in limited testing, no other adverse impacts are seen.
@sc0Vu can you please explain when padding with f is suitable instead of 0?
If a param of type
address
is included in a function call, it appears that the function stack used to encode TX data is as follows:At the point of integer formatting, a padding function is used to ensure the length of the hex encoded string reaches 64 chars by padding it with zeroes. However, for some reason if the address starts with
f
, then the character 'f' is used to pad the string.The activity of padding it with
f
causes transaction execution to fail, and appears to differ from encoding of the same transaction by Metamask.If padding is changed to be
0
in all cases, transaction execution appears to work as expected, and in limited testing, no other adverse impacts are seen.@sc0Vu can you please explain when padding with
f
is suitable instead of0
?