establish a universal schema for web3 address books (e.g. ERC)

[aspiers]

Motivation

rolod0x is not the final solution! Web3 address books should not be isolated to a single dApp or wallet or portfolio manager or developer tool. We should aim for a world where every EOA and smart contract should be labelled in a user-friendly way in every web3 UI, without users having to manually label them separately in each tool. This means that web3 UX should provide seamless synchronisation of address books across the whole ecosystem, whilst preserving user privacy and keeping sharing of addresses between tools a strictly opt-in but user-friendly process.

Indeed that was one of the main goals of rolod0x: to make an address book which works across any app and any chain. But a browser extension is also a form of moat, because it only works for web pages on desktop browsers, and not elsewhere like mobile apps, wallets, other desktop apps etc.

I have plenty of plans to build draw-bridges across the moat - see all these interoperability issues. However, all drawbridges will benefit from some kind of common interchange format which every tool can support. If web3 is able to standardise on this, then we stand a much better chance of general interoperability where every address book can work with any tool.

So this issue describes a proposal for how to achieve a common interchange format for web3 address books.

Potential users of this standard

• rolod0x (aim: be the first and reference implementation)
• All web3 wallets (e.g. MetaMask via a Snap)
• Crypto portfolio managers (both proprietary centralised services and Open Source decentralized ones such as Rotki, see also #81)
• Smart wallets
• Self-custodial asset management solutions such as Safe, Den, Palmera, Cryptio
• web3 developer tools such as Foundry, EDB: The EVM Project Debugger, OpenZeppelin Defender
• All block explorers in the etherscan family which support hosted private address books
• Auditors, auditing services, and their clients
• People and software involved with onchain analysis (including but not limited to sleuthing)
• https://app.icebreaker.xyz/
• https://github.com/verynifty/RolodETH and similar projects which aim to share public address book data
• https://docs.cabana.fi/cabana-app/vault-lists
• https://dune.com (e.g. see list of known CEX addresses)
• All onchain protocols which want to publish lists of their onchain addresses without creating ENS entries for all of them
• An allow-list of audited designator contracts for use by wallet teams
• Curators of lists of spam tokens / phishing contracts (e.g. see https://github.com/rotki/rotki/issues/8411)
• AI agents which support / understand onchain activity

Initially these tools could simply add support for import from / export to the standard format, but later automatic synchronisation functionality could be implemented so that address book data could seamlessly synchronise between tools according to policies approved by the user.

Design

The tokenlists.org JSON schema is really interesting, but it was (obviously) designed specifically for creating lists of tokens and nothing else. Hence it's not quite fit for purpose as a general address book schema, which also needs to support both EOAs and smart contracts which are not tokens.

So we could produce a modified version which is fit for purpose. Some of the modifications needed:

• [ ] Address type, e.g. EVM, Solana, Segwit, Native Segwit, Taproot
• [ ] Don't require chainId, since EOAs are inherently cross-chain, and contracts can be deployed with the same address on multiple chains. Alternatively chainId of 0 could mean any chain, but currently their schema enforces a minimum of 1.
• [ ] Don't require the TokenInfo section.
• [ ] Support signatures on individual entries
• [ ] Support signatures on whole sections
• [ ] Support linking to DIDs?
• [ ] Ensure it's possible to extend later in a backwards-compatible way (e.g. by including schema version) to add support for labelling other items such as event topics, function selectors etc. as per #28
• [ ] FIXME: more needed here

Could well be worth using https://standardschema.dev/ for the implementation.

There are also arguments for using something other than JSON, which I'm interested in exploring too. These don't necessarily have to be mutually exclusive with building a JSON schema.

[aspiers]

See https://gist.github.com/Beasta/26f630e524209c871812a5d88158af68 for a similar initiative. Thanks @Beasta!