EIP/ERC Blitz 2026: 100th EIP/ERC Editing Office Hour Special

Transcript

[music] [music] [music] [music] [music] [music] What's up? [music] [music]

[music] >> [music] [music] [music] [music] >> Heat. Heat.

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

[music] Heat. [music] >> [music] [music]

[music] [music] [music] >> Awesome. [music] [music] Thank you so much. Welcome everyone to

EIP editing office hour meeting number 100. Yes, this is 100 office hour. So congratulation to everyone. Today's like special milestone for EIP process and uh broader standard community. We started this space for authors to connect directly with the editors and this has grown into a regular forum for reviewing proposals and answering questions. I I believe this is helping contributors to navigate through the EIP process. So, thank you to all EIP editors, authors, reviewers, implementers and community members who have uh participated in these office hours and um I I believe we

are here because of you. Today we are hosting a special 2hour EIP/ ERC blitz. We did the first one uh in 2025. So super happy to organize this again. Thank you Sam Wilson for being there for next two hours and reviewing many proposals. Yeah. Well before we begin I would also like to thank the EIPS Insight team for creating a dedicated [music] dashboard for the 100th office hour. Um if anyone from the team is here please paste the link in the chat so we can bring it up.

I believe it is also added in agenda for people to follow. Um and whoever are listening it's [music] eipnite.com/eipoh 100. So this dashboard is directly create created for today's meeting for the [music] for the next 2 hours whatever we are reviewing in this meeting. With that uh let's get started. Sam thank you once again for joining and uh yeah we can [music] get started with the proposal in final. We are also joined by the author uh so in case you have any [music] question.

Sounds good. All right, this should be easy. Let's just give it a quick read through. So, specializing security. Okay, here standard interface for verifying AI agents on Ethereum. There we go. Okay. Okay, let's go take a look at that

diagram. There we go. Yep, that looks good.

Okay. The verification provider must call on the canonical identity register contract and result the returned URI to fetch against registration JSON file on metadata fields must be extracted from this JSON in accordance with the ERC registration. Okay. Direct submission of individual parameters without an agent ID is not permitted. Okay. Compliant verification providers must implement all the following verification types and apply them using resolve metadata. validates legitimacy and security of smart contract when a contract address is present to the resolve mediator. It must verify that the contract address is a displayed smart contract on the result by calling ETH get code and confirming the return by code is not 0x. Must check contract against known vulnerability.

Okay, cool. Okay. I should perform forensic analysis detect indicator generate concept. Okay. Okay. What is So, is this supposed to be the the only

check or is this part of the check? >> Yeah. So, it's if you look at the uh diagram, there's five different verifications on there. But in regards to the um media content verification, it's just that one run of a one run of one verification. Okay. Different areas using the CPA to Yeah, I guess I'm just um checking what the difference is between Ethereum token verification and code verification.

Yeah. >> Yeah. So, obviously with the um Ethereum token verification just looking at the contract address, the solidity code verification looks at all the solidity code within the verif. >> Okay, interesting. So, this one's like essentially looking at the bite code and then this one would be looking at the Okay. Um would it make sense to also have I know this is a little bit late but would it make sense to also have a um must verify that the solidity code I guess yeah this that you could compile it and then compare the bite code that'd be covered under that all right uh ensures the agent web endpoint is accessible security and metadata must verify response

check for common security vulnerabilities All right. [sighs] Good. It's good. Okay, that all looks good.

Okay. Yeah, that looks great.

>> Oh, let's move on to 4337. >> Yes. We have Alex on the call who is pushing the proposal. While you are reviewing Sam, I would also like to mention it to the participant of the call. We would love to see this call being more helpful to authors. So if you have any questions, whether you have a PR or not, if you have any questions for editors, please drop it in the chat and we would love to pick it up. Contract is an alternative model that allows each

account to supply validation logic executed. Smart contract code by the protocol provides unconditional the stock contract proposal which completely points any consensto changes instead of adding new protocol user operation. Yep. Okay. Historically introducing action has been Yep. Okay. This propos take a different approach voting any adjustments to consensus later to achieve the key goal of accountraction. Okay good. 772 bundler.

