Connecting Bitcoin, Solana, and EVM: The ERC-7930 and 7828 Standards

Transcript

I think that ultimately these specifications have the potential to move user experience forward in an incredibly positive direction. We do need to make it accessible to the people that are not existing within our echo chambers. If you wanted to represent a an address on Solana or an address on a Cosmos chain or Bitcoin, for example, you can do that [music] using this standard. It's a single binary payload that [music] represents everything that you need to know exactly where the intended destination [music] is. So, having everybody working collaboratively on one or two singular standards is much better than

>> [music] >> 10 competing standards user experience and I think that these two specifications do that. >> Picture this, you want to send funds from one wallet to another wallet. You have collected the address where you want to receive the fund and you have pasted it from where you are sending the funds. You click on the send button and then you >> [music] >> start thinking, "Did I use the right chain?" Well, if this happened to you before [music] I'm sure you're going to love this episode. Today, we are going to talk about two proposals that are working together to make this question [music]

disappear forever. ERC-7930 and ERC-7828 are interoperable addresses and interoperable names and they make blockchain transactions even more user-friendly. Welcome back to Peep and Eap. This is episode 160. I'm your host Pooja Ranjan and this episode is brought to you by EChO Institute. Today, I'm joined by someone who lives at the [music] intersection of blockchain and domain names. He's a software engineer from Manchester, [music] a six-star marathon finisher, a long-time contributor to ENS ecosystem, co-founder at Unruggable, and co-authors on both of these proposals we are going to talk today.

Please welcome Thomas Claus. Thomas, lovely to have you with us. >> Thank you. Thank you for having me. >> Well, Thomas, before we open up the >> [music] >> spec sheet, I have to ask this one important question first. Are you currently in a marathon running mode, recovery mode, or in between races mode? >> I am currently having a bit of time off the marathon running, and yeah, over the past couple of years, it's very much been fully in running mode. So, I'm kind of taking some time off, stepping back. But, I mean, I'm still running. It's It's British summer now. Yeah, so still getting my endorphin high, and taking any opportunity to get outdoors.

>> Well, by marathon mode, I didn't mean that you are physically running. I'm asking because you are writing back-to-back EAPs. So, even if you are on break from marathon, you are in a marathon for something different. >> [laughter] >> Yeah, absolutely. I mean, this is my first foray into writing and working on EIPs, and I didn't necessarily know what I was getting into in advance of kind of working on them. A lot of kind of contributors have contributed to these two specifications over many, many years, and there's obviously an element with spec writing whereby different people are coming from a sort of different backgrounds with different motivations and different incentives. My

sort of interest in these specifications was obviously we have the ENS specific context. I'm a co-founder of Unruggable, and we're currently funded by the ENS DAO, and there was kind of lots of conversations and back and forth about ENS and how that would potentially play a part in these specifications, and there were a few sort of misunderstandings on the sort of technical specifications of ENS. So, that's kind of how we first got involved was trying to answer some questions there and then just finding the whole process to be fascinating and wanting to contribute in a way that could make these particular specifications

accessible to technical and non-technical users alike. >> Well, you describe yourself to be someone who knows a lot about domains, base domain name, and names in blockchain. That's a beautiful niche. Take us back into the space like how you entered it and where did the love of human readable naming system actually started for you? >> Yeah, so it's it's been a a long It's been my whole life, really. When I was a youngster, I I got into software. I built an online game and when I was I think I was 12 at the time when I first started building it and then gradually that grew. I needed to give it

a name. I discovered domain names. I purchased a domain name and then in the process of going down that rabbit hole, I came to realize that there was a market for buying and selling domain names. I then spent a lot of time researching that and that I guess that was my kind of core hobby when I was a youngster during my school years. I bought and sold domain names as an investment, a way of making some money on the side. Then through those channels, I knew a lot of people in the industry. So, then once I'd finished my degree university, which was in economics, I was fortunate enough to have a number of contacts in the domain name industry. So, I I moved

