Tagging Addresses on your Lattice 🏷️

At the beginning of 2021 we launched an ABI decoding feature on the Lattice1 hardware wallet. This allows users to load smart contract function definitions onto the Lattice — when any saved function gets called in a future transaction request, the Lattice shows its user decoded transaction data, which is relatively readable compared to a string of hexadecimal data.

Below is a picture of how that looks for a simple ERC20 token transfer.

ABI-decoded transaction request (ERC20 transfer)

Contract Definitions vs Addresses

The discerning user may notice this decoding feature operates independently of any specific smart contract instantiation. For example, the token transfer data pictured left is displayed for any ERC20 token — it maps to the function being called, not any specific contract address or its state.

While the ABI decoding feature has been great for giving users more information before signing a request with a high value private key, it has its limits. For example, someone could call a token transfer on a malicious token using the same ERC20 ABI definition and that transfer would look like any other.

This means that, in theory, browser injection attacks such as the famed NXM attack are still possible (though much more restrictive). An attacker could, in theory, deploy a malicious contract with a familiar ABI and target a MetaMask user with a fake transaction request that simply replaces the contract address with that of their own malicious contract. To be clear, this is extremely difficult in practice, but still technically possible for a very sophisticated attacker exploiting certain types of contracts.

Thus the problem is clear: we need ABI decoding and address verification. As we all know, addresses are themselves just hexadecimal data strings and not really human readable. They are shorter (and thus easier to read) than large blobs of hex data but still not a great solution for the average user who doesn’t want to memorize address strings.

How to Add Address Tags

GridPlus is happy to announce a solution to this problem in the latest Lattice firmware release — v0.12.0. Starting today you can “tag” addresses by going to https://wallet.gridplus.io and clicking on the Address Tags menu item:

Web Wallet -> Address Tags

You can click on Add Addresses and create a tag :

Add a tag

This will make a request to your Lattice, as pictured below.

Save address tag

Once you authorize this request, the tag will be saved to your Lattice’s secure storage. This mechanism will feel similar to adding ABI definitions — you must authorize any new data on a secure screen before it can be saved to the Lattice’s secure storage.

Aside about ENS

We often get questions about why we don’t support ENS natively in Lattice firmware. The answer is simple: we are not comfortable with Lattice firmware fetching data from the Internet and then displaying that data on a secure screen without prior user approval. As a reminder, all Lattice screens are drawn by the secure compute environment and are therefore all secure screens — for more info on the Lattice architecture, see this article. Displaying data fetched from the Internet would require users trust the data source and we do not believe that is an acceptable tradeoff. Instead, we require users confirm data on a secure screen before it can be used in later requests. This means a user must sign off an all data that could be used to modify a request screen (e.g. ABI function definitions and, now, address tags).

We are big fans of the ENS project as well as the Sourcify project, which aims to standardize verification data on ABI definitions. We are very interested in ways to utilize these projects to avoid the data pre-authorization step, but we must first be comfortable about the data verification process for each. Like many other things, it’s on the roadmap.

It’s worth pointing out here that someone could easily write a script utilizing the GridPlus SDK to fetch all ENS names used by an address and load them into the Lattice in bulk. Up to 10 address tags may be added per request and this script could run on a loop. Just an idea. 😉

Anyway, back to the Web Wallet. Now that the tag has been added it should show up on your Address Tags window:

Saved address tag now visible

Any time you want to remove a tag you may do so from this interface using the Delete button pictured above.

Using Address Tags

Once a tag is saved to your Lattice, all future requests that use this address will automatically replace the hex string with your tag. This covers the following three Ethereum (or, more generally, “EVM chain”) request types:

1. `to` is tagged

1. Normal transaction requests where the `to` address is saved as a tag

The To field is always an address (for contract calls it’s displayed as Contract — this is pictured in the next section).

If this address matches a tag found in the Lattice’s secure storage, the address will get swapped out with the tag name. Two square brackets wrap the name to more clearly indicate that it has been replaced.

2. Tags in ABI decoded transaction data

2. ABI-decoded transaction requests where an address tag is contained in the payload

In addition to the To (or Contract) tag, ABI-decoded payloads also display address tags.

This replacement happens for contract functions where one or more parameters is an address type which matches a saved tag. Importantly, tags will not display if the address in question is contained in a string or bytes type.

3. Tags in EIP712 requests

3. EIP712 requests where an address tag matches an address parameter

Similar to ABI-decoded payloads, EIP712 requests contain parameters with known types. If there is a parameter in a request with an address type that matches a saved tag, it will be replaced.

Also like ABI-decoded payloads, string and bytes types will not swap tags. This is pictured to the left: notice how owner matches the address tag I saved earlier. It is not swapped here because the owner type in this request is a string and not an address.

In summary, Ethereum-based requests coming into the Lattice will now check for saved address tags any time they run into an address type of parameter. There are a few relatively small limitations discussed above, mainly that the parameter has to be an address and not a string or byte array.

We hope you will enjoy tagging contracts and addresses with which you frequently interact. As always, to update your Lattice simply visit Settings -> Software Update and install v0.12.0. Stay safe out there ✌️