EIP-7730: Proposal for a clear signing standard format for wallets

EIPs
1

Hi All,

As Ledger, we want to improve the way user interacts with their wallets by displaying more clearly to them what message / transaction they are going to sign (what we call clear signing).

Basing the UI on the ABI does not lead to the best experience, the types are too broad and not easily interpreted as is. This proposal complements the definitions in the ABI with metadata targeted at specifying how to format the display of a transaction / messages for review.

Our goal is to make it easy for contract developers to define & control the interaction of their end users when calling their contract. Making it an EIP will enable all wallets to benefit from this information.

The ERC pull request is here: Add ERC: Structured Data Clear Signing Format by lcastillo-ledger · Pull Request #509 · ethereum/ERCs · GitHub

And for more info, we’ve created an intro video: https://www.youtube.com/watch?v=-O7aX6vUvs8

Thanks!

2

gm @lcastillo-ledger, how does this EIP handle multi-call and recursive parsing? For example, the uniswap router works via a multicall in many of the cases, so if we rely on the simple 7730 descriptors, it won’t be able to go into detail of what’s going on inside the multicall.

Let me know if this is something you’ve thought about

3

Hi @Ivshti and thanks for the feedback!

Indeed this is a case we’ve considered, and currently you’d handle it using the calldata format when defining your function, associated with a path of the form data.[], specifying that the formatter should be applied to all the elements of the data array. The calldata format tells the wallet that the parameter is a nested calldata, and should come with its own ERC 7730 file to describe how to clear sign it (can be the same file).

For example this is how we’d define the ERC 7730 file for the ERC-6357 multicall:

{
    "$schema": "https://github.com/LedgerHQ/clear-signing-erc7730-registry/blob/master/specs/erc7730-v1.schema.json",

    "context": {
        "$id": "ERC-6357 Multicall",
        "contract": {
            "abi": [ ... ]
        }
    },

    "display": {
        "formats": {
            "multicall(bytes[] data)": {
                "intent": "Execute Multiple Transactions",
                "fields": [
                    {
                        "path": "data.[]",
                        "format": "calldata",
                        "params": {
                            "calleePath": "@.to"
                        }
                    }
                ],
                "required": ["calls"]
            }
        }
    }
}

Note that this is not yet supported on Ledger devices, so this form has not been tested extensively. Most notable caveats:

  • I’m realising we’re missing a way to specify the values passed in the nested calls, and should probably be added in parameters
  • We’re also not distinguishing delegate calls from normal calls. Using a target of “@.to” wold work, but we might want to show that a call is a delegate call in the UI.
  • Packing / serializing calldata in unusual formats wouldn’t work without embedding complex logic in the ERC 7730, which defeats the purpose of having a descriptive model rather than a programmatic one
4

@lcastillo-ledger thanks for the answer

have you thought about how the multiple calls will be displayed to the user? Would the UI need to show nested intent texts, or will they be concatenated with “and” or just flattened at the top level?

Like, what if the multicall contains a swap and a transfer, would this show “Swap X for Y and send Z to …”

5

Replying for ledger here (since this is clearly wallet specific and will probably never be specific by the erc 7730).
Given hardware wallets constraints on memory and screen size, the very first implementation will probably be flattened with a clear separator between each calls until we know we whether we can do better.
So probably something like
Embedded Call 1 -----
Swap X for Y
Embedded Call 2 -----
Send Z to A