Hey! I've faced an issue with encodeArguments function - when it tries to encode string into Fr it uses Fr.fromString, which always treats the input as a hex string. Even though I understand the rationale, this behavior is quite arguable, because it can be dangerous in some scenarios.
Imagine, a dAPP is sending an execution request to a wallet via walletconnect or something, for example, to call transfer(to, amount) function with arguments ("0x12..34", "100"), and a user is asked for confirmation. So, the user will check the args of the call and will see "100", and will mistakenly think that he is approving a transfer of 100 tokens. But "100" will actually be treated as hex and will be encoded into 256, so actually 256 tokens will be transferred. So, this behavior can not only mislead users, but also be exploited by scammers.
It would be cool if either ArgumentEncoder.encodeArgument or Fr.fromString treated input strings as hex only if it started with 0x, so that "100" is encoded into 100 and "0x100" into 256. This would be more intuitive and will help to avoid bad UX.
Hey! I've faced an issue with
encodeArgumentsfunction - when it tries to encodestringintoFrit usesFr.fromString, which always treats the input as a hex string. Even though I understand the rationale, this behavior is quite arguable, because it can be dangerous in some scenarios.Imagine, a dAPP is sending an execution request to a wallet via walletconnect or something, for example, to call
transfer(to, amount)function with arguments("0x12..34", "100"), and a user is asked for confirmation. So, the user will check the args of the call and will see"100", and will mistakenly think that he is approving a transfer of 100 tokens. But"100"will actually be treated as hex and will be encoded into256, so actually 256 tokens will be transferred. So, this behavior can not only mislead users, but also be exploited by scammers.It would be cool if either
ArgumentEncoder.encodeArgumentorFr.fromStringtreated input strings as hex only if it started with0x, so that"100"is encoded into100and"0x100"into256. This would be more intuitive and will help to avoid bad UX.