- The video is an interview with Victor, the EIP editor for Ethereum Cat Herders.
- Victor is focused on ERCs (Ethereum Request for Comments) and promoting open adoption and standardization for ERCs.
- He became interested in Ethereum after realizing the potential of smart contracts and their ability to execute promises without relying on trust in individuals.
- Victor has authored several ERCs, including ERC1202 and ERC437, and has sought feedback from experts in the field.
- He became an editor after being approached by others who recognized his value in providing feedback and reviews.
- Victor explains that EIPs (Ethereum Improvement Proposals) cover a range of proposal categories, while ERCs specifically refer to application layer proposals.
- There is some confusion regarding the use of EIP and ERC terminology, but the distinction will become clearer with the EIP/ERC split.

- ERCs must be referenced using EIP/ in their proposal body
- ERCs mainly target smart contract solidity APIs, while EIPs are more client-based and affect consensus layers
- Typical ERCs include ERC20, ERC721NFT, and ERC4337, while typical EIPs include EIP1559 and EIP844
- ERCs are important for interoperability and network effects in the industry, as evidenced by the $38.9 billion locked in DeFi powered by ERC20
- ERCs have a final status, meaning they are not updatable, but there are discussions on introducing mechanisms for updates
- Moving an ERC from draft to final involves creating a GitHub pull request, adding specifications, and opening a discussion thread on the Ethereum Magician forum
- The ERC goes through stages of draft, review, and last call before being ready for adoption

- The last call for an ERC is to ensure that people are satisfied with it and ready for adoption.
- The deadline for the last call is usually two weeks, unless there is major feedback or updates to the specification.
- The concept of something being "final" is open-minded, with a basic sense of worthability and functionality.
- There is no requirement for an ERC to be final, but clear definitions, rationale, and consideration of security are necessary.
- Reference implementation and test cases are highly recommended for boosting adoption.
- The speed at which an ERC becomes final depends on consensus and the need for implementation.
- Adoptions give legitimacy to an ERC, and sometimes EIPs are left stagnant due to lack of time or difficulty in meeting editorial requirements.
- There is no clear way for authors to pass on their work to others, but help and contributions are always welcomed and appreciated.

- The speaker discusses common mistakes made by authors in proposing ERCs.
- The first mistake is not researching existing conversations and proposals before proposing a new ERC.
- The second mistake is not providing reference implementation and test cases, which hinders mass adoption and interoperability.
- The third mistake is not prioritizing open interoperability and adoption, often due to promoting their own project.
- The speaker mentions the importance of collaboration and compromise in creating successful standards like ERC-721.
- There will be a split between EIPs and ERCs in the future, with different repositories and governance approaches.
- The reasoning behind the split is that the groups working on EIPs and ERCs have different goals, knowledge, and governance approaches.
- The split aims to address difficulties in EIP editing and increase engagement and attention to proposals.
- The split will require updates to links, governance, and processes, but is expected to bring many benefits.

- The process of finalizing proposals involves technical changes, repository updates, website updates, and bot updates
- The speaker is optimistic that the process can be completed in a few weeks to a few months
- They encourage people to stay informed and not be surprised by the changes
- The team will handle moving proposals into the correct domains for authors who are already in review or working on proposals
- The speaker discusses the skills required to become an editor, including technical skills, editorial skills, and fluency in English
- They emphasize the importance of passion and commitment in supporting the group
- The workload of an editor varies, with stats showing the number of EIPs at different stages of the process
- Adoptions of ERCs are also highlighted as important, with a mention of a tool called ERC detection to track adoptions

- The speaker is working on conflict of interest and promoting their own insights.
- They provide a link to EIPinsights.com, which has 687 EIPs.
- The speaker shares their interests outside of Ethereum, such as distance running, Frisbee, improv theater acting, reading, and singing.
- They invite people to join ERC dev and participate in authoring ERCs and EIPs.
- The speaker encourages open and interoperable development in Ethereum.
- They mention a meetup for ERC authors and app builders in Istanbul in November.
- The conversation ends with a thank you to the speaker and the audience.