abroad to the Cayman Islands and worked for a company that at the time was called Domain Name Sales, which later became Uniregistry. So, that was an aftermarket platform, but then it became a registry and a registrar, and ultimately that got sold to GoDaddy, which is a very large domain name registrar that I think a lot of your viewers will potentially be aware of. So, it was really kind of it started off as a a childhood passion and interest turned into a money-making mechanism, and then ultimately became my career.

And then yeah, post this the sale of UniRegistry and kind of but still generally being tuned into the industry, I discovered Ethereum and blockchain, and then stumbled into ENS, which was I guess the natural progression of digital identity systems. Domain names in the traditional internet, I guess, are ways for representing websites on the internet, whereas I was fascinated by the potential for ENS as digital identity for individuals. As I kind of think and ponder the question, like it's interesting how many different kinds of identity systems align. Like can recall

one individual who's a good friend of mine who, as well as working in the domain name industry, also runs a car a vanity car license plate business. So, he he buys and sells number plates for cars, and yeah, I always found that that fascinating that yeah, there's there's not that many of us, but they're when when you find the people that are fascinated by identity, they really do tend to go all in. So, yeah, anything related to identity, I always enjoy exploring.

>> Very interesting, like buying and selling domain name at the age of 12, friends with people who are like working on vanity car license plates, and they're like having experience of web3 domain naming system is quite a lot and I have noticed that you have shipped a lot of things inside ENS as well. Label hash ENSIP-24 ENS V2 contribution and definitely the work with Unruggable. When you look back, which is the project that taught you the most about how naming system should work?

>> That's an interesting one and a difficult question. You never said that the question is going to be easy. I think that that a question that is still yet to be answered. Over the time that I've been involved in ENS and working on ENS there's been kind of a lot of iteration of the smart contracts and ENS Labs who are the the core protocol team are currently working on ENS V2. For example, I keep up to date with kind of all of the the changes that are going on and all of their sort of architectural decisions that are being made and yeah, think it's an interesting question because blockchain specifically whereby you're working with immutable smart contracts,

it's no longer so easy to change things if you don't get it right first time and migrations and iterations on software architectures within the blockchain industry are a lot more complicated and a lot more nuanced than than in the traditional software world based on my experiences at least. In the past this kind of ENS has introduced the name wrapper and previously there was considerations about having a separate L2 for name chain and then ultimately ENS Labs decided that that wasn't the most appropriate path forward. So I think in the context of digital identity on blockchains it's still an unanswered

question and something that kind of lots of intelligent people are spending lots of hours trying to discern those answers, but I do think that as Ethereum moves forward and we adjust and adapt to the real world use cases, we are kind of iteratively moving in the right direction. And I think that having ENSV2 on L1 is the correct decision ultimately because it is [clears throat] the entry point that most people have to working with EVM compatible blockchains at the bare minimum, but also in my opinion being somewhat of an Ethereum maxi, Ethereum is the original kind of programmable blockchain and so yeah, I am strongly in favor of continuing to

support it at the L1 level. >> And I think we have received fantastic result in this direction as well, like you know, we are doing great. Now people are taking it. Now Ethereum is getting a lot of interest from enterprise and we will talk about some of the use cases later in this conversation. But just to set stage for people who are listening, we live in a world with hundreds of chain and they all share kind of same address format as Ethereum mainnet and this address itself does not say which chain it belongs to. So from a user standpoint, what is the actual everyday cost of the ambiguity which is there because of multiple chains?

>> Yeah, I mean talking specifically about EVM compatible chains, obviously there are an abundance of different blockchains that all use the same addressing standard as Ethereum mainnet. And yeah, as mentioned previously kind of Ethereum is a programmable blockchain. You have smart contracts. Not every address represents an externally owned account. And similarly, you now have smart contract accounts whereby various specifications now allow you to sort of delegate control of your spending to smart contract bots in manners that mean that you don't necessarily actually have direct control of that address. So,

ultimately, if you send funds to the wrong place, you can lose your funds. And having access to a contract address on one chain doesn't necessarily mean that you do on another chain, etc. etc. So, yeah, at a high level, it's as the number of blockchains proliferate, we want to make sure that people are interacting with the destination, be that an EOA or or smart contract that they actually expect, so that they they get the results that they expect.

