EIP Editing Office Hour #64 (EIP + ERC)
EIP Editing Office Hours · 8 Jul 2025 · 1:01:37
Meeting 64 of the EIP Editing Office Hour, held on 8 July 2025 and covering both EIPs and ERCs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers ERCs heading to Last Call, Review and Draft, force merges, and additional reviews from the project board.
Topics
From EIP Editing Office Hours, hosted by ECH Institute.
Transcript
[Music] Hey, [Music] hold on. [Music] Okay cool.
The contract name contract addresses must the references to every standalone contract used within protocol contract deploy proxy contract of choice on top of the registered contracts must reject the registration of zero addresses must. Okay. So proxy contract added. Okay. Works together with dependent
contract contract dependency injection mechanism. Okay. Okay.
String contracts identify shows over the year 256 and by stage two to K be typical for users to interact with it block stores or Dows. Clarity was prioritized over gas usage of the string identifier. Event parameters are not indexed. string parameter would become the k 256 hash of the contract name if it is larger than 32 bytes. Okay, the get contract view function reverts if the respect contract is address zero. This is central to minimize the risks of misinitialization of a protocol.
Okay, fine. Yeah, this is fine. And this is going into last call. Sure. Okay, moving on to 4361 signing with Ethereum. It's approved.
There's the former from the original suspect by saying the terms of practicality in practice today. So I'm happy to prove here as well. Good. Nice. Okay. Why do people do this? Just let me edit your things. It makes it so much easier. And what is two weeks from today, the 22nd? Okay.
So sign with Ethereum Ethereum authenticate without chain services by sending a stat message for map part scope session details and security mixed. Actually I'll just check how this has changed since my last review. Good. Good. Yeah, that's all fine. So this just needs the date to be changed. Okay. 4361. So 4337.
See, has this one changed? Nope. All right. 7829. Okay. Data asset NFT. Bring data assets online digital products to NFTTS to ensure their integrity through a storage proof. Neat. Okay. This is an extension of ERC 721. This proposal introduces a new role reader who is granted by the owner and allows multiple readers for single NFTt. Additionally, this protocol extends the metadata interface of ERC 721 requiring that metadata should include at least a commitment size, expire time, and upload address. This proposal also proposes a storage mechanism to ensure the
correctness of metadata information. Let's see if the rest of it's okay.
Yep, that's fine. Three parts size expire short information. Shut the addresses modify this information contracts and blockchain. Okay 721 Okay. Okay, that's fine. Tristan read
permissions ask. Okay. Yeah, I um
I agree with you. I really have no idea what this is trying to do. Like it's missing like a statement of purpose. Like what what is it trying to accomplish with this stuff? I mean it looks like it's trying to I mean I get what problem it's trying to solve. At least I think I do which is that the the actual content of NFTs generally is not on chain doesn't have any proof is completely malleable. like you know um and it sounds to me like it's trying to generate some kind of proof that's stored on chain as to the validity and veracity of the of the like content stored elsewhere. But like I
kind of fail to see what a proof on a contract does. Like I mean let's say everything's put on an HTTP domain. Then I mean you can still just rug it right after you put the proof up and put something else there. Like I mean aside from the fact that since there's no way for the contract to know if it's a valid proof or anything like that, there might even be ways to to spam something that at least looks like a proof. Um or to I like I don't know. It's like Yeah. Don't know. But yeah, whatever. Why not?
Yeah. Like I'm not I'm not critiquing the the technical merit of it. Yeah. Yeah. Yeah. Yeah. Okay. Wait. So Okay. The biggest for disability. Okay.
So, your rationale is just wrong. Um, Okay.
Yeah, cool. So 7829. Moving on to the luck token. Define restricted security here.
I don't Okay, you got your dead today. Move it up to the top. Okay. Well, let's just give this a read. Cool. That's a much better description.
Um, EFC 7752 defines a lot based token model. Each issuance or acquisition event means a unique lot lot ID that carries its own quantity cost core interface also standard is pause freeze force trans other beautiful abstract okay traditional token standards excel funability or single indivisible items real world assets equity certificates that native fraction sit between those extremes when issu may create thousands of discrete lots over time each lot needs cost basis vesting or lockup data regulators demand pause freeze and force transfer powers your C7750 basis requirements to single determinist KPI. So wallets custodian tax. Cool.
Um Yeah, absolutely nothing. Um car interface. Oh, you can't use this.
I was just looking at the license line and wondering if it was an issue. Yeah. Yeah. I'm pretty sure this is the business use source license. Yeah, her business first license. Yeah. Okay. So, I'm not even going to look at
that. Um, okay. And for Yeah. Okay. Okay.
second. Yep. What does DOI mean in this context? Uh document object identifier. Um, if you've ever seen like academic papers, they're assigned a unique identifier and then uh we have a way of linking to things that have those identifiers.
Oh cool. Why isn't only one of those ERC's linked? Because the other ones have been mentioned earlier. So Oh, got it. Yeah. Yeah. probably better to link them all, but uh that conclusion smells like GP2.
Yeah, it really does. Uh, frankly, I mean, using GPT to write EIP actually does sound like a good idea, though. I've got to say, just like nail the sections, right? Things like that. Like, I could see it having an easier time, especially for someone who's new to it. It does a really good job of writing text that is plausible, but it can't follow the rules to save its life. Oh, really? Oh, I was thinking it would be the opposite. Uh, I was thinking it would follow the rules and the text would be kind of meh.
I mean, maybe if you post the um like EIP1 into your prompt, but yeah, most of the time it just generates random sections that are just like not a thing. Yeah, connection API. I think I just got pinged about this one today. So, this is good. All right.
With modular capabilities. Yep. Perfect. Uh, sort of. Um, Do you have any specific questions about
10002? Hey. Yeah. Um, I just hold on, let me refresh. Um, so I see that your latest comments have been addressed. I was wondering, is this now at the bottom of the queue? Uh, yeah. So, the way the Q Well, I mean, you're here, so I'll review it now. Um, but generally speaking, the way the Q works is it's sorted by the oldest author interaction on the pull request that comes after an editor interaction.
Um, okay. So it doesn't necessarily go go back to the bottom of the queue. No, no, it goes to like if you just edited it now, it would be at the end of everything that has been dealt with. It's a little a little confusing. It's a Rust project if you really want to dig into it, but yeah. Um yeah, I I can read this now since you're here. Um interal addresses a binary form which refer to an address specific to one chain. All right. It's a binary form to describe an address specific to one chain with the companion specification for human readable display.
Okay. This is for version length prefix binary envelope that supports arbitrary length data that the interpretation of serialization rules for the data envelope were defined by companion standards which provide profiles for each chain type. Current Ethereum addresses like chain specificity and evolution check sums creating several challenges or such education. Okay. Put the insights from Okay. that you use dashes for some
reason. I thought they didn't. All right. Which combines spicity compact binary form and crushing missing addresses entrop infrastructure at the edges of and beyond the ethereum ecosystem by supporting representation addresses. Okay. Any future address will be convertable in address one which together with makes them mechanical representation of treat them opaquely. Two triple addresses converted to the will be bitwise equal if okay short enough to be compared by humans enough for easy differentiation of target addresses independent of the actual date. Okay.
So cape 10 proposes a standard text format to represent what in this document is defined as target addresses since it's taxon with the representation of the serialization to serialization of the various transform. Yep. Not being able to guarantee canonicity. Yep. Uh so the text is of little use for smart contracts for crosschain liquidity transfers. Messenger pass. Yep.
Comparable to Cape 10 without going through binary representations. Backward compatibility should not be an issue. Um good. Okay. Address binary ambiguously. Okay. Chain type chain reference. Chain reference address. Okay.
Yeah, that looks good. Cool. Hey, thanks for coming out. Um, cool. Thank you. Good luck with the standard. Um, so what? Um, sorry. Let me pick up here with it. Oh, so this has been approved now and we can expect it to be uh merged. Yep. Great. Okay. Thank you. Take care. All right. Back to the wallet connection API.
uh leverage the monitor capabilities approach in 5792 to streamline connections and authentication to a single interaction with application of control support for more secure function connection flows need for unified access connection become apparent. This is especially evidence in the case of batch connection with authentification where existing methods like like extensibility require at least two separate user interactions connect then sign Okay. Good.
Good. Good. Good. Disconnect. So fine. Initial authentication. This is fine for a draft. Okay. So, that was 779.
I'm sorry to interrupt. Do you if the um automerge is going to go through because this this PR had um HTML proofer error um and it may have required manual merge. Let's see. Uh 7828. So has that been merged yet? 928 not yet.
Yeah. So the the this was um a circular dependency. Yeah. Okay. That there there was a previous comment that you know there will be some exception made. Yeah I can merge that for you. So everything looks good here. Nice. Thank you so much. Ma'am, if you may uh refresh the agenda.
I have also added one uh PR for the draft on the EIP section. Yeah. Uh it was requested by the proposer in the Oh, sure. um
mechanism for RPC providers to advertise your service endpoints, capabilities and agreements via DNS, SD and direct IP queries. Okay. Okay, so this is arguably networking or maybe interface maybe
Okay. Yeah, I mean this is arguably networking since it does relate to networking.
What's what is the actual definition of a networking EIP? Where is that? Is that in here? Okay, let's actually give this a read
through before I say it. Yeah, this is one of the things that um chat JPG does. It bulls the titles for some reason. Um, Let's go see what goes in the interface.
face language level standards and contract API. So, So that would be moved to ERC with the
same number. Yep. Okay, cool. Assuming it's been assigned a number. Um, 7 95 9. I guess I can finish my review. That's all fine. Just look at the methods.
Yep, that's fine. Okay cool.
Sam, I know we have 15 minutes left and a bunch of uh PRs for draft, but I believe if you can take a look at the miseliness and the PRs which are waiting for force merge. Sure, I can do that. Yeah, we can perhaps close more. All right. July 6th, we are past the deadline.
Okay. Okay. Good. So we can close, reopen, and that should merge. Okay.
JSON RPC hex value encoding reference to ethereum.org. Please see the updated link to the Ethereum wiki for JSON RPC hex value encoding and e with the current and maintained documentation on ethereum.org. All right, where is this redirecting to? Jason RPC hex value encoding. H interesting.
[Music] Okay.
Add link to rest EVM reference implementation. No. And this is valid for all clients.
lines right? Uh for everything. Yeah. Yeah. Okay. Change specific considerations. a session to the AP template to address any chain specific consideration. The aim is to reduce the likelihood of incidents like the racolia which are caused by minor differences between chains. VIP authors address these considerations
might be caught earlier. Okay. So yeah, this is still um do do we have an active call for input? Yes, I no I'm not sure. Uh okay.
Yeah, I don't think so. Um maybe want to create one. I mean it's fine if you want to do it u yeah change specific considerations. Yeah. Okay. I'll um yeah I'll make a thing for that. Uh change specific consider vulnerable dependencies. Yeah, I think this is still the case.
Yeah, still the case. All right. Fix minor typo. Yep, that's fine by me. 627 1355. Place the link to the Eash main loop section pointing to the archive GitHub wiki with an updated link to the Ethereum. Okay.
So instead of blinking just it's withdrawn. Wait, does that even No, they don't. That doesn't even make sense.
Change the hash function that the DAG item in Echithm from FNV to the new FNV 1A. But this doesn't mention F and V in that section. dimensions are way down here. Whatever. Um, source Ethereum. What fork is this?
I guess it doesn't matter. So, we'll grab Frontier. Frontier. Actually, it's probably going to be in here. Is that what it's looking for? FNV index.
Yeah. All right. So, I guess I'll just do this. Go. Go here. and
hash There we go change divided by mix hashes times mix hashes. That's not the right one. FNV. FNV FNV.
Take care. Okay. I'm not familiar enough to make this change, so I'm not going to. But I will just say [Music] Okay.
Cool. And I suppose we covered all the miscellaneous and that's all the time we have for today. Well, thank you Sam for joining us here and for people if you have any more open pull request please add it to the next meeting agenda. See you on Tuesday at 1600 UTC. Thank you. Take care everyone and thanks Puja. Rick [Music] on
[Music] hold on [Music] Heat. Heat. Heat. Heat. N. [Music] Hey hey hey.
[Music] Heat. Heat. N. [Music]