EIP Editing Office Hour #84 (EIP + ERC)

EIP Editing Office Hours · 13 Jan 2026 · 1:06:13

Meeting 84 of the EIP Editing Office Hour, held on 13 January 2026 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

Loading developers...

[music] Heat. Heat. >> [music] >> What's up?

>> Thank you. >> Heat up here. [music] >> Heat. [music]

Heat. >> Heat. >> Heat. Heat.

>> Yes. >> Welcome to EIP editing office hour meeting number 84. This is issue 1872 on Ethereum/PM GitHub repository. Um in this meeting we have PRs from uh ERC repositories mostly. We have some PRs for last call review miscellaneous and draft. We are also joined by some of the authors and they have some questions. So perhaps we can get going with the first PR which is ERC 1412.

EIP Editing Office Hour Introduction

Um I don't know if it >> 1412. >> Yeah. Uh even if it is not added can you uh just go ahead to 1412 and we can >> you mean the you mean the PR number 1412? >> That's correct. Let me share the link in the in the chat. It is >> Yeah, I just have added it. This is uh at ERC ENS trust registry for agent coordinations >> and we are joined by Quam here uh in case you have any question for him.

Discussion on ERC 1412 and ENS Trust Registry

>> Hi. And uh hi Kwan. Uh I couldn't seem to find you in the participants list. Can you unmute yourself and say hi? I I I sorry I couldn't see you. >> Hi Victor. Yeah. Iswami here. >> Oh okay. Hiwami. Nice meeting you. Okay. I can now identify you. Yeah. And apologize. I usually will have my camera on uh but today I'm like because of all some logistic issue I'm currently in a in a coffee shop. Um so and then the network is not the the ideal so I just

leave it off but good to meet you. Thanks for coming to our ERC EIP editing office hour. >> It's a pleasure. Thank you for having me. >> So yeah um do you have any question particular question? No, just a it's just a new ERC that we're working on. It's an it's kind of like an extension to the uh ERC80001 um that has recently been canonized and uh just an overall review um and to see if we can get it added or if there's any changes that need to be made in order for that process to happen.

>> Sounds good. So it's this is a ERC A107, right? >> Yes, it is. >> Okay. It's a trust registry. Um, web of trust validating user validation and discussion. where we wanted the transitive truck

relationship using VNS. um propagate to the sign chain following PGP sorry GPG one Uh yeah.

So motivation determines the minimum of primitive multi-party agent coordination but explicit defer trust to modules pricey threshold and uh there's motivations there's specifications uh trust level this is ENS 137 7 uh signature author. This is 12 uh 1271 for sure. These are all repetitive like what does this specific uh this is actually the the one

that you inter you define right? >> That's correct. who is going to store this uh information. Do you envision one implement one instance of this in uh one contract instance of this uh interface

being it or do you think it would be decentralized and be uh spread out to multiple different contract instances >> we're looking for a more trustless approach of course >> so everyone can deploy a contract and the contracts conform to this interface and then these interfaces uh become the um the one where a agent can query. So I can see the permissionless part. What about or decentralized part? What about how people >> um okay so gain a class through a web class approach where it's travers through assets right?

>> Yes that's correct. >> Okay. Uh and then ENS is being used and then you uh basically using the node. Am I looking at the >> Yeah, you you you have to have >> specification? >> Yeah, you have to have an ENS address in order for this to to work >> ENS. Can NFT be available uh be be used instead? Of course, we know that ENS issues NFT um in its in in its um not the first version but the the current version. Um but uh would you consider generalizing?

This is a question not a you you can have your preference. This is not a suggestion. I'm just asking from a from a scoping perspective. Oh to have um NFTTS as well. >> Yeah. Is ENS required? Right. Is when you make a when you make a decision to use it as as your as here have you considered generalizing it to all kind of NFTTS or different type of nodes and or do you specifically want to be opinionated that this is going to be supporting ENS and ENS only? Yeah, it's a pretty minimal um like ERC and it