>> Very well said. And I think it is the right time we get into the proposal and see how both of the proposals working together going to help users. So, let's peep in. >> Absolutely. So, I have prepared a couple of slides just to briefly run through these specifications. So, yeah, so this presentation and the the specifications in question here are ERC-7930 and ERC-7828. So, ERC-7930 is named interoperable addresses, and it defines a binary address format for what we define as a chain-specific address.

So, this is an address that represents both the chain and the address on that chain. So, in the previous sort of back-and-forth dialogue, I mentioned how you can have the same address on multiple chains, an address on Ethereum mainnet can also, in principle, be utilized on base, Arbitrum, Optimism, any EVM-compatible chain. So, what was kind of needed was a way of representing a specific address on a specific chain. Originally, when I first got involved in working on these specifications, there were various different specifications and lots of kind of

interplay and a lot was sort of crammed into one specification. So, we worked extensively with kind of a number of parties on iterating on these specs, including Josh and the Ethereum Foundation. So, that's Josh Rudolph from the Ethereum Foundation and the team at Wonderland. They kind of gave extensive support and contributed massively to these specifications. And the main sort of conversation was how do we build specifications that are clearly defined in what they do and also maintain the appropriate separation of concerns such that different user groups can read the specifications that they need to read,

be able to consume them, understand them, and be able to work with them without kind of too much complexity. So, ultimately, we separated out these two specifications into ERC 7930, which is interoperable addresses, and ERC 7828, which is interoperable names. 7930 is There's an example in this slide. It's a long binary payload, but whilst it's kind of not immediately obvious to the human eye what that actually represents, to a computer or a smart contract, it is sort of standardized, very clear, very easy to break apart into its constituent

components, and it's easy to work with. So, with moving forward with intents and things like that, this is a fantastic and simple way of representing a large amount of data in a small amount of space. So, this string stand-alone looks quite complicated, but actually it's made up of these six components that are outlined in the body of the 7940 specification. So, there's a version, a chain type, a chain reference, and the address. In advance of the chain reference and the address is a representation of the length such that

any parser knows how many characters they need to parse from what follows to pull out the respective address. This standard is designed for representing addresses on any chain. So, whereas there were previous standards, the Kasa, the chain agnostic standards agency, had produced, I believe it's Cape 10, which was a a representation that was a string only representation, if I recall correctly, and that, whilst kind of functional and useful, is not open-ended and it's not necessarily an efficient way for storing

data on chain, for example. Whereas by having a binary standard, yeah, you can represent a lot of data efficiently within the constraints of the technical paradigms that exist at the moment. So, this string represented on this slide is actually my address, and this representation is for my address on base. Uh this chain reference 8543, that is the ID for base, and it's encoded it in hexadecimal as 2105, for example. So, go on to the next slide. The motivations behind 7940, whilst this list is quite small, there is three elements. I have

intentionally made this slide quite small to because whilst yeah, there's only three items, they are all kind of incredibly significant items. 7930 allows you to have an address representation that binds together both the chain identification and the raw address. So that is the crux motivation for this. It's a single binary payload that represents everything that you need to know exactly where the intended destination is. As previously mentioned, compact, which an incredibly efficient way of storing binary data on chain. If for example, you wanted to store a

string, that would be significantly more costly from a gas point of view. Whereas the using bytes primitives on chain in Solidity allows for yeah, cost-effective and efficient storage that only costs what you actually need to store. And then yeah, that third point is that this extends beyond EVM blockchains. So for example, if you wanted to represent a an address on Solana or an address on a Cosmos chain or a Bitcoin, for example, you can do that using this standard. So well, before I go on to 7828,

it's worth also mentioning the supplementary standard, which is KEIP 350. So again, this is produced by the Chain Agnostic Standards Agency and the team at Wonderland have contributed massively and and maintain those standards. Though the the reason for the separation there is KEIP 350 is a living standard. So historically, ERCs and EIPs are not living. They're immutable once finalized. There is an exception for ERC-1 or EIP-1, which outlines the the standard process, but generally,

these standards are immutable once finalized. So, the premise was that we didn't want to preemptively invest lots of time into standardizing exactly how different chain address standards are converted to and from. And additionally, we don't know how the ecosystem in the space is going to develop over time. So, at the moment, there are CAIP-350 profiles for, as I mentioned, Solana chains, Cosmos chains, Bitcoin, but in the future, over the next years, there