Okay, that's all fine. All right. Definitions. Uh, user operation is a structure that describes a transaction to be sent on behalf of a user. Joey computing is not named transaction. That makes sense. Like a transaction, it contains two called in a max fee per gas, max priority fee per gas, nons [music] signature. Okay. It's not defined by the protocol but by the smart contract. Account implementation contract execute puzzles operations.

Okay, that makes sense so far. Okay. Okay.

Okay. Verication. Okay. According to required for the smart contract account to have isa. Yep. The op user hash is a hash. Open the user op except signature entry point and chain ID. [snorts] I mean, it's not a huge deal, but it'd be nice to say how it's serialized. Um, but yeah, not a huge deal. Um, must

validate the caller is a trusted endpoint. Oops. Must validate that the signature is a valid signature, the user page, and should return should not return early when returning sig validation failed. should complete the normal flow to enable performing a gas estimation. That makes sense. Must pay the entry point caller at least the missing account funds which must be zero in case the current sender deposit is sufficient. [snorts] Okay, that one's a little bit more confusing. So if it's not returning early when doing

sig validation failed um it doesn't revert. So this rule as written says that even when signature validation fails the entry point must be paid. Um which is kind of confusing and probably not intentional. Yeah. Um I want to elaborate here uh what what is meant uh yeah so the idea

is that this call will never uh uh complete onchain because the returned code would not would be signature validation failed. So the entry point will not allow the transaction to go through. Oh, because the the entry point will revert as opposed to the entry point will revert. The smart account should not revert because that makes does estimation impossible. Um, >> that makes sense. >> So, it will in fact do the signature value like it will actually send the funds and the entry point will revert.

That's okay. >> Yeah. Yeah. >> The center will pay more than this minimum. The return value must be packed of um I can't execute would be caught by the entry point. Okay. For each key, the sequence is

validated by the entry point for each user operation of the nodes verification failed. accounts to implement any custom logic they may need operating on a 192bit key field without while fitting the occur. Okay. Okay, while preparing the user operation, bundlers may make a view call to this method to determine a valid value for the nons field. Bundler validation of user operation should start with get nons to ensure the transaction is valid nons field. If the

bundler is willing to accept multiple user operations by the same center into the me poolool, this bundler is supposed to track the key and sequence pairs already added in the meool. Yep, that makes sense. So, um, in order to require the accountant to have classic sequential nons, the validation function must perform Okay. Order administrative events. In some cases, an account may only of operations running in parallel to normal operations. In this case, the account needs a specific key when calling methods on the account itself.

Okay. must be an EOA with designation. The entry point validates the authorized address matches when specifying the user operation signature. Okay. If the sender does not exist and the init code is empty or does not deploy a contract at the sender address, the column must fail. Yeah, that makes sense. Uh, calculate the maximum possible fee the sender needs to pay based on validation and gas

calls. Yep. The entry point must be the call data bank code. Refund the treasure account. Okay.

Then I guess let's go take a look at your diagram here 4337. Guess we can just quickly look at them all. Yep, that's the diagram. Again, this is just the source code for them.

Okay, cool. Before accepting a user operation, bundler should use an RPC method to locally call the handle ops function in the entry point to verify that the signature is correct and the user operation actually pays fees. Bundler must reject us operation that fails the validation, meaning not adding it to the local mepool and not propagating it to other. Yep, that makes sense. In order to support any user operation objects button [music] noise which turn propagates from through the PTP meool, we introduce a set of JSON RPC APIs including E send user operation and ETH get user operation receipt. The full definition of the new JSON RPC API is outside the scope of this proposal.

Okay. Um the user opash is calculated as an A712 type message hash with the following parameters. Okay. Uh the eent user operation method accepts an extra e7702 o parameter. If this parameter is set, it must be valid 7702 authorization temple and must be signed by the sender address. The bundle must add all in a bundle set code TX type. Yep, that makes sense. If the init code field starts with a 7702 right padded with 18 zeros. [sighs] Uh this account was deployed using a 7702 transaction then the hash is calculated as follows. For the purposes