it is kind of like really tied to ENS and the uh web of trust. >> I see. uh and uh when it comes to web to web of trust. Let me see if trust is a consider a boolean or it's a quantitative um value that you can assign like if I tr if if an if one of the instance uh trust another instance uh or trust another ENF names is this um is oh the trust level is a is an ENA >> yes that's correct it it maps directly

to um how um you know web of trust in GNU GP work. So it it's >> basically using their rails. >> I see that makes sense. >> Cool. Um let me see the following are optional. Semantic that trust should revert that trust batch true revert must revert trust

the trust node. Now is relationship. Can you explain to me when an ENS expired what happened? Let's say if there are tractor in in in one case >> um can you um can you say that again please? Sorry.

>> Yeah. Um if one ENS name being the trust has uh inspired its um has come to the end of it time of expiration. How would this algorithm um handle that case? If I were to say different way, ENS names have expiration time, right?

>> Yeah, that's a good point. uh do you want to be opinionated on that or do you want to say this is open for as as a standard designer you can choose to say I'm not going to enforce anything whoever implement it you can feel free this is the flexibility I'm leaving it to your design space >> or you can also say I want to be designing it to make sure you don't surprise each other when each of you design it differently. Yeah, I mean we don't like I mean in the the worst case like we're looking to um handle that particular type of situation and you know um definitely open to

suggestions. That's why you know I'm here today. >> Yeah. Yeah. I I think that would be an open question for you to handle the expiration times and expiration and let's say transfer um of things. Um and then also the second question is whether this should belongs to uh the reference implementation or the inter or the specification here because these are the algorithms right and then if you provide it saying this is like everyone have to do particularly this way then pretty much you're defining a reference an implementation.

Specification vs. Reference Implementation

>> Okay. >> Yeah. So do you do you consider this as um as part of the specification or do you consider it as a as the um as a reference and people can implement on their own? >> Well, we want it to be you know flexible like a good standard should be flexible and allow the you know the developer that's using it the the freedom to to have something that's canonized but the flexibility to >> be creative with it. So, um yeah, that might be something that I should probably just take back and um either revise or um think a little bit more on.

>> Right. Okay. So, I think it's good enough as a draft. So, I I think this is moving. Oh, you're trying to wait. Um let let me take a look actually like a brief review right I think for review you probably need to be able to do that for draft is good enough which you already did but you're creating a new file right >> this is a whole new file right okay so then then there is multiple things >> one is need to start with um draft status

that is instead of oh let me do this probably this easier so it's draft status when checking first time but I would uh consider this version good enough as a draft then um um consider the verify by path and other parts in the specification. It seems some of them need to be in reference and can do you know the difference

between specification versus reference implementation? >> Yes, I do. Yeah, just just to clarify specification is like hey everyone who consider themselves ERP 8107 conform must do what I said in the specification but reference implementation more like uh when it's flexible enough I I can do it this way and it will work but you can do it flexibly so be very u clear about uh what you put in the specification and what you put into the reference implementation is is what I what I um will suggest you to do

>> consider ENS um expiration situation. >> Yeah, if you didn't make ENS as your designated mandate in your application, then number three would not be a problem. If you do um require an ENS and only work with ENS, then you do need to consider what will happen to ENS and that I didn't even mention uh ENS on different chains like I think they're trying to expand to ENFB2 is trying to

expand to onto different chain through CCIP read or other approaches um that you might want to take a look if you haven't addressed them. I haven't been able to read in more details but uh if you if you have to consider that that would be great. If not then that's something you would be looking into. Um and also I would recommend this to yeah Nick John Johnson.

But once you change that to uh from from review to draft, I can actually approve and make sure that you can publish them so you can share these more easily. >> Thank you very much. >> Yeah. Yeah. And you can give me a ping on um on discord or black. Well, this board not so much but on on Telegram um if if once you switch this to to graphs and then I will >> and thank you for contributing to ERC standards. >> Thank you for your review.

