I’m late to the party, but I’d love to see EIP-3770 move to review then final!
Two tiny recommendations:
- drop the
0xprefix since it doesn’t really convey any useful information; and - move the table of prefixes into the EIP itself.
2 Likes
Would love to see this going through to final! @lukasschor what is needed to make it a reality?
4 Likes
Hi, I just want to express my support for this EIP!
It would be awesome to see automatic chain switching or alert when prefixed addresses are pasted into wallets, and prefix added when copied. Is there anything the community can do to nudge this in the process?
I was surprised to see this EIP in draft mode. Seems Gnosis Safe already implemented it and that the scope is well-defined. I’d also suggest moving it into review.
2 Likes
Great EIP, and I am already using this at Coinshift.
However, the shortName field in https://chainid.network/chains.json is not consistent with the example screenshot in the EIP.
For ex -
should we use matic:0x123… or poly:0x123…
same with xdai:0x123… or gno:0x123…
2 Likes
It would be very useful to expand this ERC to cover transaction hashes as well (or create a new ERC). Happy to help
3 Likes
I have seen this with Gnosis Safe and love it.
1 Like
I’ve seen this ERC come up for discussion every now and then since its creation. People seem to generally like it, which is unfortunate, because it is completely useless next to CAIP-10. To be clear, I don’t believe that 3770 is a bad or poorly conceived proposal on its own merits. Rather, I believe that a world where we adopt 3770 alongside or, horror of horrors, instead of CAIP-10 is simply worse in every way than if we all rally around CAIP-10.
The Ethereum ecosystem is increasingly multichain, and in need of a multichain address format. We can consider the problem from a technical and UX standpoint.
Obviously, having unambiguous addresses is desirable from a technical standpoint. 3770 and CAIP-10 are equivalent in this respect for Ethereum, but CAIP-10 is superior in that it can represent addresses from any protocol. As a developer, you may or may not care about this capability, but it doesn’t hurt you if it exists, so why not choose the more powerful option?
For the UX standpoint, let’s start by reviewing the 3770 Motivation (emphasis mine):
In [a multichain] context, addresses become ambiguous, as the same address may refer to an EOA on chain X or a smart contract on chain Y. This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address which was not deployed on a particular chain.
This implies that users will handle raw 3770 addresses, and perhaps use them to distinguish between addresses on different chains. However, we all know that raw addresses in the UI are considered harmful, which is why wallets and designers generally try to abstract them away using techniques like address books / petnames. Perhaps ovm:0xdeadbeef... (3770) is more readable than eip155:10:0xdeadbeef... (CAIP-10). But, once the UI knows which chain a particular address is associated with, it can display any conceivable user-friendly representation of that address. In other words: handling raw addresses in the UI is an antipattern, and the format doesn’t matter for UX purposes.
The likeliest way that users will continue to interact with addresses is copying them from location A (say, the dapp) and pasting them into B (say, the wallet). Here again the address format doesn’t matter so long as it’s unambiguous, and for the growing number of dapps and wallets with aspirations to facilitate use cases beyond the EVM ecosystem, CAIP-10 is again completely superior.
I commend the authors for their foresight in drafting this ERC, but urge them to withdraw 3770 and promote CAIP-10 instead.
2 Likes
GM there, fren:
There may already be a draft or submitted EIP I don’t know about, but there is also a draft CAIP (chain-agnostic equivalent) that was never submitted for lack of any implementers committed to prototyping. If you’ve got a use-case and want to play around with it, we’ll submit it! It would work like CAIP-10, but instead of the address segment it would have a transactionHash locator in its place.
A little bit confused by some articles. Is there another EIP 3370 also for addr, or its a typo?
Attention! Someone attempts to create yet another standard for representing addresses! I mean CAIP-350 ( New CAIP profile: interoperable address binary specification by 0xteddybear · Pull Request #350 · ChainAgnostic/CAIPs · GitHub ) and EIP-7930 ( Add ERC: Interoperable Addresses by 0xteddybear · Pull Request #1002 · ethereum/ERCs · GitHub ). These standards create new binary representation (but we already have CAIP-50) and, moreover, they create new text representation (but we already have CAIP-10). Please, anybody intervene! These standards should be withdrawn or, at very least, should get wider discussion before merging.
At very least I’m asking for mandating that new text representation created by CAIP-350/EIP-7930 should be subset of CAIP-10
I think this would definitely be a step in the right direction!
The way people switch networks now in Metamask is error prone and terrible UI