may be other blockchains, other technology stacks, which have their own addressing formats. And as long as they have a CAIP-350 profile, they will also be usable within the ERC-17930 specification. So then, the question that kind of always comes up is that long string of hexadecimal characters that represents underlying binary data is not very easy to read and understand. So, that's where ERC-7828 comes in. So, as the sort of headline for 7828, I've defined it as maximally readable chain-specific addresses for

user-facing interactions. So, whereas ERC-17930 is a binary standard that's very useful for smart contracts and low-level underlying software interactions, the majority of real-world users are utilizing blockchains through user interfaces and need an easily understandable representation of a chain-specific address. So, this example here klaust.eth@base that is, in my opinion, the sort of ultimate end game for a maximally readable address. Klaust.eth is my ENS name, so that's the Ethereum Name

Service, which is a very well-established digital identity primitive for the Ethereum blockchain, but its functionality extends to representing data on all sorts of different blockchains, and that klaust.eth can be resolved to an underlying address on any specified chain. In this case, the 7828 representation uses the the chain label identifier base, which is obviously representative of Coinbase's Base chain. So, by having this singular string, I can represent my address on Base. For backwards compatibility, the

specification for 7828 does allow for flexibility, so you can, like this second example underneath, still use a raw address and still represent an address using previous standards. But, this 0xAC etc. etc. @ EIP-155:1, in my opinion, is less visually clear to the user than the former example, klaust.eth@base. So, motivations. Again, it's a a human-readable representation of a chain-specific address. So, ultimately, the motivation for this specification and the motivation for

separating it out into its own specification is to provide a definition of a chain-specific address that is really easy for your normal user, day-to-day user, to understand. If you see clouds.eth base, it's, in my opinion, fairly clear that you are transacting with the underlying address for clouds.eth on base. Similarly, base as a as a label string is less opaque than a chain identifier like EIP-155:8453.

Obviously, people that involved in standards, Ethereum standards specifically, and in the blockchain world probably know what both of these representations mean, but if you went out onto the street and said to someone, "What do you think of blockchain EIP-155:8453?" they would likely have no idea what you're talking about. Base, on the other hand, is a lot more semantically clear, in my opinion. And then, yeah, the next point that I mentioned is it's decentralized and it scales.

So, what that's referring to is the chain registry resolver that is actually specified within the 7828 specification. So, this exists as a resolver contract that is set on the on.eth ENS name, and what it allows for is it allows for the conversion of a string representation of a blockchain to be converted to that ERC-7930 binary representation that we previously discussed. So, from the string base or optimism or Arbitrum, you can call this

resolver and return back the interoperable address that represents that blockchain. Additionally, the on-chain registry resolver also acts as a single source of truth for blockchain metadata. So, the ultimate end game is to have the operators of these chains take control of the entry within this registry, and they would then be able to set any metadata associated with that chain within the resolver, and it would be able to be returned to the user subject to the standard ENS resolution processes that are outlined within the ENS IP

specifications of the ENS documentation. Additionally, the registry resolver allows for a 7930 representation of a chain to be converted back to a label. So, it works in both directions if someone is doing some low-level on-chain interactions using a 7930 identifier and then wants to produce a user interface that displays the label, they can convert that complex binary identifier back to an easy-to-understand label representation like optimism. So, yeah, as previously mentioned, the

on-chain registry resolver utilizes all of the ENS IPs to allow for the resolution of data related to a specific blockchain, and that data is also viewable or visible or discoverable through a website that has been set as the the content hash for the on.eth namespace. So, there does exist a fantastic service called eth.limo that allows for you to view websites that have been set as the content hash for a specific ENS name. If you visit on.eth.limo in your web browser, you can view a front-end for the on-chain registry,

whereby you can interface with the registry, view metadata associated with chains that are stored in that registry. And as kind of visualized in this screenshot, for example, if you were to type in optimism, you would get this interoperable address back, which is the representation of optimism using the the 7930 standard. Now, whilst of course out of order in the process of having spoken about this, I realized one glaring omission with that I I didn't kind of outline in relation to the 7930 standard. When we were conversing about