>> Thank you Victor. Uh that was really a very good catch. people should start a proposal with the status draft because draft is the very first status to uh go ahead with. Uh next we are joined by um an author who is willing to move his proposal from review to last call and the ERC uh PR is 1423. I have shared the link here in the chat and Nabil is on the call. Um >> if you have any questions. >> Hello. Yeah, we are from on behalf of Shaler who is the editor and contributor of this PR.

Proposal Status and ERC Discussion

>> Uh Victor, I think uh your screen sharing has been stopped in case you want to restart it. >> Hi AB. Uh just see 7943 right? 7893. >> I must be on the wrong >> Yes, is the ERC 7943. Yes. >> Yeah. Sorry, my bad. >> Um, okay. Okay. Um can you make your change first and uh

keep the call move to last call in a single um in a single PR? I could review it but I usually we usually prefer change of status to be a separate um will be a separate um PR. So you can add your co co- contributor uh you can add other updates. Um so that's one thing. Um >> okay can you leave it as a comment in the PR please for the for the >> Yeah. Thank you.

>> Yeah. You keep uh updating um status into a separate Uh so that's one one of the updates and the second one is that we actually don't know if we act I don't think we have a policy for using JIT subm modules in this because we usually want to have all of them inside. So this I would defer to um refer to EIP anyways to determine whether we will accept sub modules.

Um yeah, for the past time it you need just like copy and paste into the copy into the assets and then um I personally understand why you do that and then I'm in favor but uh we need to probably get approval from the EIP editors group together. >> Perfect. Thank you. Our time >> um together [snorts] to determine whether this is a good idea. I can see a few of them say no. Um, and I also don't I also understand why you're not copying them because this like subm module is a better way to keep them in sync and also respect the copyrights and everything.

So, I actually am in favor. But yeah, I I'm I'm not there to impose my own personal preference into this. This probably needs a consensus. >> Got it. Thank you. >> Yeah. Um yeah, this I think this one is pretty stable. Now let me go see if there's any what what is the uh the adoptions uh currently. >> Um Dario left um an explanation comment in the PR at the end of the of the com.

I see you're having a lot of in uh inputs from this contributor >> so much so that you add them as a co-author I think right is that is that person >> he is the principal author of the of the RC >> oh okay he's also >> yeah on behalf of him he he couldn't join he's the main yeah he's the main author I see okay yeah >> okay you guys are very very much actively addressing all the questions Yeah.

Discussion on Delta Update and PR Review

>> Um, okay. >> So, >> wow, that's really a lot of discussion. I probably need to look more >> 100 plus. Yeah, there's a lot of uh a lot of Yeah, the delta update. Let me actually give

it a read and see what could be um what do people have question about and why. It has gone through um a couple of PR right now. >> Yeah. What a adopting that right now. Um there are many of public names for the standation of uh real world assets.

We >> I mean currently yeah what what what assets have currently adopting adopted this uh this um ERP >> um there is a list in the in the last comment from sher >> yeah let me take a look >> yeah not in the magicians in the in the p request itself in the conversation in the pull request. >> Oh in in a p request itself. >> Okay. You can check it in the conversation. Uh yeah, this one.

Okay, you are adding frozen and whether a domain. Oh, and force transfer and just check in for author. I see. Cool. Great. >> Yes. This last >> in good shape. >> Yeah, this last uh pull request was um regarding some typos and minor clarification on some returns.

>> Is that for the module that needs um consensus? So, I wouldn't use approve, but I will say that I'm personally in favor, but um we probably need to wait for that. Um >> yeah. Um, if we remove the G models, do you need a reapprove of of the P request?

>> I think I would if you remove that, I probably would be able to uh to just approve it. >> Okay, perfect. >> Yeah, >> thank you. >> We for subm module to check in. So I don't know if I can whether I can approve everything except for that single file.

So let me just leave it there. You can leave me a ping if you if you'll remove that or if you want to like ask for uh consensus on that. >> Perfect. Thank you. >> Yeah. Oh, let me make sure I don't forget uh in me uh if you u when you are ready to merge and yeah I'll I'll leave um I'll leave my uh telegram in what's the best way to give you my personal pet telegram >> maybe in the chat here