of house calculation the first 20 bytes of nit code field. The user operation are sent to the accounts 772 delegate address fetched with Xcode copy. The init code is not used to call a factory contract. If the init code is longer than 20 bytes and the rest of the init code is used to call an initialization function in the account itself. Okay. And note that a user operation may still

be executed without such a nick code. Uh in this case, the entry point doesn't match the current 772 delegate and can be potentially executed against a modified account. Okay. Additionally, each 772 defines gas cost of executing an authorization equal to per empty account cost 25,000. This gas consumption is not observable on train by the entry point contract and must be included in the pre-verification gas value. Okay. Um we extend the entry point logic to support pay masters that can sponsor transactions for other users. This feature can be used application developers to subsidize fees for their users. Allow users to pay fees with the ERC20 tokens and may many other use cases. When [sighs] uh the pay master

and data field and the user operation is done empty, the entry point implements a different flow for the user operation. Uh during the verification loop, in addition to calling validate user op, the handle ops execution must also check that the pay master has enough e deposited with the entry point to pay for the user operation and then call validate payment user op on the pay master to verify that the pay master is willing to pay for the user operation. Note that in this case a validate user op is called with a missing account funds of zero to reflect that the accounts deposit is not used for the payment of this user operation. If the pay master invalid pay returns a non- empty context array then handle ops must call posttop on the pay master after making the main execution call otherwise no call is done to the posttop function

pay masters could pose the risk of DOS attack against the system and bundler should take steps to mitigate it as a mitigation. butler should use a reputation system for contracts they serve and the pay master must either limit its storage usage or deposit a stake in a reputation system. All right. Uh the pay master and data field is a spider that contains a non-standard encoding of the following fields. Pay master address, pay master verification gas limit, um 16 bytes of gas limit. Okay. The following data can optionally be attended to the pay signature value by array to be checked by the pay master

contract. Pain master interfaces as follows. Uh the entry point must implement the following API to let entities like pay masters have a stake. [sighs] Okay. Yeah, it doesn't matter.

Yeah, I mean this is fine. Um, if anything comes up that's not clear later on, I mean we can add clarifications to final E. So, I don't think that's going to be a problem. Um, yeah, I think this is fine. >> Woohoo. ERC 4337 who waited for 5 years for us to organize the 100th office hour to get merged in final status. I'm so happy. Thank you [music] and congratulations to the team Sam. We have got a question.

>> Thank you. >> Sam, we have got a question in chat for you. >> Okay. Oh, uh let's see. Um the co-author of 7930 7827. We're trying to discern the next steps for this finalized. We believe that we are ready to update the statuses to final [music] and can Yeah. Okay. So, um 7930. Yeah. So, um once you're ready, you can open a poll request moving [music] it to last call and then you set a last call deadline of say 2 weeks out. uh that's the last opportunity for anybody to comment on these proposals

and then uh once that period elapse elapses you open another poll request to move it into final and then it's it that's it um Sam I would like to add something right over here I think author can explain it even further the reason why it is brought to this office hour is about CAP 350 which seems to be a proposal which is being mentioned and that is out of EIP repository. CIP 350 is not in the final status right now. The idea is to take it to living status but uh it's not there yet.

>> Yeah. Um yeah, there's there's not really much we can do here. Like you you shouldn't link to a draft from a a final proposal. Um uh but like as long as you link to a particular commit, I think it's okay. Um but you'll be linking to an outdated version of the [music] spec. So that's kind of a risk you'll have to weigh yourselves.

>> I'm I'm not sure exactly what the process is in terms of the call, but am I able to kind of speak or do I need >> Oh, absolutely. Yeah. No, no, this is absolutely a a conversation. >> Okay, perfect. Um yeah so uh the dependency on uh cape 350 [music] is essentially to uh separate out those elements that are final and immutable which is essentially the content of 7930 and then have uh the flexibility of a living standard within that uh Cape 350 whereby we can add uh profiles iteratively over time that define uh the conversion efficient rules for the

