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!

1 Like
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

6

@lcastillo-ledger How would someone support signing 712 messages for multisig or smart contract wallet like gnosis safe? We have thousands of safe wallets deployed and more being deployed everyday with same EIP712 signature structure. Would not be feasible to keep adding addresses all safe wallets across all chains in PR

7

Ah I love this!!! I’d like to add some functionality that I think will make all of this “just work”.

May I recommend a new ERC-7730 function called getWalletDocsUri. Here is an example solidity implementation

string constant DOCS_URI = "...."; // string here
uint256 public latestDocsVersion = 0;

function getWalletDocsUri(uint256 docsVersion) external view returns(string memory) {
   // Could easily add conditionals/mappings/etc here....
   return DOCS_URI;
}

This would return a URI (similar to that of an NFT) which has the JSON object with all the data. There are a few nice things about this:

  1. The JSON could be base64 encoded, so the entire documentation could be placed on-chain.
  2. It could be easily updatable, and map new versions of the docs based on the latestDocsVersion.

If you don’t wish to have your docs on-chain, then you could still host them on a site. Many tokens like ERC20s, could just point to another contract that already has the ERC20 ABI implemented, and would not have to spend any additional gas other than adding this additional function.

1 Like
8

They could all just point to a docs_uri based on the safeVersion:

So it would make your life actually really easy, almost no lift on your end.

1 Like