>> in the chat maybe. >> Yeah, sure. >> Um >> well I I'll tell Yeah, I'll tell Puja and then Fuja knows can you share I I I don't want it to be public record on our >> Uh and but yeah, Fuja has my my my uh my telegram. You can you can just ping me. >> Or email. Yeah. And I think the another best way is maybe you can show up on EC Discord and just tag you over there. That way it will be faster. Tag you with the PR number. >> Oh well. So I I need to be better at that methods on on this. Anyway, yeah, but good job. Thank you very much for

contribution. any more question uh for me is that how it pronounced your name right? >> The update. >> Sorry again. >> Oh, did you you called me right? >> Uh yes. I ask if you if you have any more question about this particular PR.

>> Uh no. >> Okay. Um thank you for your contribution to ERC uh standards. Um congratulations and look forward to merge it into last call. >> Thank you Victor. >> All right. Uh so the next PR we have the number is 1 22 3 and the author is trying to move the proposal from draft to review. Okay, let me see. Can you see my new screen? Did I?

>> Yes. Yes, we can see it, Victor. It's all good. Yeah. So, this proposal has already been reviewed by Sam earlier. I guess the author has made some changes from the last review and looking for it to be moved to review status. Okay. I think Sam requested the only blocker being no more external links. Um and then you just remove it out.

Uh let me just double check that. I think um he have give you given you verbal approval and then I'll get back on that checking.

And by the way, um, who who speak who was speaking? The author Sean is here. Uh no we don't have the author on call here. Uh it is just moved over from the previous meeting. >> I see. Okay. >> Let me double check what they they have done what uh they promised to do. >> All right. Uh I think they removed all the reference link. Um

let me update this. Yeah. Okay.

So congratulations to the authors. I think we can do all. All right. So next we have got a PR which is um to update the EIP template. Um this is u 10965. I have shared the link in the chat for quick reference. no I think it is on EIP GitHub repository. Yes. So I guess it requires multiple editors approval. Sam has already reviewed it in the previous meeting and he has approved it. So I have added it for your review.

Review of EIP Template and New Draft Proposals

This is also approved. Let's move to the next PR. >> All right. Um, Victor in chatwam is mentioning that he has made the updates that you have requested earlier in this meeting. Um, yeah, if we would want to go back and take a look at DPR 1412. >> Yeah, Victor. Yeah, we made the change in the in this one too in the 7943.

approved. >> We are. >> Congratulations. Uh next we can go with the PR number 1396. Uh this is to add a new draft and yeah I guess uh the author has uh made some changes post the ERC number allocation and is waiting for the first review.

Is author here? No author has just left a comment in the agenda but uh unfortunately he could not join the Yeah, this seems to be a quite long

draft. I might need more time. >> Is there uh other PRs that we can process first? >> Yes. Uh yes, definitely. It seems like a longer one. Maybe better to take it offline. Uh I have shared the next PR1463. This is also for um uh a new proposal. It's for minimal agent registry. >> One second. Uh let me document this. referring um this PR to pay to offline.

Discussion on PRs 1455 and 1463 by the same author

>> Yeah. Okay. >> Sorry. Uh what's the next one? This uh 14 PR1463, right? >> That's correct. Yes. >> Yeah. I >> As agent registry, >> yes. So, uh just to let you know, uh there are there are two PRs um together is 1455 and 14 63 by the same author. I don't know if they are interlin, but yeah, just letting you know. 145.

But uh if they're into link, they should mention each other. >> Yeah. I'm not sure that if there is a link already, but uh those are the next two PRs and I noticed that they have same author. >> Oh, okay. lightweight on registry for discovery AI

agents. and the underlying registry design on metadata. It's swapping a discovery problem. Let's see how they read it. Okay. And agent is registered for this register. Register key value.

Okay. I have a technical opinion. Uh, but I'm not going to post that on the editorial message. Why did that come on?

G26 the display of it should specify whether it's That's probably US. agent ID. Yes.

Followed by a column. I should be very small numbers. Normally they will have

64 digits in text format or 80ish Yeah, that's one of the same as every agent has a single owner must map owner address. This mean an agent ownership is determined by the chain of