- Victor, the EIP editor for Ethereum Cat Herders, promotes open adoption and standardization for ERCs (Ethereum Request for Comments).
- ERCs are application layer proposals, while EIPs are more client-based and affect consensus layers.
- ERCs are important for interoperability and network effects in the industry.
- Moving an ERC from draft to final involves creating a GitHub pull request, adding specifications, and opening a discussion thread.
- The last call for an ERC ensures satisfaction and readiness for adoption.
- Authors often make mistakes by not researching existing proposals, not providing reference implementation and test cases, and not prioritizing open interoperability.
- There will be a split between EIPs and ERCs in the future, with different repositories and governance approaches.
- The split aims to address difficulties in EIP editing and increase engagement and attention to proposals.
- The process of finalizing proposals involves technical changes, repository updates, website updates, and bot updates.
- Becoming an editor requires technical skills, editorial skills, fluency in English, passion, and commitment.
- Adoptions of ERCs are important, and a tool called ERC detection tracks adoptions.
- The speaker invites people to join ERC dev and participate in authoring ERCs and EIPs.
- The conversation ends with a thank you to the speaker and the audience.

Topics covered
---------------------------
1:05 - Introduction
7:10 - What is an EIP/ERC?
14:15 - ERC updates after finalization
18:40 - Stages of ERC lifecycle
25:15 - Updating stagnant ERC/EIPs
30:30 - Common ERC/EIP mistakes by authors
36:10 - EIP/ERC - Split
43:00 - How to become an EIP editor
48:00 - EIP/ERC statistics
52:03 - Interests 
53:11 - Takeaway from guest