how to build a standard that's flexible and meets as many needs as possible, it did become apparent that we could build a standard that is incredibly flexible such that you can use it to represent a specific address on a specific chain, but it doesn't require you to define an address. So, if you hypothetically wanted to represent an address within a namespace, for example, you don't need to include the chain reference components of the 7930 identifier and similarly the address, you don't need to

include an address. And if you don't want to include an address, you simply specify the address length components of the 7930 identifier as being zero. That was kind of a a quick, albeit not that quick, overview of these two specifications. And yeah, I'll pass it back to Pooja who I'm sure will have additional questions about all of the things that I imagine I have missed. >> I mean, you have already covered a lot of things. Here we see two companion standards designed to be read together.

7930, that is the machine layer, and 7828, that is the human layer. And together they are answering one of the most pressing UX issue. You already shared some examples. We're going to talk a little bit more about it, but all in all, this information is super helpful. Thank you for building such things. Thank you for documenting these standards. >> Absolutely. >> Well, quickly going back to touch on a few points from a developer standpoint, how have wallets and protocols been handling this so far before ERC-7930 and 7828?

>> Yeah, so specifically in relation to 7930 and 7828, whilst we've been iterating on these specifications, we've been very proactively involved in the various interoperability calls and conversations that Josh Rudolph and the team at the Ethereum Foundation have been putting on to sort of connect the various stakeholders in these conversations. And a lot of the participants on those calls are technical members of teams associated with wallets, chains, et cetera, et cetera. So, I think it would be fair to say that at this point a lot of the the chains and the wallets are aware of

these specifications and standards. I think as with many things in blockchain and especially when in the case of some of the wallets you're working with private companies, you have to kind of make it very clear what the value proposition of the specifications are. They have limited engineer resourcing and time and they want to focus their time on implementing the standards that are going to the most value for their customers ultimately. But, we have had positive feedback. There are ongoing conversations with lots of the big wallets that users know and love and I think that ultimately there is general

consensus and acceptance that these standards are good and do achieve what they set out to achieve. And now it's just a case of discerning the best path forward and the best mechanisms for supporting teams to implement these standards. So, the team at Wonderland for example have worked to produce an SDK to make these standards incredibly accessible and very easy to implement. Similarly, there's a website that was also built by the team at Wonderland at interopaddress.com that gives sort of hands-on user interface demonstrations of how these specifications work and then

simultaneously there's been outreach to the technical teams at major wallets to support them in implementations. I think that the main outstanding question is surrounding the kind of initialization of data within the on-chain registry and a lot of time and effort has gone into working out the the efficient and pragmatic ways of doing that, and more information about that will be coming in the near future. But, I think that we kind of appropriately laid the groundwork and appropriately sort of opened the doors with the teams in the appropriate places to move this forward over over the coming months. So, I'm very hopeful that we will see chains

implementing these standards and wallets implementing these standards over the coming months. >> Indeed, and I really appreciate all the work that has been put in in order to bring it to a place from where it can be taken forward by different UA providers and maybe having a standard body to organize all of these things. Let's start with ERC-7930. As we understand that 7828 built on top of it. So, getting there, you mentioned about CAIP-350. I'm looking at the standard CAIP-350. It is currently in the draft status and it is obviously not finalized, not living.

I want to understand what role does it play for ERC-7930? Can we consider this as a mandatory proposal? >> So, 7930 depends on CAIP-350 in the sense that yeah, there is heavily defined interplay between the two. CAIP-350 is explicitly mentioned within the 7930 standard. And really, yeah, it's set up this way for separation of concerns such that the core 7930 specification is not too bloated, but it also allows for

flexibility. So, at the moment, there are there are CAIP-350 profiles for Bitcoin, Cosmos chains, Solana chains, and EVM chains, I believe. But in principle, if any other software package blockchain software architecture wants to establish Cape 350 profile defining its addressing standards and how you convert to and from that standard, then it would be welcomed. This separation allows for flexibility such that, yeah, we can iterate and move quickly and be future-proof, essentially.