which was registered. Oh wow. Must be one 115. This 1155 here. We're not using 1155. These are additional keys.

Images are recommended. Now backwards show security.

Okay, I think it's good as it drops. Yeah, we can further see reviews or changes in the review status when it is there. [clears throat] >> Okay. Uh what's the next one? >> So, okay. I guess you have covered both of them, right? >> I've only covered the uh one 1460. Do you want me to also cover the one 1455 next?

>> Yeah. Yeah, that is the next one >> on agenda. Yeah. >> Oh, this is missing. Let me see. I'm in storage. rectify this.

You are So world column Maybe. Okay. Maybe something that does not

value. How to describe one parameter is okay.

Review status and feedback on PRs, awaiting author's response

Yeah, I I think this is there's some change that need to happen on this these are premature ones. >> All right. So the next one is already reviewed by Sam Wilson and >> uh he has made the suggestions like he had already added the suggestions by Sam. So uh this is for the second review but to move into the status draft. >> Yeah I'll I'll I'll leave it to Sam. I think Sam is having an active conversation with with uh with the author and author has not give a summary uh response to it. Maybe author make changes but author have not uh basically said that they have all the concerns and

they have not responded yet. So I'll leave it to Sam to the author. >> All right. So, >> oh my god. Am I am I seeing different PS or the same PS? Okay, this is 1 126. >> Yeah, the same thing. Yeah, that's the same PR. >> So, the next one is 12 to 59. >> One, two. >> Oh, sorry. >> 59, right? >> Yes. Yes. I think >> that's the EIP. I think it's >> not six. One 59.

>> Oh, no. Six. Okay. Fine. I don't know what's wrong. Why my B is not getting right. >> Oh, [clears throat] our friend has made a number of onchain metadata for token registry. A key value store interface allow registry to store and retrieve. this is not the right way to HTML not this is not I think it doesn't probably

doesn't get um bought a yet is it? Oh, it's only being run. Yeah, the bot has not approved it. We can wait until the bot has been has addressed it. We're here on the

botto work workflow and not >> do we know any specific error or is it just that we can close and open and it might work. Uh no uh I because when I see that references this is probably going to be caught by the boss and it give me an impression that this has not passed the bomb >> because he has instead of making a relative.

>> Yeah. So I think he let's wait until the author has has addressed all the all all the bots feedback. >> Yep. That makes sense. ones. That's >> I guess there's >> Yeah. One, two, one, four, two, three has passed all the checks.

>> Let's see. One, four, two, three. >> Yeah, you just remove the module there. >> Yes, that's it. Okay. Uh let me proceed. It's great to end uh uh this office hour with approval.

>> Thanks. Nice. >> Thanks for the contribution to the standard. >> Thank you guys for the support. >> Let's go. Right. Uh that's it, right? Yeah, we made a lot of progress here today. >> Yeah, I guess there is one last we could not touch on that is already uh maybe if you get a chance maybe take a look at it async. U that was for second review. The PR number is 1227 and yeah we are good with all the items covered here today.

Review of PR 1227 and Async Discussion

Uh, looks like it was already Yeah, it was already reviewed by Sam and the author mentions that he has responded to all of his comments. Please have a check. >> Okay. Yeah, I'll I'll >> referable NFTt royalties as a draft. Yeah, let me see. Let me actually see if they they did uh address all s question and then maybe I could have put it in. Okay.

>> that's a common error. >> That can be fine. Uh right. Okay. I think they addressed all the Sam's question. Let me just uh authors has addressed all questions.

Awesome. >> And that was all the PRs. Those were listed here for review. Thank you Victor for taking our time and thank you authors for joining us here today. Next week we are going to be joined by EIP editor Gajjender Singh and we would be only taking EIP related PRs. So ERC PRs will not be reviewed next week. We will take it a week after. Thank you everyone for tuning in. >> Thanks. Have a great day everyone. >> Bye.

Conclusion and Next Week's EIP Focus

Oh, [music] heat. Heat up [music]

here.