addressing systems of any blockchain software stacks that may come in the future. And >> I guess the issue is that uh obviously that's an unknown unknown. Nobody knows how blockchain technology is going to develop over the years and there could be uh multiple new tech stacks. um that cape in principle itself could be updated to being final because the highle cape 350 is um yeah that is immutable and well defined. It's just uh these iterative profiles that may um come or be updated over time that that that's kind of the confusion I

guess. Yeah, we don't we don't have a great process for dealing with um like lists of things that aren't that are like sorry, we don't have a great process for dealing with mutable lists of things. Um so what we normally suggest in the EIP process is just publish a new EIP that adds the the new type to it. Um but then you have the problem of you can't find them all easily. Um, so yeah, I mean it should be fine linking to the cape if you want to keep it. Um, >> okay. Uh, but the link would have to be to a specific commit.

>> Yes. >> Um, okay. I will feed that back to um my other co-op. I mean, obviously these specifications have had many authors over the years, but kind of this this recent push to update, clarify, clean up, etc., etc., has predominantly been from myself and the team at Unruggable and Mono Orca and the team at Wonderland. Um I will [music] converse with them. I assume yeah if we go through that process create uh PRs for final call set uh a deadline in a couple of weeks and then potentially uh I'm not sure how regular these these calls are but potentially would um there be an

opportunity for kind of live review of that uh push to final uh perhaps in a month. >> Yeah, there should [music] be should be a slot for that. >> Okay, perfect. I will do that and I will feed back that back to everybody else that's contributed to these and uh [music] get them moved forward. Sounds good. >> Thank you. >> All right. Oh, yeah. I am an author on this one. Forgot about that. Okay. This is odd. Why are you breaking like this?

Um, sorry. Okay, I just want to take a few minutes to >> No, that's perfectly all right. It's good that we have brought up this you. >> Okay, I see what's going on here. So, if we go here and let's say so Skeletor spaceman. So, you have a non-breaking [music] space there. But what we actually need is span And then Okay. And then

this one. So I guess it'd be Yeah. Okay. So we'd have to add that. I will note that down somewhere. Um Oh, one second. Someone's at my door.

Sorry about that. Just getting some mail delivered. All right. So, note written down and we can continue on. Okay.

Yeah. No discussion on there. Good. Why do you do this? Okay. >> Yeah, you can absolutely chat. Um, >> you can hear me?

>> Yep. >> Hey, Sam. How are you? >> Not too bad. >> Did I join at a bad time? >> No, no, not at all. >> Okay. Yeah, I uh I I just like a couple weeks ago made my first couple edits to an EIP and I was like, "Yeah, this is fun." So, uh uh wanted to just kind of know how I can be a helpful community member without, you know, getting in the way. I know it takes time and effort to bring someone up to speed, so I didn't want to I wanted to be conscious of >> Oh, yeah. that. Yeah. >> Um so, I guess there are two general areas you can contribute to. Uh well and and um that's excluding the stuff on the um cat herder side. Um but uh so for the EIP process itself there's uh

contributing technical feedback and reviews. So if you're you know knowledgeable about Ethereum or about any particular domains [music] going on Ethereum magicians and giving feedback on people's proposals asking them questions getting things clarified. Uh that's a super useful thing to do. we'd never have enough people reviewing uh the technical side of things. Um >> yeah, >> so just to give you my background, I I've been a security researcher at Open Zeppelin for three years now. I'm at Cantina. Uh I've always just kind of been doing my own thing and would love to get more involved. So technical stuff, what do I how do I I mean find the technical things that need help.

>> Sure. Um so if you go on Ethereum magicians Yep. and you go under say just the ERC's tab um pretty much anything in here that you are interested in or um you know you you have some relevant knowledge you can just click on it and provide feedback. Um, >> I know that's like a a hugely wide thing to ask of somebody, but yeah. >> Yeah, I've been looking at uh so so so in terms of like writing EIPs. Okay.

Yeah. So, seems like there's two sides. One is like vetting EIPs and another is like drafting and writing them. >> Yes. >> Uh, >> which are you more interested in? >> I mean, either I I I you know, the technical side, you really have to go deep. So, I've been looking at 8140. Uh because that's like the the one they've been trying to get to Hagota for a while. Or are you 41? What? >> Yeah, frame transactions. >> Yeah, frame transactions. Sorry, not 40. 41. Uh yeah, >> I'm also working on that one. >> Yeah, there's so much to consider and think about and so much discussion, you know? So, it's like >> if if I'm going to put time in, that's going to take all of the time. So, it's like, is that the best use of my time, [laughter] you know?