>> How important is the mention of CAIP in ERC 7930? Because I am looking at the CAIP 350, it seems like it's other way around. Like CAIP needs 7930, not 7930 needs CAIP. >> Yeah. I mean, I guess that works in both directions. 7930 depends on Cape 350 and Cape 350 depends on 7930. High-level, Cape 350 is essentially the living elements of a a universal binary addressing standard, whereas 7930 defines the sort of core pieces that are immutable and never change.

>> Very well. Uh from Ethereum's standards point of view, I have a piece of information. I think it has already been followed in ERC 7930. But since CAIP 350 is a still in draft status, it is highly possible that the standard may change over a period of time. As you mentioned, the idea of keeping this proposal as a living status is there in the community, so definitely it is going to have at least one status change, which is going from draft to living. So in order to move ERC 7930 towards final, it is important for us to keep it with the

commit history of the latest commit for CAIP-350. So, this is some technical point that as an author you should keep it in mind. Otherwise, this proposal will be outdated because we do not allow to link to the CAIP-350.md file. We would allow only particular commit history. >> Okay. That is interesting additional insight. I know that yeah, team Wonderland working to push these specifications through the process to finalize the the specifications. So, I will feed that back and make sure that that

is appropriately considered. >> Very well. I'm sure like the proposal ERC-7930 still is in draft, so we are going to have two more status change, last call and final. So, that will give us enough time in order to push CAIP-350 as well. Like if they are helping each other, let's move both of the proposal towards final or if they want to go it in living, very well. That is also good. >> Absolutely. Yeah. >> Very well. Let's talk a little bit more about use cases with the ecosystem and builders. So, first talk about who builds it. So, if a smart contract developer is listening this conversation right now thinking I want my contract to start storing addresses in the human readable format, what does adoption look

like for them? Like what do they need to do in order to get this incorporated in their project? >> So, from a smart contracts point of view, if you want to represent a specific chain or a specific name space or a specific address on a specific chain within your smart contract, you can do so using this standard out of the box using your standard Solidity primitives, namely that bytes type, which is an efficient mechanism for storing dynamically sized arrays of raw binary data. So, a 7930 interoperable address is ultimately

binary data, which you can store within your smart contract depending on your use case. And under the hood, that is what the the on.eth registry resolver does. It essentially has a mapping that is a mapping from a label, a string representation of a chain, to that binary payload. Yeah, so assuming a smart contract developer is is working with solidity, they can use this now. And in many respects, this is why it was designed this way. >> Ready well. And you already have mentioned that most of the wallet teams are informed of it. Some of the chains, blockchains are also informed of it. So, if some chain who may have missed it by any chance, what is the cleanest way to

start supporting both standards? Is there a working group? Is there a monthly call ongoing where they can participate? How would it work for them? >> Yeah, still exists on a non-uniform cadence, the various interoperability working groups. There were previously regular calls on interoperability. And I am sure that they will continue as appropriate. So, that's probably the most accessible entry point, and I can provide links that can be shared within the notes of this conversation. There are additionally Telegram chats. And of course, if people want to reach out to myself or the team at Wonderland

directly, I'm more than happy to for them to do so. And I'm also more than happy to kind of provide technical insight or answer any questions. >> Another question, because this is mostly related as an Ethereum standard. Do you foresee any protocol level change in order to get this smoothly incorporated or make it smoother interoperable? >> Yeah, so this is one where perhaps, given your background and experience, you would have more clarity and color on this. Obviously, the specifications are defined as ERCs as opposed to EIPs, but then when they kind of put their shared and documented on the

ethereum.org EIP section, these are not specifically sort of protocol level specifications. They don't require any underlying change to protocol clients, for example. They're specifications for how you can sort of interface with the protocol in a way that is clear and concise for chain interoperability. So, to answer the question, no protocol changes are necessary. This is purely a specification for a standard for how you can represent primitives that already exist in a in a universally friendly and accessible way.

