Trezor adds readable signing for supported contracts

Trezor makes supported contract actions readable

Trezor announced Clear Signing for supported Ethereum-compatible transactions. Instead of presenting only opaque transaction data, the device can show an understandable action, asset, amount and destination. Coverage depends on a supported ERC-7730 description. Unsupported contracts still trigger the blind-signing warning. Trezor names Safe 7, Safe 5, Safe 3 and Model T with standard firmware; Model One is excluded.

What ERC-7730 contributes

ERC-7730 is a structured format for describing how transaction information should be displayed. Its specification binds a description to a particular context, including the relevant blockchain and contract address. A wallet must verify that the data being displayed matches that context. This is why a readable description cannot safely be attached to an arbitrary transaction just because the wording looks helpful.

The specification also discusses misleading descriptions, registry poisoning and compromised frontends. It calls for checks around provenance and the relationship between formatting and the actual data. Those design requirements are a reminder that readability is an important part of verification, but a familiar project name is not a universal endorsement of every request carrying that name.

A concrete comparison at the moment of approval

Imagine a fictional application that asks Nina to swap 50 units of Token A. Before approving, Nina has a simple expectation: a specific action involving a specific asset and amount. If the device instead describes permission for a different action, a different token or a much larger quantity, the discrepancy is meaningful even if the website still shows the original friendly summary.

The example does not assume that every swap displays exactly the same fields or that every contract has coverage. Its purpose is to show what an understandable device screen lets a person compare. A sequence of unreadable characters leaves little room for that comparison. A description of the actual action gives the person a chance to identify a mismatch before authorising it.

Nina can also pause when the information is incomplete. The absence of a field she expected is a question to resolve, not something to fill in from memory. An approval should be based on what the transaction actually asks, rather than on what the person remembers intending several screens earlier.

Coverage is specific to the action being signed

A useful way to evaluate the feature is to begin with one ordinary task and follow the result. Record the device model, software versions, network and contract interaction. Observe whether the device provides a readable description or falls back to a warning. That observation says something about that tested path; it should not be stretched into a statement about every application on the network.

For example, a person might successfully review one action in an application and later encounter a different action that is not described in the same way. The second prompt deserves its own attention. Familiarity with the first should not create an automatic approval habit. This is a proposed evaluation method, not a report that we have tested particular contracts on Trezor hardware.

The same idea helps developers communicate coverage. A release note identifying supported actions gives users a more useful expectation than a broad claim that an entire ecosystem is “clear signed.”

Use clearer information to make a deliberate decision

Our reading is that the main improvement is the chance to compare intention with an intelligible request on the device. It does not remove the need to decide whether the requested action is sensible. A perfectly readable instruction can still be an instruction the user does not want to approve.

Suppose a person understands that a transaction grants a permission but does not understand why the application needs it. The next useful step is to investigate that permission, not to approve simply because the text is readable. Likewise, an unexpected destination is worth checking even if its format is valid. The value of a clearer display is that it makes these questions visible at the decision point.

For readers, the practical change is therefore less guesswork during supported interactions. The strongest habit to pair with it is a short comparison: what did I intend, what does the device say, and do those descriptions agree? That keeps the feature focused on understanding an action before it is signed.