>> Yeah, it's it's hard to tell, right? Um, but that is probably like with somebody with a security background and that kind of knowledge, that is probably where you'd be most useful. >> Yeah. Yeah. The politics side of it seems like a very supercharged EIP. >> They always are. >> Yeah. >> Yeah. >> And then I guess the the other side is um on the like the shape of EIPs, you can contribute as an editor uh or at least as a a reviewer for the time being. Um so that would be like going through and making sure that you know the motivation is in the motivation section and the rationale is in the rationale section. So that one requires very little technical knowledge. Um yeah if like yeah the way I see it is like if

I have an hour and I and I only have an hour, what could I time box in an hour? What could I do? What could I where would you want me to be helping if I only had an hour? >> Uh personally I'd say grab any pull request and review it for like adherence to EIP1. So like a non-technical review um just provide feedback uh on Yeah, that would be the most useful thing. >> And and you want me to be jumping into the EIP's GitHub or the ERC's GitHub? Which one? >> Uh either um there's lots lots of pull requests on both. So >> yeah.

>> And then uh Okay. And I'm not a reviewer. So who who are the people that I should be is it is it obvious who I should be tagging if I start reviewing things? uh just review them like the exact same way that I'm doing. Just like leave comments on the poll request and Yeah. >> All right. >> Yep. There there's no like um requirement for somebody to be approved before you can leave reviews. So, just go ahead and do it. >> And can I ask you something not related to the IPs?

>> Sure. >> The the Solidity language guys seem to be pretty sequestered. Um, I've offered to help out like a few times over there and I don't get any response. I don't know how to pierce that veil. >> Um, unfortunately I can't uh Yeah, can't help you there. >> Okay. Yeah, they see they seem to be very just secluded like in an ivory tower. They do great work. I'm not like criticizing just like I've seen some PRs there where it's like I can help and nobody responds. So I'm over here now. Ah, >> it's all good. You know, disagregated community is what you get. So, >> yeah. Yeah.

>> Cool. Well, thank you so much for taking the time. I I uh that was all my questions. Appreciate you. >> Cool. Well, thanks for coming out. >> All right, back to setting the last call deadline on this. So, then check out seven eight Uh so then this is the RC 7813 and two weeks from today is the 16th.

>> [sighs] >> All right. So, I can't edit it for some reason. I can't push to it for some reason. Why is that the case? Where's the little check mark? There is no check mark. Okay. Okay, let's review this one.

Um, actually do want split. Okay. Um, store table based introspectable storage onchain tables for automatic indexing and introspectable state. Some author is good. Last call deadline. Good. Okay. The introduces a flexible onchain storage pattern that organizes data into structured tables that consist of records with fixed key and value schema similar to a traditional database. The storage pattern consists of a unified contract interface for data access along the compact binary encoding format proposed static and dynamic data types.

Yep, that's a good abstract. Uh the absence of consistency for onchain data management in smart contracts can lead to rigid implementation setup contract logic and challenges in updating or extending a contract's data layout. This pattern leverages unstructured storage making it easier to operate a contract without the risks associated with using a fixed storage layout. New tables can be added at runtime without breaking existing [music] integrations with other data consumers. Okay.

Okay. So, a store is a smart contract that implements the interface pro that makes sense. Okay. Okay. static length fields. Okay. Okay. And then share I encourage the bite length of dynamic

fields of a specific record. Mhm.

Okay, cool. So create this. I should guess I'll let you finish. Okay. I can never spell that. Where there I

go. Okay, cool. So, that one's done. 1779. [music] Okay.

Okay. transfer both tokenized vault requests 7540 enabling optional transferability depending. Okay, let's go see what discussion we have need to include sender in the transfer deposit request. Okay, did they take care of that? Yeah. Okay. Perfect.