>> I mean, without any protocol changes, I think this is a meaningful achievement by these two standards. Eventually, if we see some kind of protocol change, I believe that would be a good thing to have because this is going to have a larger impact. So, if a slighter protocol change can help increase adoption, that would be a nice thing to have. >> Yeah, I mean, there's definitely nothing that sort of needs facilitating in the in the near future in that respect, but the the question kind of highlights an important point that historically there has been kind of a lot of fragmentation, a lot of different standards around addressing, and different wallets have come up with their own ways of

representing things and then the appropriate user interfaces to match. By having this kind of standard, it allows singular standardized definition such that we can hopefully get kind of a bit of consistency and agreement on the best ways of doing this. I think as with all things, there is no value in duplication of effort. We don't want to kind of waste engineering resources and we have a lot of kind of talented engineers within the wider Ethereum ecosystem. So, having everybody working collaboratively on one or two singular standards is much better than 10 competing standards.

>> Indeed, it is. All right. Just talking in a similar direction about the governance. I know there is no like protocol level effort getting into the system right now in order to push this proposal forward. But, how does the governance lens look like for you? How do you think about shipping standards like this with help of CAIP and ENSIP work in this ecosystem right now? I want to have a take on your perspective. >> Yeah, I think if I'm being completely honest, yeah, as I mentioned at the start, this is my first foray into the ERC and EIP process and kind of Ethereum governance. And it required kind of significantly more kind of time

investment and I guess mental energy investment than I had originally expected. And at the time, it wasn't necessarily always enjoyable, but it worked. Um There was kind of a lot of people that were sort of very actively involved in the conversation and there were a lot of discussions and debates about specific elements, kind of what gets separated into what specifications, how how we sort of maximize the flexibility and satisfy as many potential kind of consumers of these specifications as possible and we didn't always agree, but at least in the context of these specifications everyone involved was kind of on incredibly

knowledgeable to incredibly passionate, but also very pre professional. So, even when there were disagreements we were able to kind of debate them and I think it was through that debate and discussion that we ultimately came to produce much better resulting specs. So, whilst it it did take a long time, uh I think it was worth it. I mean, I'm not sure exactly how one would achieve it, but yeah, if we could somehow optimize the time it takes, then it would be a very good process as far as I'm concerned.

>> Indeed, you guys have done an outstanding work right over here coming up with something like this. This is going to change the way it blockchain transaction works right now. So, if it takes a little bit extra time getting into final status, I think it is going to be worth it. >> Yeah, absolutely. And even rereading 7930 in advance of this conversation, for example, it's not actually that long a specification anymore and in the time when I first got involved, it's vastly different. I would be intrigued to kind of do a diff on the specification in its current form versus when we first kind of got involved in the process, but

yeah, it's vastly different and simplified for the for the best in my opinion. >> Good to hear that. We want to make the experience of documentation of proposal as smooth as possible. So, thank you for sharing your feedback. >> Mhm. >> I have one last big question before we get into the rapid fire round. So, if both of these EIPs/ERCs succeed beyond the wildest expectation, 3 years from now, what does everyday Ethereum experience feel like for a regular user?

>> I think 3 years is a long time in blockchain. So, and I guess there's always an element of we don't know what we don't know. And when I think back to the the 3 years that have preceded this in areas of sort of blockchain development, yeah, things have vastly different to how they were 3 years ago in ways that I think many people didn't anticipate. I think that ultimately these specifications have the potential to move user experience forward in an incredibly positive direction if we can get broad consensus and broad integrations across the ecosystem within wallets and can

open constructive dialogues with chain operators, wallet operators, dapp developers, etc., etc. to continue to develop these kind of standards, then I think that ultimately we will be in a a much better place as a result. I always think to myself and many of the people that I work with on a day-to-day basis, we we work in an echo chamber where we assume that everybody on the planet kind of has the same level of kind of technical understanding or knowledge of of blockchains and how they work, but in practice your your normal user, your normal member of the public that doesn't

necessarily work in software doesn't have a clue what we're talking about. And if we really want to grow blockchain and have it be a fundamental underlying piece of infrastructure for our technological future, we do need to make it accessible to the people that are not existing within our echo chambers. And one way of that is simplified user experience. And I think that these two specifications do that.