Show notes
--------------------
Victor: https://twitter.com/ZainanZhou
Haresh: https://twitter.com/h_gedia
EIP Insights: EIP stats visualized in a dashboard (https://eipsinsight.com/home)
DevConnect Istanbul meeting details (https://medium.com/ethereum-cat-herders/erc-devconnect-2023-4c343289b3cb)
Dune Dashboard ERC adoption statistics.  (https://dune.com/ilemi/erc-and-eip-starter-kit)
ERC Ref discord ( https://discord.io/ERCRef)
ERC Ref contracts (https://github.com/ercref/ercref-contracts)

Connect with Cat Headers
--------------------------------------------
Website: https://www.ethereumcatherders.com/
Twitter: https://twitter.com/EthCatHerders
LinkedIn: https://www.linkedin.com/company/ethereum-cat-herders/

Meet the Herders Hey everyone, welcome to Meet the Herders.

Meet the Herders is a series of interviews with past and present members of Ethereum Cat Herders.

Ethereum Cat Herders help coordinate upgrades to Ethereum by aligning multiple teams from wallets to protocol clients.

They also assist individuals and teams to write EIPs and ERCs.

Ethereum Catalyst also surveys and informs the community as the landscape changes.

Today, I'm pleased to welcome Victor, who's the EIP editor.

So like as the start of every show, I request the guest to please introduce themselves to the audience and tell us what you are working on currently.

So in this context, I am an EIP slash ERC editor, and I spend most of my time on the ERC side as opposed to other EIPs.

And we will get into this because the name is confuses many people, including some very core contributors and very deep involvers.

And I also try to initiate and build a community to promote ERC and open adoption and open standardization for ERCs, which is called all ERC devs.

And in addition to Meetup, we also have a smart contract repository on GitHub to be completely open for people to share reference implementation.

So my goal is to help Ethereum, the ecosystem, to have a lot of different applications that can interoperate with each other.

And may I ask how did you discover Ethereum and how did you get started with it?

Everyone I meet in the crypto space, especially in the winter, I like to ask the same question.

For me, I first learned about Bitcoin in around like 2011 or something.

I had a hard time realizing the real impact of what a blockchain could do.

And when Ethereum comes out, I look at it and realize, okay, small contract could actually make you promise something that in the past you have to trust a person will do, but now it will be executable in the witness of almost everyone.

I see myself a big part of my life is to drive community building.

So a lot of problems lies in how governance work, how do you make sure that people are properly aligned in governance decisions, and how do they respect each other and give people a voice.

And so if you come up and then I said, okay, we see ERCs, 20s, we see ERC721s, and realizing that there was no proposal of standardization for voting.

So I started out doing ERC1202, which is still a draft by the way, because I think it's still very, very early in how governance will converge, but we evolved.

So ERC 1202 is what I authored to begin with.

I realized, OK, it's not just about voting, but also how to execute it.

And so I further down proposed a bunch of other things, such as smart proposal, which is a little bit like user operation.

If you have been following ERC 437, I also author a bunch of others like extension.

How do you allow endorsement to be on ERCs?

And how do you allow a jurisdiction to be represented on smart contract, those things?

So I am first and foremost an ERC author and builder.

And at the time I was trying to make sure that I'm following the right path, the right pattern.

People are agreeing or people like those ideas.

It was very hard because many people out there building, not all of them are having an eye on standardization.

The very small group of people who come and go to author it are usually not very, are usually focused on their own proposal.

They didn't get a lot of, didn't put a lot of attention in reviewing others.

So, instead I try to approach people who have massive adoptions of their proposal to come and give us the feedback like William Entrecamp, who was the first author of ERC721 and Fabian, who was the first author of ERC20, right?

And also the ownership standard, the interface standard, ESC 165, things like that.

Make some friends realizing there's value here to give feedback.

And so I decided that, okay, maybe this is the time I can also help others.

Get some reviews, help people, people think it's helpful trying to reach out to me for more feedback and all the way to the point that I feel, okay, I should regularly do this.

And so 1 day when, as I was doing that, I think it was a Panda Pip or Sam Wilson.

Yeah, so they reached out to me and said, hey, maybe you should consider being an editor.

And so that was when I started to become an editor.

But yeah, I still consider myself first and foremost an author and builder trying to promote open interoperability.

Yeah, I think it's quite interesting that you mentioned Because I feel it is it also important that the right set of eyes fall on a particular VIP or ERC and they give you the right comments to make it a successful 1.

People should have technical competency should be should have the right incentive should basically understand what it takes to be a standard.

A lot of them are good engineers who think how to build great infrastructure and products.

But it's a different hat and different skill to propose something to be standardized.

A lot of ways of thinking and compromise you make is different when you build the implementation.

So now let's start to get into the details.

So, so could you please describe to the audience what an

EIPS, and how does that differ from an ERC.

So up until now, by the way, we have the EIP slash ERC coming up.

So that word is going to change meaning a little bit.

But until that final split is done, EIP covers a bunch of categories of proposals.

EIP stands for Ethereum Improvement Proposal.

I'm sure that everyone who listened to this podcast is probably aware of what it stands for.

But the real difficulty, what gets people confused is that ERC stands for Ethereum Request for Comments, first used in ERC-20.

And when I think Fabian, the author of ERC20 coined the name of ERC because it was 1 of the first, or if not the first smog contract standard.

Different from previous ones, ERC doesn't have to be accepted or forked by clients, right?

Currently we have execution layer, we have consensus layer, but whatever it is, it's clients that runs the network of Ethereum.

And ERC doesn't have to be forked and to support.

And so it's more like, hey, we want to do it this way.

If you like, you can do it with us kind of suggestion.

That's why I think Fabian called it request for comments.

Now, when EIP ERC program is evolving, people start to come up with core EIP category, interface EIP category, network EIP category, interface EIP category, and ERC is another category.

And so these are standards track where a different category address a different purpose.

So currently ERC specifically referring to application layer of the theory and proposals.

And in the future, increasing once we have EIP slash ERC splits, people will increasingly starting to use ERCs, EIPs only to refer the non-ERC part of those proposals.

What gets confused is that at certain point during my activity as an author, the EIP editor groups started to enforce a rule to require for the convenience that all ERC to be called EIP, to be cited as EIP in a text.

So everyone who referenced an ERC have to use EIP slash something in their proposal body.

And very recently when we decided to split, there's the new rule is that you have to address ERCs to be ERCs and only address the EIPs as EIPs when they're not ERCs.

So this get people confused, But yeah, don't worry too much about it.

Chances are, if you're not building a client.

If you're not proposing something to go into a client, either by fork, or sometimes not necessarily forking you are forking you are working on the RCS.

So maybe if I were to try to summarize that ERCs are mainly application layer base so so they more or less target like smart contract solidarity API's.

But if you're looking at EIPs, they would be more client-based, which could affect consensus layers or like state growth or something like that.

So for people who aren't following the editing specifically, let's say you're generally an Ethereum builder or follower, typical ERCs are ERC20, ERC721NFT, or ERC4337, contract abstraction.

Typical EIPs are EIP1559, that defines the fees, things like that.

So if you hear about something in the news, it's likely it's very likely that it's an ERC, although there's also your fee.

I think there's also yeah yeah people 844 which is Dan sharding that's coming up.

So now that we have defined these 2 terms, how does an EIP or ERC, What flow does it go through once it's drafted?

So I think I want to also mention, if I may, why ERC matters.

Because I think it's an important thing to talk about.

It's important to know the difference between EIP and ERC.

And you can consider ERC as an optional EIP kind of thing.

But it also matters to know why people build ERC compliant contract EIP, ERC compliant wallets.

I usually direct people to this graph of DeFi Lama.

Currently, there are $38.9 billion of dollars locked in DeFi, mostly powered by ERC20.

So that amount of assets is being supported by ERC20 shows how much impact it has to the industry or to the world.

Having an ERC or conform to an ERC allows the kind of network effect to take place.

For example, in ERC20, you can call a function transfer or send.

But the fact that people can agree upon 1 name allows Wallet to only worry about 1 way to interact with your contract.

And if Wallet are interacting with your contract in the same way, every new contract can be deployed by exposing the same interface.

So that kind of network effect kicks in in the ERC.

So the whole goal for ERC to be open and interoperable is to support this kind of open interoperability and harness the network effect to be even faster to reduce the marginal cost of building new new stuff.

Is it possible for an ERC to be updated once it's finalized so so let's see if you find.

I don't know I want to add a new function.

Can I do that or do I need to go and create a completely new ERC for this?

So on the surface, it is okay that you propose something new.

So let me step back a little bit, when we call something ERC20 or giving an ERC names, there are multiple status, the final status called final.

And in our current rule, final means it's not updatable, you can't update it.

It means it's finalized, people are gonna adopt it, they should not be regularly coming back and check it.

And also a smart contract that is deployed to be conformed with this might not be upgradable or it might not be changeable.

So that's the reason why the current final status for ERCs are a final, and which means immutable.

Regularly you see there are new things that needs to be add to the ERC, but you don't have a good way to point people to the new thing.

And we are trying to introduce mechanisms to do so.

I can give you a few examples where updates would be necessary.

Like in ERC721, there is this very subtle difference between safe transfer versus transfer from.

Safe transfer from allow you to check, mandates the conforming contract to check the recipient, Whether if they are an EOA, it's fine.

But if they're not an EOA, they should be able to respond to you in a certain way so that you know that contract is capable of receiving an NFT and operate it.

Let's say you want to transfer an NFT to a contract wallet.

You want to make sure that contract wallet have no house deal with NFT and be able to transfer it out.

That is because in the ERC 20, that thing doesn't exist.

And people get get get bitten by get hurt by this.

So there were previous effort like ERC 223, which is trying to solve this problem and there's also an ERC 131373 or 1363 I could be getting wrong numbers, But another, there's a bunch of ERCs that's trying to add similar behavior where you can call and make sure that something happens on the other side.

It's very hard to point people to the new behavior.

So there's active discussion in EIP group or it's supersede ability, right?

Next, an ERC can supersede a previous 1, having gotten a consensus.

Some of us support the idea, some of us don't, and all for good reasons.

But I think you create a general concern that is worrying people, right?

And another thing is that a proof is being widely abused in ERC20, right?

So if someone phished the person or compromised the contract being approved for, a user can lost all their fund.

And that is very hard to update in ERC20 as well.

So yes, the problem is currently you can propose a new thing and try to convince other people to adopt the new standard, but there's no good way to let people know there's a recommended way to supersede existing contract.

Cool, So I mean, I can understand it's it is a difficult problem to solve, because on 1 hand, you might end up locking or creating a new issue for the contracts which are on a previous version of the same ERC standard.

But yes, I'd be interested to see how the discussion on this evolves.

were going for was, how does an ERC go from a draft state to a final state.

So actually, moving an ERC from draft to final is not very hard.

What you need to do is you make a GitHub pull requests, and you copy a template, put your whatever you propose there, update it, add the specification, and also open a discussion link, discussion thread on the Ethereum Magician forum.

And then you should be ready to go to draft, right?

A EIP editor or ERC editor has to come over and see if follows the editorial requirements, and to be ready for emerging as a draft.

Step is to move into review when you feel that the stable enough, you want to ask for open active review and then you'll be, you will be soliciting the feedback and actively updating your next version, next snapshot.

In that case, you move to another second state called review, send a pull request, change it to review, approved by an EIP editor, you can be on review, and there's no requirement on time, it takes between draft to review.

And when you are in review, seeing people comment and seeing people getting excitement and feedback and update, for example, you're ready to move to third and second from the last status, which is called last call.

In the last call, your goal is to make sure that people are happy with it and this is ready for adoption.

In 2 weeks, usually the last call deadline is 2 weeks, people, if no new major feedback or no new major updates to your specification, you can move it to final.

And then each step needs to be approved by the editor.

Now 1 thing that people often ask is that, what does it mean, or what, what does it take for something to be called final.

We currently take a very open minded approach.

Basically, you can check in almost anything.

We do have very, very basic sense of worthability or a very, very basic sense of whether it works or not.

You could try to come up with a standard that is almost similar to another 1, but trying to compete with people.

You can also come up with the idea that a lot of people doesn't like.

We don't try to be the judger of who wins.

Being final also doesn't mean adoptions, at least for now.

I am personally trying to promote the idea that we should have some barrier of adoption before something can go to final in ERCs.

But currently, as a group, wearing my EIP ERC editors hat, the policy that we impose is that there's no requirement for a thing to be final.

We do highly suggest that people have clear definition, motivation, clear rationale.

We do strictly require that the specification is clear, not self-contradicting.

We do require proper and sufficient consideration of security to be put in place.

We highly recommend but not requiring reference implementation and test cases to be supplied.

That said, I personally want to promote the idea that you should provide reference implementation if you really want people to adopt you.

That's the only 1, 1 single most important and easy thing for you to do to boost adoption.

On the other hand, test cases is gonna be very, very useful as well.

And therefore a lot of people ask like how many VIP goes to find out how many people, how often, how long does it take to get there.

A easy answer is that it depends like you, the fastest possible way is to make it in within 2 weeks.

That happens when there's very wide massive consensus that this is final this is a stable.

Nothing seems to be important enough to warrant a change to it at this point and yeah let's go get it.

Things like that happens only a couple of times.

For example, ERC 712, an important, it's called EIP 712 but I personally think it's more of light in ERC.

ERC so so he does the IP ERC 712 is a type structure data hashing and signing approach adopted by ethers and master meta mask.

It was in the draft for quite some time several years, The first time it was created in 2017, and it was not finalized for a long time.

But when we realized that, hey, actually the space is in desperate need in finalizing it so that people can proceed implementing it.

We get quite fast a few in a few weeks we move it from draft all the way to final, because there's out there, a lot of adoptions already in certain implementations we just need to finalize it.

On the other hand, there would be adoptions that is fast, that there would be EIP that is fast, finalized, but never adopt, or there would be EIPs that is draft, author forget to come back, doesn't have time to come back, get stagnant, but also widely adopted.

feeling between an EIPS final versus this EIPS legit.

For me personally, I think only adoptions give legitimacy.

Oh and I guess I'm also trying to understand because you mentioned it sometimes it feels like a chicken and egg problem you know who does the adoption come first or does which of these things happen?

If, for example, this EIP you mentioned, which was stagnant or like wasn't moved to final from 2017, what were the reasons why it was left in that state, even though there seemed to be a lot of an option for it.

I guess I'm trying to understand how does an VIP fall out of, you know, the cycle, and what what causes it to do that.

Yeah, I'll give you an example that I recently deal with.

Usually the person who started this thing in CET 2017 are like, they are the OGs, right?

They are OGs, they have good ideas, new ideas, they have important things to do.

So 1 example is that an ERP 1769, or let me just check.

So I was involved, yeah, 1767 was now a stagnant 1.

So there is a, there is a, let me just show the pull request that's easier.

So the other day I was talking, I was thinking of looking into options to generate a graph between ERC people who transfer ERC to each other right.

And I was trying to find out whether there's already a standard or an interface for people to create them in a GraphQL, I realized I stumbled upon this 1.

The author, first author is Nick Johnson.

Do you recognize that name by any chance?

So other than other great things he did he also is the first author and I think 1 of the main builder for this for go east of this interface.

And so he authored this to trying to promote so that other other clients can follow suit as well.

Of course, he's busy, and of course he has other things to do, so he proposed this, doesn't have enough time to follow through, just get left.

And so, These are things when things are adopted, but not being finalized.

In fact, sometimes the reason is also, it was very, very hard and curbsome or even annoyed to update the ERC EIP to the kind of editorial requirements that we do, we impose.

Me speaking from an author have real pain and real personal firsthand experience in facing that.

When I was editing a few ERCs, during the time, a few months, some kind of new rules are imposed by the EIP bot.

And then the snapshot that was previously valid under the Linter rule is no longer valid.

So when I become an editor, I'm trying to advocate against those policies which should make it easier for people to submit, for people to publish, and be less restricted.

But that was 1 of the reasons I see people drop out from from from from from continue editing or authoring their, their, their IP RCS.

And I guess there is no way for the authors to like pass the bait to like a new bunch of authors if they say, you know, someone wants to carry their work on.

There's no good way to ask for help or indicate that if you want to help you could right I know the rule clear enough that I am able to offer that kind of help and Nick says yeah, I don't have time to touch it but if you want to, I'm very happy.

I'm very happy and I will be supporting you to do that.

So yeah, just that we mentioned what kind of key message we wanna say is that, yeah, you can help in any way.

See all Ethereum Cat Herders transcripts on Youtube

Meet The Herders #2: Victor Zhou ERC Editor #ethereum #ERC #EIP #ECH