There extends by adding optional transferability of pending deposit and redeem request and introduce two separate interfaces that allow a controller to transfer the pending request balance to a new controller. Implementations may support either or both interfaces independently. Okay.

Yep, that looks good. Cool. So, moving on to moving to review 1692. Uh conditional send transaction RPC JSON RPC for block builders allowing users to express preconditions for transaction inclusion. Okay.

Send raw transaction conditional for block builders and sequencers and answering transaction allowing users to express preconditions. Okay. Oh, okay. Interesting. So, you can express like how a transaction will fail without actually having to execute EVM. That makes sense. Um, simulate transaction CPU intensive. Um, Okay, that makes sense. Before I accept

the request for a block builder, our sequencer should Yep. Check that time stamp is within the time stamp range. Should reject the request if any address is not. Um okay. In case of a successful

inclusion, the cost should return a hash of the newly submitted transaction. This behavior is equivalent to the Yep. In case of an immediate failure to validate with the transaction conditions, the block should return an error with the indication of the failure reason. Okay. The error code should be B with reason string. Okay. In the case of repeated failures or known account mapping being too large for the current block builder. Okay. Uh the same as within even with an RPC method does not result in an error and the transaction is initially accepted.

Yep. That makes sense. Good. Okay.

So, I'm going to take a few minute break. I will be right back and then we can continue on with the second hour. >> Very well. Thank you, Sam. In the meantime, maybe we can go for a quick recap uh of what we have done so far. I'm looking at the chart uh uh at uh eipnite.com/ipoh 100 and we have two proposals moved from last call to final and two from review to last call. I think there is some error but we have two proposals moved to final and those are

um ERC 4337 which was originally documented back in 2021 and [music] now is finally getting to final status in [music] June 2026. over 5 years of journey lot of hard work that went into and u the proposal has made so so grateful um impact in the ecosystem everybody knows about 4337 because account abstraction is one of the basic proposals that were used for wallets and all thank you to the team for all this hard work and uh yes we made it to final status the next proposal that went into final today is ERC 8126.

This proposal is about AI revolution. [music] So this proposal is AI agent verification now that everybody is using AI in U programming. So I believe this proposal by uh Cyber Century, Chris John um and and rest of the people who may have contributed to this proposal will help them build something great. Sam, I am just trying to fill up the time while you get some rest. Let us know whenever you are back.

In the meantime, uh we also moved proposal 8161 to the last call. So the proposal 8161 is transferable tokenized vault request and uh the last call will end in 14 days from now. So if you have looked into this proposal and you have thought suggestions in order to uh like you know improve the proposal or if you may have implemented please feel free to drop a comment a note on ETH magician forum. The link can be found [music] on the EIP itself. The ERC number is 8126.

We have a few proposals for review and a bunch of open for draft like to be merged as draft. [music] We are looking forward to have them reviewed today. Do we have Sam back? [laughter] Quickly checking. Um not yet. But uh I also want to share this information with the community that um this office hour is a a place where you can actually reach out to editor and have your questions answered. I know there are over 400 open PRs

over 400 PRs and um it is even difficult for editors to go on reviewing them in one week. So if there are certain things that are pending for long, please join us in this office hour and check with editor what's going wrong. Yes, let's go ahead with uh uh with uh uh PRs uh which are listed in the agenda as well as whom for whom we have authors available in this call. So we can respond to their questions um like right here right now. These calls are organized once in a week. It's on every Tuesday at 1600 UTC. You may see different editors, but we've organized

this office hour frequently in order for uh a forum where people can reach out. You can also find the schedule of the next office hour right here in the bottom of this agenda. It's called EIP office hour calendar. So from there you can always like find what is the next um available editor's time you can join the meeting and you can uh share your PR in case there is something stopping or blocking we always expect editors to take these PRs review these PRs async but in certain corner cases we would appreciate people to just show up get your questions answered and we move the proposal forward.

Please drop your questions in chat. I'm happy to respond to them while we are waiting. I don't know if we can have some music for some time. >> Oh, I'm back. We're good. >> Thank you, Sam. So yes uh we are next headed to move to review proposals. Yes. Yeah.