>> Rightly said, simplification of the process and accessibility of tools that helps users use the technology in the best possible way is the best way to go towards adoption. Very well, this is a meaningful achievement and thank you so much for you and the entire team behind these two proposals for stewardship and dedication. We look forward to see this proposal get into most likely in the final status if not living soon. >> Perfect. Thank you. >> Well, Thomas, we are switching gears and now we are getting into rapid fire round.

So, it's one word or one sentence [music] per answer, first instinct, and no overthinking. Are you ready? >> Yeah, I'm not very good at not overthinking. >> Okay, let's give it a try. >> [laughter] [snorts] >> Interoperable name format in one word. >> Universal. >> The single feature ERC-7930 you wish you had named differently if you have anything in mind. I mean, if it is perfect, it's all right. >> Yeah, there's there's nothing. I think nothing is perfect, but I'm very happy with ERC-7930.

>> First wallet you would love to see adopt ERC-7828 by name. >> I think I would love to see any wallet that wants improved user experience. >> Governance in one word. >> Interesting. >> One ENS use case that is widely underrated right now. >> I think schema definition for ENS text records. Yeah, ENS instantly becomes more usable if schema is a standardized in the same way that Ethereum comes usable if addressing is becomes standardized.

>> If on.eth grows to a thousand chain, the very next ENS namespace someone should claim is >> There There's not a quick answer to this. >> I know. That's why it's a trick question. >> [gasps] >> I think on.eth is and should stay the canonical namespace. So, I think especially for this use case, there shouldn't be another namespace for it. >> Right. Yeah, I mean, of course, it is one of the most meaningful name right over here. >> Yeah, and I think ENS is a DAO. The on.eth name was given to this initiative by the ENS DAO through a vote. So, ultimately, any good proposal can go through a similar

process. >> Favorite marathon medal so far? >> I think the New York Marathon. I did it in Well, I've done it in 2017 and 2023. Uh it didn't go well in 2017, so I got my revenge in 2023. >> Best place you have ever written code from? >> It's not somewhere that I've written code, but many years ago, I attended a meeting from a queue for a roller coaster. >> Interesting. All right. Domain names are running. Which one would you keep if you have to give up the other for a year?

>> I would keep running. I think I will always prioritize my mental and physical health over domain names. >> Yes, health is wealth. >> Yep. >> And the fun one. So, if your ENS name would resolve to one interesting thing of your choice for 24 hours, what that would be? >> Yeah, I think the way my mind works, my first reaction was, "That's not how ENS resolution works." But I I know it's a contrived like a a fun question. The immediate things that comes to mind is the identity of Satoshi.

>> [laughter] >> Yeah, that's an interesting one. Yes, of course, being an engineer, the first thing that comes to your mind is the technical possible way of getting it done. >> Yeah, exactly. >> Yeah, I understand that. Well, Thomas, this was wonderful. And before we wrap up, where can listeners follow your work? >> Yeah. So, my Twitter handle is g u a. I mean, that in itself is a good example of digital identity. Like, I think I've been on Twitter since 2009 and people always bring that up that I have a really short Twitter handle. But, g u a is probably the best initial point of contact. And then, I can share Telegram or other communication channels. And I also have a website, thomasclaus.com,

which also has contact details. I sometimes post about technology and running. So, if you're interested in either of those things, that's probably also a good website to visit. >> Yes, I was looking into your Twitter name and I was like, how could he get three half of that? It was interesting, yep. >> Yeah, I did I I did have a look at one point. I think I signed up for Twitter in 2009 or something. And that's a a long time ago. >> Earlier adopter, got it. >> Yeah, yeah. >> Very well. This was very interesting.

Thank you so much, Thomas. And it was truly a treat to have you here. >> Perfect. Thank you very much for your time. Yeah, likewise. It was great chatting [music] with you. >> To everyone listening, if you are a wallet builder, a protocol team, or a chain operator, or just someone who cares about Ethereum being friendlier for the next billion users, this is one of those quiet revolution worth paying attention to. Check out proposal, jump into Ethereum Magician thread, and bring your feedback to spec while [music] it is still in review. As always, if you have enjoyed this episode, share it with one builder of your circle who would love it. Subscribe it if you haven't done it already and don't forget to click the bell icon. We'll see you in the next one. Thank you, everyone.