EIP Editing Office Hour #78 (EIP + ERC)
EIP Editing Office Hours · 4 Nov 2025 · 59:38
Meeting 78 of the EIP Editing Office Hour, held on 4 November 2025 and covering both EIPs and ERCs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process.
Topics
From EIP Editing Office Hours, hosted by ECH Institute.
Transcript
Heat. Heat. [music] >> [music] >> What's up? [music] Jesus
Christ. >> Um, and people will join. I know a
couple of authors have reached out to me. So, they would be joining in the meantime. We can go ahead and get whatever we can cover on the agenda. Sure thing. Uh so we've already taken care of most of the um >> Sam one minute please. We may have to hold this >> Akash to let us know. >> All right. Welcome to EIP editing office hour meeting number 78. This is issue number 1791 on Ethereum/PM GitHub repository. In our today's meeting, we are going to look into EIP as well as ERC pull requests. We are joined by editor Sam Wilson. Thank you, Sam, for
joining us here today. >> Happy to be here. >> Yeah, I see some of the authors have also joined. Um um so perhaps we can go ahead and get started to maybe cover uh the first final proposal if it hasn't been already done and then we'll uh get to the PR for author's uh request here. >> Sure. >> So what do we do in here?
Okay, let's start by looking at there. Okay. So, standard interface for NT. Okay. NTH is A standard interface for NFT specifically designed for AI agents where metadata represents agent capabilities requires privacy protection.
this all looks like valid solidity. Um, okay. Okay. better reference implementation, some NFTts.
Yeah, that all looks good. All right, you can go to final. All right. Um, so what do we have in the chat here? So, all right, David, let's go take a look at your proposal here. Did you have any specific questions or just wanted uh just wanted a review on it? >> Yeah, it would be great to just get a review for it. Sure.
And so everything else looks good. So contract ownership. Okay. We define a multi-step contract ownership interface. Um for more secure or more secure contract ownership management. This makes the ownership transfer uh into three distinct steps with the first two steps perform the original owner. Initiate confirm and the remaining one step performed by the new owner. Except okay. [gasps] How we enforce an optional time window between initiate and confirm
stages to give additional room for review and make ownership key compromise. Um, okay. Ownership management is crucial in onchain security and a significant portion of the security assumptions of D5. management is crucial in onchain security and a significant portion of the security assumptions of D5 protocols, smart contract wallets and onchain utilities.
super minor like grammar nitpick here, but because this is a list, um it's easy to read the second part as part of the list, but I don't think it is. Um I'm not even going to comment on that because it's really just nitpicking. But yeah, the single step friendship style ownership mechanism has been in the industry for a long time. has been used in
Jessica for multi-step timegate ownership management timegate ownership management something um process to enhance the ecosystems contract to more reviewable, stopable, thorough, and security. Okay, so um yep, that's good. Multi-step ownable. must the buffer period with initiation
then confirmation after the existing buffer period. The break train owner keys come from a
scenario. Okay. Shouldn't this be an interface? Okay. Uh
[gasps] yeah. So, Actually
this section was um written in this format to be in line with the original ownership standard and uh within the ERC 173 if I'm not mistaken it within the rational I think it had something in line with bad. >> Yeah, this is >> a fairly old standard, so it doesn't follow the rules as strictly. Yeah. So a good example here like sorry um other schemes that were considered is definitely good rational content um
because that like in like it describes why you made the choices that you made. these ones seem more like very general things about the proposal like um so why would you want a multi-step ownership standard? Um these these things all answer that except maybe some simplicity. Um, but why do you want this particular actually even why you want this particular standard is still motivation?
You you'd want to answer things like um I had a good example here somewhere. Yeah, this one here. So, I'm not saying that you need to move this to be clear. this is just a good example of what rationale should be like. Uh. >> Mhm. All right. Yeah, I got your point. I can have some nitpicking >> for this part.
>> Yep, that looks good. Um, yeah. So, fix this up and then, uh, I'll get to review it eventually. Um, and it should make it in. Um, >> thanks. >> All right, we can move to our last call proposals. Okay. So, we do have an author approval
on it. Oh, I'm a I'm an author on this one. Um, >> yeah, I noticed that and I I think that's why you had been asked for this one as well, but it was already reviewed by Victor, so perhaps we can still take it even if you are the other.
Yeah. Okay. So, See 7828.
Yeah. Okay. Good. Um, is there anything else immediately wrong? No. Okay. So, let's give this a read then. Except for refresh specific one cha addresses. I really don't like that this is a plural and then referred to with a singular. [laughter] Um but I guess that makes sense. Is the binary form to describe an address specific to one chain with a companion
interoperable name specification for human readable display for version length prefix binary envelope that support length battery data the interpretation. Oh, interesting. I didn't realize we
supported definition lists. Huh. Sam a question.
>> Yeah. >> So um for this PR like could we merge that as last call just now or we should wait for the author to come back with the changes because it does not look like very big of changes. Definitely something that needs to be done before the funnel. >> Um, well, they're going from draft into last call, so we probably have to merge you anyways. So, >> yeah. So, that's a very fair point. Perhaps we can change the status right over here as well.
>> Yeah, that's I'll probably do that. Um, >> and then the author will get plenty of time to make further iteration on this one. Okay. BNF. Okay. Yeah, everything else seems fine. So,
and then because I'm an author on this, I don't Oh, I can't edit it. Well, then >> then we must add it as a comment. Yeah. >> Yeah. Okay. So that will stay like that. All right. One, two, two, four. What's going on with this one?
Unadressed comments. That's Going to take a look at That So, the 18th
We should have some background music for these. >> Yeah, I know. I know. Sorry. Um >> Oh, no. You're doing great. [laughter] It's a It's a little easier when there's authors here to talk, but when it's just uh me reading proposals, it's >> Yeah, Is it possible? I don't remember.
I guess it isn't possible because you'd end up with Yeah. Okay. So, 1333. So what are we looking at here?
>> The last last call proposal on agenda today. cool. So this standardiz method for onchain treasury management of institutional assets ensuring secure private key generation hierarchical management. Yep. Yeah, I mean that seems good to me.
>> All right, so we have one proposal moved to last call today. 7893 37 review. Oh my god, there's a lot of stuff in here. Okay, a lot of them are images. That's That's good. [snorts] all right.
Okay. Core interfaces. I mean it's good to see D5 related
proposals also coming in D5 protocol. >> Yeah. Yeah. It's nice. >> So what would be the best category for this? I'm just trying to understand here. It's like interface for D5 protocol to implement verifiable solveny proofs and monitor financial health status. Should we still categorize it as ERC? >> Yeah, I think so. Um, there's like ERC is kind of like a really broad category. Interface. Interface I think has been used historically for RPC methods and for like solidity level standards. Um, this one's definitely an application level
standard. So, I think it still makes sense. It's an ERC. >> Yeah. Yeah. I mean otherwise it will always create a confusion because when the EIP ERC repo split happens happened then [clears throat] some of the proposals were like in that >> to go start it. Yep. Let's keep it simpler. The uh use of tables and emoji
definitely makes me think this is a uh chat GPT proposal. [clears throat] I mean many time people take help of chart GPT to maybe avoid any kind of typo kind of do a better formatting and things like that and then while doing so these things appears as well. >> Yeah like I don't mind like using chat GPT to help it's it's when they just generate pages and pages of content that doesn't really add anything to the proposal that it gets kind of annoying. Yeah, absolutely.
for a D5 proposal usage of AI. All right.
>> Sam, we are joined by David again. Maybe want to revisit. >> Oh, sure. >> 1212. Yeah, I have addressed all the comments I mentioned. All right, let me just reread these. Yep. So, how does this work? Let me go back
down here. first you initiate to a new owner. so that I'm not going to like hold up
the proposal on that. I'm just throwing it out as a suggestion. Um, that's good. Yeah. And this is just moving your rationale. Awesome. Yep. Those become interfaces. No. Interesting. So, the idea would be
if the um owner's key is leaked, then they could like frontr run the attacker trying to change it. Um doesn't that also work in the opposite direction? Doesn't that mean the attacker could frontr run any ownership changes to um like a Yeah, I guess it would just turn it into like a fight for for gas fees. >> Um actually um it it requires this only happens if the attacker acquires the owner key. So if the attacker doesn't have the owner key then um they would be not be able to >> Yeah. pass it. Yeah,
it it would have been more of like a gas because there is that time buffer and within that time frame the other side will have to flip it and then like the ownership wouldn't be able to be transferred. >> Yeah. So the >> the compromised key would remain the owner basically is the best case scenario there. Yep, that's right. >> Okay. >> Because in the existing case, the compromised key can just uh switch the ownership.
>> Exactly. Yeah. Yeah. >> Cool. >> Thanks. >> Awesome. So, that should merge hopefully. Um yeah, thanks for coming out and uh I think that's about all the time we have for today. So talk to you all uh next time I'm on >> right and for the next time next week actually we are going to have EIP editing office hour for EIPs only but we will meet Sam uh during the event that we are organizing that is EIP summit on 21st of November. So please check the agenda you'll find the link if you are around you can come and meet us in person in the event but Sam will be there in order to answer any question kind of AMA and we'll be going through
some of the um author's questions during that call. So yeah thank you Sam for joining and everyone here for tuning in. >> Take care. >> What's up?
>> Thank you. Oh, heat, [music] heat. [music] Heat.
Heat. [music] >> Heat.