Okay. So we did this one already. Um you know honestly I think we can just approve this and they can fix Yeah. Okay. Okay.

Okay, let's put you in 7679. Okay. Is uh 7609 the right one here? Pujo.

>> Um 7691. Let me quickly check >> 7609. Nope. No, no, no. I might want to fix that. All right, I will come back to it. Move to withdrawn. This one should be easy. For anyone in the call, if you have an

open PR and you're waiting for review, please feel free to drop the link in the chat and we will try to pick up after uh the current one so we can respond to your queries and make sure the proposals are moving forward. Okay. Um

yeah. Okay. So Yeah. Okay. Okay.

Okay, so I need to send an email to these people. What's so And has opened a little against

VIP 867. Seven because no didn't have username is present in Okay.

Okay. So that's easy enough. >> So Sam um couple of things. Uh first I have fixed that uh uh EIP number. It's 7607 and we have got two authors on the call. Maybe we can take it after that. >> Sure. Of course. Okay. So that looks better. So, it was supposed to be Faka upgrade. >> Yeah, that makes sense. Uh, so this is going to review the CF documents. [music] Yeah, that seems fine. Um,

>> thank you. And in the chat, I have uh written all the PRs which >> which we received in the order from from the authors on the call here. Okay. So, moving on to 1396 [sighs] minimum interface.

Okay, >> Sam, you already reviewed this one a long time ago and I um made all the changes you required. >> Perfect. >> So may maybe you can check uh further down. Okay. Heat.

Okay. Okay. New proposals are always longer to

review in office hours. >> And this is a this is a long one. If there is someone in the call whose proposal is already been reviewed once and they have worked on the suggestions from the previous call, please surface your pers. Uh otherwise we'll be going through the PS which are already shared in chat. All right.

ancient NFT findings. You know, we have author Prem on the call. Pre, if you have any questions, please share. Otherwise, Sam, if you find something or some questions, yeah, he is here. >> We'll do. All right. And now we're on to 11545.

Oh, no worries. Take care. Okay.

Okay. So I think that is all the pre-lin ones. [music] >> Oh yeah, I have also fixed for PR 1156. Okay cool. Maybe I can quickly share some stats with people here. We have reviewed nine EIPs so far and six are from ERC's repo.

Three are from EIP's repo. We have got one new proposal merged as draft, one moved from review to last call. Uh two from last call to final, one to withdrawn and u one from draft to review. Sam's activity as per the leaderboard here is 11 uncount including all reviews, comments and merge. And yeah, we have a few more proposals to review. We have like 15 minutes. I think we can pick up the one that we received in the comment as chat. Sam, if you want to take it as the last one that is 1747 on the ERC repo.

>> Sure thing. >> Thank you. Cool.

So, I might have time to do one more. What do we have? We have eight minutes left. >> Probably not. Probably not a whole draft. So, um I'm going to say we wrap it up here. >> Yeah. Very well. I mean we did a great job here because we have merged so many proposals today. We have like two final, one last call to review, one to withdrawn as well as uh one to to the draft. So definitely good use of two hours that we have here today. Thank you everyone for joining the 100th EIP editing office hour and thank you so much Sam Wilson for spending last two hours reviewing these proposals

answering questions and helping authors navigate through the EIP process. >> It's my pleasure. Thanks for hosting >> very well. Um and um yeah thank you to everyone who have participated for the from first office hour till the 101. These sessions are to just make sure that process are accessible, transparent and we we need your collaboration in order to keep moving forward. We have added the office hour calendar in the agenda and we keep it adding to every office hour agenda. So please take a look at it and join us whenever possible. Will see you all in the next office hour. Until then, keep writing, keep reviewing, keep improving Ethereum

standards. Cheers everyone. [music] Heat. Heat. [music] [music] [music] >> [music]

>> What's up? [music] [music] >> [music] >> Thank you. [music] [music] >> [music]

[music] >> Heat. Heat. [music] [music] Heat. [music] Heat. [music] >> [music] >> Heat.

[music] [music] Heat. >> [music] [music]

[music] >> Heat. Heat. [music] >> [music]