Currently, when a hardware wallet is attempting to clear-sign a transaction which includes a data suffix, the transaction either has to be blind signed, or sometimes the transaction may not be able to be signed at all.
ERC-8021 standardizes how data suffixes are structured, which means ERC-7730 could parse that data and omit it when verifying the transaction. Wallets which implement ERC-7730 could also optionally display this additional data.
- Clear signing: A feature of hardware wallets that allows them to show a detailed breakdown of a transaction for verification purposes
- Data suffix: Arbitrary data attached to the end of a transaction, often for analytics or rewards purposes
Base team members introduced ERC-8021 so chains and protocols have a structured way to do transaction attribution for things like rewards, analytics, app promotion, etc.
While the use cases ERC-8021 allows are important, the fact that it enforces a structured way of defining transaction data suffixes means it's flexible enough to allow for other use cases, protocols which currently use data suffixes can adopt with relative ease, and entities such as indexers and wallets can correctly separate the main transaction data from any attached data suffix. This last point is something that is not possible when using arbitrary, unstructured data suffixes.
Adding a data suffix to transaction data means the transaction data can look different than the expected ABI. When this transaction data is submitted onchain, the contract ignores any additional data it's not expecting. This feature of how additional data is treated by contracts has been used by protocols to do attribution, and has built-in support from tools like Viem.
Unfortunately, tools like ERC-7730 which expect transaction data to match a given ABI exactly can have issues with data suffixes.
The screenshot below shows what happens when one tries to sign an ERC-20 approve allowance transaction that includes a data suffix on a Trezor Safe 7 and the Trezor Suite desktop app:
We've gotten reports of issues with other device as well.
While there's little that can be done in this case if the transaction data includes an arbitrary data suffix, it's possible to handle this gracefully if the data suffix is structued as an ERC-8021 data suffix.
ERC-7730 could be updated so that implementors are aware of ERC-8021. If transaction data ends in the ERC-8021 ercMarker (16 bytes of 8021 repeated), the entity verifying the transaction data can parse out the ERC-8021 suffix and verify only the main transaction data.
Additionally, hardware wallets who wish to do so could display the ERC-8021 suffix data if they wished.
Discussion around ERC-8021 is happening in this Telegram group. Please feel free to ask any questions you may have about ERC-8021 there.