# Chain Addresses [Signup for calendar invite to calls](https://forms.gle/Q8iFCBxeCr9tJ6TMA) [Call #0 Agenda](https://docs.google.com/document/d/1HZb6h6VIbMt40k0tWsNe2gqb_VpOrmCYfd1VzHKwvxM/edit) _Below is a summary (with portions copy/pasted) of recent discussion from several people on the topic of "chain addresses"_ ## 1. Background - See [ERC-3770](https://eips.ethereum.org/EIPS/eip-3770) for previous discussion on this topic - In the current ERC-3770 spec, addresses look like this: `bobchain:0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326` - We are considering other options, most notably an ENS-based one: `[email protected]` ## 2. Notes - Motivation & Goal: - Improve L2 UX by setting an intuitive and human-readable standard for chain-specific addresses (potentially leveraging ENS). - Set a clear standard for the ecosystem, and get all major wallets to accept these addresses and to output these addresses. - Automatically handle bridging if someone puts an address into the "to" field that's on an L2 where you currently do not have assets. - Solve the pain points that are the biggest deal in cross-L2 UX today (eg. depositing to something like polymarket: right now you have to engage with confusing stuff like "bridging", and ideally the process of depositing to polymarket should just be clicking a button and the wallet moves funds over to polygon for you automatically). - Reminder: - Let's not boil the ocean :) - Whenever a discussion opens around "let's make X somewhat better", there's an impulse to say "while we're at it, let's try to solve this bigger underlying problem as a whole", and then after a couple of rounds of this, we get something too big to chew - How would leveraging ENS for this work: - L2 registers on ENS, and ENS points to the address of the L2 bridge contract. - use that ENS entry as a prefix or suffix to an address to identify on which chain you are interacting (e.g. [email protected]) - Benefits of ENS approach: - It's permissionless, and removes the need to maintain a centralized registry of L2s. - Anyone can spin up a chain, register it on ENS, and it'll be compatible. - Risks of ENS approach: - Name could expire. So we should encourage 99 year registration, and wallets should give a warning if a given address has less than 10 years left on it. - If you control the ENS name you can change the bridge contract address. So to verify you need to check both the bridge and the ENS name. - EVM chains that aren't "Ethereum-rooted" would get left out: tron, binance, etc, unless they setup a canonical bridge contract to eth L1. ## 3. Abbreviated roadmap 1. ERC-3770 and ERC-7683: Key milestone: all major wallets support these, and we actually get to the point where you can put a new-style address into the `To` field of a wallet, and it does a cross-chain send automatically. Users never have to treat "bridging" as a separate operation again 2. More advanced payment protocol: figure out the URIs, QR codes, etc, to make an ideal payment protocol work for wallets across the ethereum ecosystem 3. Figure out light client stuff. Ideally, move the entire concept of a "chain config", at least for ethereum-rooted chains, into the ENS record. Key milestone: "universal basic L2 read/write interface" works out-of-the-box on wallets that are willing to support it (see [endgame](https://notes.ethereum.org/LTZ7LgeRT_GbzD7hcazxdA?both#5-The-Endgame) below) 4. Sort out more advanced stuff like keystore rollups, proof aggregation, sharing preconfirmations, etc 5. After a critical mass of rollups are committing to ethereum in every slot (5-10 years from now): complement/replace 7683 with a "natively-cross-chain token" ERC20 replacement along the lines that @justindrake and others have been talking about. ## 4. Questions - How does this remove the need to maintain a centralized registry of L2s? - Today, the registry mapping which chain gets which prefix for ERC-3770 is basically just a file in our github. With this proposal, that same info would live on ENS. - You do need to have some kind of off-chain consensus on what is what somewhere. Wallet implementations would still realistically need their own registry of chain => IP addresses for RPC nodes. But that's something that's unavoidably going to be custom for each wallet anyway. - "In an ideal world: the contract itself would define the config of the chain, including details like how to verify state and receipt proofs" - "In practice: we can't boil the ocean, and have to deal with centralized RPCs for now..." - "when we have proper light clients and good p2p, you could have clients that are permissionless, so if your client has never heard of a given L2 before, and it walks through some network until it finds a way of getting state/proofs from that L2, it can then verify the proofs it provides against a verification function (similar to the ENS CCIP-read idea) that's itself provided in the contract that that L2's ENS points to" - In the ENS approach, if bobchain.eth reports that it has chainID 10, can someone trick Alice into signing a OP Mainnet transaction? - If we move toward making the ENS the canonical thing that specifies chain names, then we would also move toward signatures working that way too (this can be implemented in smart contract wallets quickly). But that's years away - What is ENS's latest thinking re L2 strategy? This is "enshrining" ENS at a deeper layer of the stack than we have been before, and so it creates a greater-than-before need for it to be "neutral". - "ENS wants to be neutral, so we are already thinking of going to our own L2" - Format: chain:0x123... vs 0x123....@chain (this is independent of ENS-or-not). The main consideration here is just what looks more pretty and less scary to people? - How do testnets fit into this? (ideally, this would include testnets that you spin up locally, so it would not have a dependence on mainnet ENS) - What is our "official recommendation" for how non-ethereum-rooted EVM chains (eg. binance, tron) should fit into this? - "I think what I had in mind is something looser: not trying to bring them "under our umbrella", but making it clear what their umbrella can be. A simple strawman would be, if they have their own ENS equivalent, they can just use that, eg. Tron has .trx" - Opportunity to also push wallets to make checksumming mandatory. One really nice way to do this gracefully is to make it mandatory only for the new-style addresses to start off (as there are no backwards-compatibility concerns there), and then retire old-style addresses over time. What do people think? - But don't people already have the same address on all the chains? - Either there should be a strong push to guarantee that same addresses are more consistently available (this would require a strong alignment between the L2s, including zkSync and other non bytecode EVM compatible L2s). Or we embrace that we longterm will not have the same address on all networks (this would require that we start create building blocks so that we can better handle this). EIP-3770 assumed the later. It was meant as an initial building block to tackle that addresses will not be the same across all chains. - Should there be a dedicated TLD for chains? (e.g. `.chain` rather than `.eth`) - Should we jump straight to pushing for an ENS-based config? - We don't want to make a stronger push to moving everyone toward ENS unless a couple other problems are solved first. The main issue is that it's a significant degradation of privacy if we're saying that we're organizing the entire UX around the assumption that all your addresses are tied to a public identity. And better to use the move toward different addresses on different L2s as a forcing function to get the infrastructure built to make more comfortable using different addresses on _the same_ L2, so that we can actually start to have privacy again. - Can we just make this all the responsibility of dapps, rather than wallets? - "Cross-L2 transfers should be the responsibility of wallets, not the responsibility of dapps. The reason for this is simple. First, there are like 10000 dapps, and there are like 20 wallets. Second, we want it to be possible for dapp UIs to be as immutable and static as possible. So polymarket should not have to worry about *how* they're cross-L2 transferring, they should only have to declare *that* they're cross-L2 transferring, and it's the wallet's job to figure out how" - What about using a private 3rd party solution with trust assumptions? - "Cross-L2 transfers should be a "basic public utility", NOT a "privatized solution". That means, there should always be a "universal basic backup" way to move tokens between different L2s, that (i) involves no trust assumptions except for the integrity of ethereum and the L2s in question, (ii) does not depend on liveness or safety of any specific servers, and (iii) involves no protocol/governance tokens except perhaps ETH itself. If individual wallets discover that for a specific trade, there is a way to do it that gives more favorable rates / faster settlement / lower gas, they should, but that's extra benefit on top" ## 5. The End(game) V: a note on the endgame that I think this is all building towards: Imagine a world where (i) a version of ERC-3770 based on ENS is adopted, and (ii) an extended version of ERC-7683 is adopted that lets you specify not just wanting tokens on a destination chain, but also wanting to make a specific call on a destination chain. Now, suppose that I launch a new L2, call it Bobchain. With (i) and (ii), as soon as I complete setup, Bobchain will get a basic level of functionality on all compliant wallets _permissionlessly_. Let's see how: 1. I launch an L2, and set up a bridge contract. I register it on ENS as bobchain.eth 2. Now, I start telling users about it, and users start getting addresses, eg. [email protected] 3. Suppose that Alice sees a payment request from someone, asking her to send them ETH to that address. Her wallet will then automatically have all the information it needs to know how to construct an ERC-7683 message that sends that payment. She sends that message on-chain (eg. on ethereum L1, or on whatever L2 she is already on). She doesn't need to do anything else. 4. Now, suppose that Alice gets sent dog coins on Bobchain, and she wants to dump them. The bobchain config tells her that the chain is EVM-compliant. She sends a transaction on her current L2, which is an extended ERC-7683 message saying "I will pay whoever pushes this data onto Bobchain". The data itself is an ERC-7683 message saying "I'm sending all my dog coins to this contract, whoever can send me enough ETH on Base and can pass through a proof gets those dog coins". So we can see that Alice can do a surprisingly large amount without needing to have _any_ pre-existing information about Bobchain, beyond the config. Later on, once L2s adopt light clients with CCIP-read, and once we figure out a good off-chain p2p discovery for this, Alice will be able to ask the network "please give me a light client proof for a call with data X executed on bobchain.eth", and she will get a proof. And so with 3770 + 7683 + CCIP-read (3668), we basically get a default minimal viable light client _for every compliant L2 by default_, without wallets having to make any config whatsoever. Obviously, wallets are going to be sophisticated and _want_ to offer better tiers of functionality, whether through centralized RPC nodes that they control, or to help users understand what's going on in more detail, but that is all functionality that would be available on top of this base.