You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, during EVM calls, users see a large number of values that are not easily human-readable. To improve this, we propose parsing the calls and presenting them in a more understandable format.
Until clear signing is implemented, we should focus only on the most commonly used calls and hardcode them into the firmware.
Here is my suggestion for prioritized calls:
Approve() Revoke()
I’m unsure about the feasibility of parsing permit2() in a meaningful way — can this be parsed clearly?
transfer() and transferFrom() should already be supported iirc.
The text was updated successfully, but these errors were encountered:
we only support transfer() because transferFrom() is not useful for end-users -- it is transferring someone else's token under allowance.
permit2 is interesting: first, it's a regular Approve() call with a known destination (the Permit2 contract), which we may want to special-case -- but the user still need to approve each of their tokens for Permit2 separately
then there's an off-chain permit2 message which seems to be an EIP712 structure signable by EthereumSignTypedData -- we can do that today but a nicer representation would be helpful
...and then there's some other, possibly contract-specific? call that consumes the signature of this message.
so to make this extra nice, we'd have to integrate both those two things under a single confirmation, and that would be quite a lot of work.
but to only make it work it seems we don't have to do any additional work except for supporting Approve()
Currently, during EVM calls, users see a large number of values that are not easily human-readable. To improve this, we propose parsing the calls and presenting them in a more understandable format.
Until clear signing is implemented, we should focus only on the most commonly used calls and hardcode them into the firmware.
Here is my suggestion for prioritized calls:
Approve()
Revoke()
I’m unsure about the feasibility of parsing
permit2()
in a meaningful way — can this be parsed clearly?transfer()
andtransferFrom()
should already be supported iirc.The text was updated successfully, but these errors were encountered: