 And these days we also have executable specs, which are specified in Python. So the core developers are working on, first of all, this specification, if you can look further, it's also all there. So first of all, this specification, then the implementations. The implementations of Ethereum are on two layers and the consensus layer handling the brutal stake, actually the validator said the consensus for the network and the execution layer, which includes executing the transaction, having all the state, all the Ethereum data, all the contracts. And of course, we need to be able to test this. There is a heavy testing infrastructure of various domains, which make sure that these implementations not just work and work together, but also follow the specification. And all of this is kind of led by many, many researchers from all the various organizations who are trying to find the best solutions of the cutting edge issues in the blockchain in Ethereum. On the other hand, when you say Ethereum developer, people mostly imagine people writing in solidity, building on Ethereum itself. So there would be some beach by apps, some NFT projects maybe, or even layer tools or the infrastructure, like maybe some blog explorers or stuff like this, which is built on top of the Ethereum. So to give you the idea of what numbers we are working with here, the core developers of Ethereum are in, we would be here in low hundreds, like 100, 200 people in the protocol guild, which is an organization. It's an original magical list, which is including all, like it's up to an list for core contributors to be able to have some sort of funding. There is under 28 people, but again, it's up to 10. So there is not all of them. Most of the people from protocol guild or from the core community is on this picture we met in Austria on January. So you can see that it's a wonderful group of people, yeah. But it's of all of them, of course, the projects in the core ecosystem are very wide. There are many different domains. There are not just the clients, but there's always some library or some piece of tooling, which somebody maintains somewhere. This aggregator is pulling various repositories and identifies over 200, sometimes up to 300 contributors to these various repositories. Again, they don't list specifically which ones, so I would guess that it might be even more. However, if we compare this number to actual web-to-developers, we see a big difference. So the web-to-devs are people building on Ethereum, using the Ethereum technology, but not contributing to the Ethereum itself. And Ethereum is leading in the number of these web-to-devs, the dev-developers. There is, well, let's say, at least 20 times more than the core contributors. So it's a big difference. And yeah, the main difference here is that the app developers are working on the high layer, basically. It's the smart contract layer using something or Viper or Fee or maybe some, these days, whatever compiles to EVM like some Cairo, building the different applications, the things that users actually use. And building these, the developers are responsible for how the app behaves and the security of the user response or the security of the user data is their responsibility, the responsibility of the app they are using. It's also competitive environment. Many Ethereum, many protocols in Ethereum are maybe some public use, but a lot of them are businesses or even DAOS, which have some profit incentives. So they tend to be rather market-driven. And yeah, they're building kind of offensive cars or the standard people use because what the core devs build is the road. It's the actual platform that they are building on, right? So to build the actual platform, to build Ethereum itself, we need lower-level languages. We need the languages which allow us some software architecture, which is mostly Go or REST or C++, Java, even TypeScript, or maybe NIM. So these languages which allow us to build efficient and secure software. And this is how the consensus, the execution clients are implemented. The work done there is still maintaining them, upgrading them, optimizing them, and most importantly, upgrading them for the newest EIPs. And if you think about it this way, the core developers or the people working on the clients themselves are responsible for security of all of the users of Ethereum, not just a single app. So it bears certain commitments that they're responsible, I would say. But this way we have all the robust testing and cooperative community for it. So when I say that it's cooperative, it's very unique because compared to the market-driven economy of companies building something else or the core developers are directly collaborating. So people from different teams, different companies come together to build the things together to make sure that it works and it's all properly specified in Ethereum. Yeah, so it's more ethos-driven. And yeah, so why is it important? Yeah, why is it important? Why maybe some web-tree devs here or other kind of developers or technical people might be interested into the core development? And it was mostly mentioned here. It's the development of the clients themselves or the implementations with Ethereum that actually nodes running the network. If you ask, what is Ethereum? I like, that does the thing with the blockchain, right? You can send a tank to a bank because bank has the building Ethereum will never have that because it's thousands of computers running this very software all over the world and each little computer is running the code that you can contribute to. And yeah, so the contributions by directly contributing or testing upgrades maybe benchmarking and generally improving Ethereum by researching some complex problems. So I would say that without the core devs Ethereum wouldn't be here. I mean, it's kind of obvious. Like if we wanted, we need to build it kind of a democracy approach, but all the work done on launching the Ethereum on the frontier, the homestead, all the upgrades till now, till the merge, Chappelle, it's all was done by these good contributors. And of course there are different people before the now but they come and go, some stay. They're all working towards the same vision. So we say that Ethereum is sort of an infinite garden. It's a game that we don't play for winning but for playing. It's a garden that we will have to improve and trim here and there. And I see it as a, it really comes from the, comes from the free software movement and the central punk culture of the people who are trying to build this distributed and free software, which allows us the coordination and it's the vision that people follow here rather than just some market incentives. That's what makes the core open unique to me. And when I talk about the complex and interesting problems, that's another reason why I see people around me working on the core development because it's not just some shared vision but it's very interesting problems. It's, if you like to solve problems, there is a lot of them to do. So this was around the merge and sure if it was before or after the merge and tell it to say and Ethereum is still only about 55% finished. There is a lot of boxes to fill as you can see in the roadmap. Each in different domains of Ethereum, different parts of the computer science to tackle here and to work on. So it can be also very open and creative like basically whatever problematics you get interested in and you want to get into, it's your opportunity to just come and learn and contribute. Yeah. And yeah, so it's all of this research because of various issues that need to be solved in Ethereum but generally what you know about is the scalability through a lot of blockchain through a lot and all of these people have been putting very hard work to researching potential solutions which can keep the network as decentralized as secure as possible while achieving some scalability. That's these are really the cutting edge solutions to the blockchain technology that we have and like the probably the biggest example of a huge collaboration of people completely open collaboration of people distributed all around the world which was successfully done as this lovely transition to the merge, right? So the merge happened in September 15 last year and it was just incredible to watch how people, each everybody doing their own thing but contribute to the higher goal, right? And yeah, this is what these people are doing and I think this is the last slide before Josh takes over because Josh will actually explain you how can you become one of these contributors and work on all the interesting stuff that I mentioned. Awesome, thank you Mario. Yeah, so the Ethereum Protocol Fellowship as Tim mentioned earlier is a program that's designed to make the process become in a core developer researcher or contributor easier, clearing the path forward so that there are the least amount of roadblocks and you can spend some dedicated time learning and applying any of the things that you learn towards becoming a contributor to the Ethereum Core Protocols. A little brief history of the EPF it was originally a program started by an early core developer Piper Miriam. It was called the Core Developer Apprentice Program and his idea was to find developers that were going to be able to help him work on a project that he started called the Portal Network. He hosted two cohorts originally to do that and then passed the program off to the Foundation Protocol Support Team to host the program in sort of a wider sort of manner. So it is coordinated and funded by the Ethereum Foundation. The design of the program is meant to mimic the core developer experience. So it's a largely self-directed program. You're able to choose what you get to work on. It's the main mode of communication to the greater world is through different technical updates and it's really meant to help you allow you to figure out how to find your way in this ecosystem through your own research but also through accessing in the developer community asking help and gathering guidance from mentors and the Ethereum Core Developer Community. It is coordinated majorly through a GitHub repository and as well as a Discord channel within the ETH R&D Discord. And then we do host a couple of weekly meetings each week to have some face-to-face time. It is a permissionless program which means that anybody is welcome to join the program and will have more or less the same resources that somebody who is officially accepted into the program. So we do encourage people to participate permissionlessly. Our application review processes by no means perfected and we're human and we make mistakes when it comes to applications. So we invite people who maybe don't get selected to be a part of the program to prove us wrong and show us why you should maybe be a part of the official cohort, receive funding, that sort of thing. So some of the benefits of the protocol fellowship, as I mentioned, you get to work closely with the existing core developer community. It is a semi-structured process. So we do have some structure in place to keep people accountable and allow you to have some feeling about what it is that you should be doing through this four month program to help you along in your path there. You get to work on what you're passionate about. So the problems that you're interested in, the areas of the core protocol or of computer science generally that you like to work on and you like to research and that you feel passionate about are the things that you get to work on. There's also the mentorship aspect which allows you to have access to the people who are already working on the core protocols, the people who might have answers to your questions or able to point you in the direction that you need to be going to solve a problem that you're not really sure how to solve. There is a financial stipend that is associated with the people who are officially accepted into the program and we do keep aside a portion of that stipend budget for those people who participate in a permissionless manner that are doing good work throughout the program. And then you also, yeah, you get the experience of what it's like to contribute to an open source software project like Ethereum. We finished up the third cohort in February 2023 and it's a four month program. We had over 600 applications for that program. We conducted 40 interviews. There were 24 official accepted applications. We ended up having about 36 people participate in the program, so 12 people participating permissionlessly. And then I believe five of them ended up becoming sort of official fellows through the permissionless track of that program. They worked on 20 different projects with 27 different mentors. And yeah, the fellows created 300 different development updates. As of, I believe, two months ago, 40% of the fellows that were in cohort three have some sort of placement within a client team, within a research team have been granted in some way to work on a project that they were excited about working on. I'm not gonna go over each of these different projects but these are some of the projects that fellows worked on in cohort three. And I did highlight one that after the cohort was over, one of our fellows that was working on the deter attack defense, the Geth client had that sort of DOS attack happen very shortly after the program was over and the work that that fellow had done on this attack defense came in very handy during that portion of time. So how does the program work? Well, here is a brief timeline of the process. So there are three different phases of the program. The first phase is what we call an onboarding phase and it lasts for a couple of weeks. This will be time for you to meet the different fellows in the cohort, get to know more about the program and the expectations that are set for the program and for you to take some time to get a brief overview of the current landscape of the Ethereum protocol and the current set of problems that are being worked on. We do have a list that is kind of ongoing different projects that our mentors and other people from the developer community are hoping to see worked on or would like somebody to work on potentially if you're maybe struggling to find a project to work on. And then so yeah, once you've done that sort of cursory overview of the problem scape, you will go into phase two, which is the learning and project selection phase. This is where you'll do a deep dive into that particular issue that you're looking into or the project that you'd like to work on, really getting to know the different nuances of that project. Then you'll start to create a project proposal. This would be probably similar to what it's like to create an EIP or some other kind of proposal for upgrading or creating something within the core protocols. And then you'll get feedback on that project proposal and the project in general and iterate on it. And then we do a, I think it's over two weeks, we do project proposal presentations where you will spend five to 10 minutes giving a presentation on your project why you think it's important and how you're going to tackle it. And then the majority of the time in the fellowship is the project execution phase where you're actually working on your project, getting feedback and assistance from your mentors and fellow fellows in the cohort. We'll host these weekly standup meetings where you will give sort of a brief overview of your progress through the week, be able to ask questions of the fellows and maybe have, you know, Mario and I point you in directions of people to talk to if you're struggling with a certain roadblock of some kind. And then towards the end of that third phase, you'll do a project report where you, you know, it's a written report where you, you know, sort of give an overview of your time in the project as well as like, you know, the different things that you struggled with, the different avenues that you took in order to solve the problems that you were having and just generally how the project turned out where it is currently, if it's complete or not, that sort of thing. And then this cohort will end with an in-person meeting at DeafConnect in Istanbul. So this will be a time where fellows will get to meet, face-to-face, have some time to chat about their time in the fellowship and also give some in-person project presentation. So what it might be like to, you know, speak at a conference on what you're working on or, you know, just generally give you some more sort of public speaking opportunity so that you can verbalize your thoughts to others that are working on similar things. So if you are interested in joining the Ethereum Protocol Fellowship, the fourth cohort, we encourage you to apply. Successful candidates will have strong written and verbal communication skills. The majority of this program is, you know, done remotely. So it's important that you're able to speak about the project that you're working on and just about the technical aspects in general. You'll also be writing weekly or bi-weekly updates about what you're working on. So being able to write about what you're working on as well is definitely a handy skill to have. It's important that you're self-directed and self-motivated. Again, this program is not designed to hold your hand but it's designed to, you know, mimic what it's like to actually be a core developer, somebody who's, you know, typically working remotely and, you know, needs to have some aspect of self-motivation. It is important to have somewhat of a technical foundation to be able to write some code, be interested in low-level architecture and also having a passion for Ethereum and for decentralized technology in general is also a very important aspect of this program. So when writing your application, it's very good to have well-written answers in your application. We encourage you to put some thought and some effort into the application answers and would discourage you from using chat GPT or other AI tools to write those responses within the application. It's important to have an active hub account of some kind. We definitely understand that not everybody has the opportunity to, you know, work on open-source projects all of the time or maybe, you know, the work that they do is not able to be shared. So it's certainly understandable if you don't have a super active hub account, but when you are submitting your application, it would be important for you to sort of explain what sorts of projects you have worked on in the past and why they aren't necessarily able to be shared. Making open-source contributions to either issues and things within Ethereum ecosystem or generally other open-source software platforms is great. Having some low-level language proficiency, things like Rust and C++ and Java and all of these sorts of things, it's great to mention that in your application. And if you've done any kind of, you know, protocol work, peer-to-peer work, things like that. So the application period is open until June 16th. The program will begin in mid-July and it will run through mid-November. And as I mentioned before, it will culminate in EPF day at DevConnect in Istanbul. Yeah. So these are a couple of QR codes for you to scan if you so desire. One is to the Google group where we do some very high-level communications talking about ways to participate permissionlessly or just announcements about different cohorts. And the other is the GitHub repo for the third cohort. We do have another repo for the fourth cohort which should be open at this point and we'll throw a link to that in the chat if it is still legible. So thank you for listening to this presentation and for joining us on this town hall meeting. We're gonna open it up for questions and we'll see how this process goes with the issues that we were having earlier. Hopefully it will be great. So if you have questions, feel free to post them. Oh my God, there's so many things. Yeah, maybe I can run through what's already been shared in the chat. Cool. Yeah, so first of all, yeah, people are asking for the slides, we can post those there as well. First question was out of the 36 participants last time, how many became core devs? Yeah, so as of I believe a month and a half ago about 40% of them have been placed in some way shape or form. So that could mean that they received a grant through the Ethereum support program that they were hired by a client team, that they were hired by the Ethereum Foundation, the research wing of the EF. So there's a lot of different sorts of ways that you can become a core dev. So, but 40% of them currently are working full-time on core development projects. I guess, yeah, go ahead. I would just to note that like the 20 projects which has been delivered, like all of them were meaningful contributions. So like one thing is being actually employed somewhere, we're getting a grant, but like even the work within the EPF was the actual contribution that people did. And to me, I would say that they already became a core dev or core contributions. And the placement rate, like what we talked about here, about 40% also important to note that some of those people just decided to work on something else or maybe finish the school before joining some teams. So I would say that it's really up to you like it's these projects can easily prove your skill and then it's pretty, it's relatively easy to get hired wherever the help is needed. Awesome. Okay, so the second question is the fellowship only for coders. It is mainly geared towards people who can write code. It doesn't necessarily mean you need to be able to write like production ready code, although that is definitely helpful. We do have a lot of people from the last cohort who were more on the research side of things. And so interested in researching the different things, but it is handy to be able to be able to express your thoughts in code. Or Tim, yeah. I was just gonna say, so like, yeah, it's important. I think to keep the program focused on actual core, protocol development and client development. And the EF does a bunch of other grants rounds for like different research areas, everything from like, you know, social science to like math or, you know, more like abstract technical research. So I think for this program, like being comfortable with the Ethereum network and its implementations, like as a live thing is probably the main thing. And, you know, a lot of this is obviously software engineering, but like we mentioned, like the example from the presentation, you know, around the Get the Mempool DOS protection. That's something that started much more on the research side and then they work with the Get team on like implementing a fix. So like there's probably some branches of research where it's like very applied, you know, to things like whether it's like networking, you know, DOS and things like that. But if you're completely outside of those domains, then there's probably other grants rounds from the EF that are better fits than EPF. Mary, I don't know if there's anything else you want to add. I just wanted to mention that I would really recommend to check the past project. So we have the lovely recap blog that was mentioned on the blog of the Ethereum org next to the application so that you can find also there is a link in the blog post to the blog, which is explaining the previous cohort and all of the projects are linked there. Also in the repo from the last cohort, you can see all the work which has been done by the fellows and the projects, you can get an overview that like most of them is some development work. Some of them are also just like, you know, data analytics or building tools which enable some more clear data. Or actually there was also to work on the MEV, some sort of crypto economics implemented in the open games engines. And if you're interested in game theory, there is also some logic to apply in the research there. But this is different from the minority of the program and the most of the projects, yeah. Awesome. Okay, next question was, what's the monthly stipend if you're acceptable? So we do stipends based on needs basically. So we ask you to calculate your monthly burn rate, the amount of money that it takes for you to live basically for a month, things like food rent and basic life necessities. And then that's sort of the number that we would ask for in terms of what you would receive for a stipend. So the program isn't meant to give you like a developer's salary per se, but it is meant to allow you to spend the four months focusing on the project and not have to worry about the things that you would need to survive. Okay, next up, I'll try to run through this because it's more and more. On what basis are the applications accepted and how much are you expected to know about core development? So the second question is sort of touched on a bit, but maybe the first part of the question, like what are the things we look at for good applications and help us make a decision? Yeah, so things that we look at, we definitely look at GitHub profiles a lot. We'll look at the repositories that you've contributed to the different things that you've been working on within the GitHub. We definitely read all of your answers to the different questions. This particular cohort, we've added a new question into the application, which is asking applicants to describe some kind of technical concept, either in a video or in an essay format. So giving some idea to us as to where your technical knowledge is at. Additionally, just describing different projects that you've worked on, giving us some kind of brief resume-like idea of your skills and the languages you work with and the things that you're interested in, as well as just having an interest in Ethereum itself, we definitely highly rate the passion that people have for working on these kinds of projects. But I don't think that there's any hard and fast boxes that we have to check in order to say that somebody is worthy of having an interview or whatever. So, yeah, there's not like a thing that I can say that this will definitely get you into the program. Okay, if you can help me, I'll bring it up a little. Just, yeah, everything that Josh said, like we're looking to see that technical insight, insight into Ethereum, but then we invite people for the interviews. So we will have interview with a subset of people that we decided we will get to know more there. And the thing is that if we have these applications here and you can apply even, but the thing is that the program still stays open and permissionless. So the idea is that even if you don't get accepted or even if you don't apply, you can still just come and contribute. And from the past cohort, we learned that there've been people that we did not accept or maybe didn't apply and just show up to do work. And after a month or two, we see that they're doing a great job and they deserve the stipend. So we offered it also respectively. So like, if you don't get accepted, you can prove us wrong just by coming in and showing the skill, yeah. Yeah, like I just said. Okay. Sorry, I'm going back and forth in the chat here. Okay, so this- There's a question around the, good. I was gonna say, the next one is like, do mentors ever become overwhelmed by having so many people in the program? We didn't necessarily experience that per se. We do ask fellows to really make an effort to try to solve the problems on their own before they reach out to mentors doing a lot of their own research. And if they do have to reach out to mentors for something that they can't figure out to really have a directed question or ask of the mentor so that there isn't a ton of time spent on the back and forth communication around what it is that you're actually trying to figure out. So we didn't, yeah, I wouldn't say that mentors got overwhelmed. And I think that a lot of the mentors are understanding that this is helping to bring in the next crop of developers so that their plates are generally not as full. So yeah, I think the majority of them are happy to help. Awesome. I would just add quickly that there is, you can actually find the list of potentially available mentors. Like they're available just, you know, their things might change, but you can see that there are people covering almost all the core teams. So also what we encourage and protocol is to, and the protocol fellowship is to identify the project that you're trying to work on, but also check with the peers, check with the others. Maybe you can collaborate with somebody on the same project with one team and it helps not to get the mentors overwhelmed like to actually distribute the projects around the various teams. And yeah, so we don't end up with many falls working with one mentor because it won't be possible. Okay. Next up, what's the required time commitment for EPF? We don't have a specific time requirement. You know, in the application, we do ask the amount of time that you would be able to dedicate to the EPF during the four months. We do think that if you're able to, you know, spend only 20 hours or less on the program per week, that it might not be the right fit. You know, that's certainly again, not a rule by any means, more of a guideline to go by. So if you already have a full-time job and, you know, a family and you have a lot of other sorts of obligations that you have to take care of in your life, it may not be the right fit for you, but also, you know, if you're somebody who also likes to stay up all night working on passion projects, then, you know, certainly feel free to apply. It's not something that we, it's sort of much lower on the list of things that we take into consideration. And I would say maybe I'll add something to that. There's like, the reason why time commitments is so hard is because at the end of the day, quality is what matters more than quantity and people have like very different, like outputs based on time. So if we said like, oh, it has to be 20 hours and then, I don't know, somebody who can actually do great things in 10 hours a week feels like they can't join, that's bad. But like, you should expect during the program to make like a meaningful contribution to something like one of the projects that's listed there. So if you like read through the list and you know, you think that's the type of thing you can tackle in like four months, then yeah, that's pretty much the bar we're going for. And related to that next question, is it okay to express an interest in more than one project in the applications? Yeah, certainly that is certainly a possibility. You know, we wanna hear about all of the different things that you're excited about within the protocol development world. And yeah, you can express interest in all those different things. And, you know, in phase one of the program, the idea is that you're, you know, able to do a very high level overview of the different sort of things that are happening in those different spaces. But then, you know, once you kind of hit phase two where you have to choose a project, you know, we will ask that you choose a project to focus your time on. That doesn't necessarily mean that you can't spend time working on other things, but we would want you to focus mainly on one project. I mean, if you feel like maybe doing two smaller projects, if you feel like you are Superman and you can do two things in four months, I mean, I believe like the program is opened and like it's completely directed by you what you do. So for free, if you feel like it, I wouldn't recommend it in general, like one thing and perfect, right? But we also saw people think after a month of the researching one topic they decided they have to work on something else. So the actual deep dive in the first weeks of the program should be the real time when you decide on which one to finally work on. Awesome, the question by Amora about, can we say more about participating in the research capacity? What's the example of a topic that a participant might research? Yeah, go ahead, Mario. So there is a lot of research going on in the Curium ecosystem. So I would check out the project ideas. There are also some research, you know, less development things mentioned. One of the things I mentioned before is more of the crypto economics topic, topics handled by the Rick, or was this Google research, which has, it's linked in the project ideas. It's the Rick open problems, open questions. You can find some of the research that are interested in there. It might be like the cutting edge, the current stuff happening. So right now there is the development rate for four, which still might require some maybe some benchmarking, some, you know, more of a applied research, and then more theoretical topics which are still far ahead, but are very interesting and need to be figured out, such as single-slip finality, maybe data available to something. One of the fellows from the previous cohort was working on data available to sampling research. And so the research being also, if you're not aware of the ETH research website, it's a great way where to, for an overview of what's happening in the ecosystem, it's making this a good link, it's ETH research. I'll maybe add to that one type of research that like, I feel we never get enough great people working on is things like simulations and like, basically, yeah, almost more like experiment, like very hands-on research. And like one example I can give, this is not EPS, they were gonna call about this right before, is like for bank sharding, figuring out how many blobs are we gonna have in bank sharding, right? And then running things like network simulations or, and this is a mix of like, you can take a more theoretical approach, you can take a more like sort of simulation and like software approach, but things around that like changing the, some properties of the network or like, changing the topology of the network, things like that. And like understanding that a bit better is something where like, we could have way more like smart researchers who aren't necessarily like engineers in that like they're writing code for core devs, for like core clients, but like are able to use code and like a bit more of like a research and experimental mindset to like, figure out what the right limits for a bunch of parameters on Ethereum are and, you know, are there, are there like things we can improve? That's like a huge, I think area that almost falls like between research and engineering. So like not a lot of people end up there, but I think there's a ton of valuable work to do out there. Okay, so there's another question. Can people who already work on client teams apply? I guess you can apply. I think in terms, so in terms of prioritizing who we give a stipend to, you know, we'd probably prioritize by default, someone who's not already on a client team to try and get them possibly on a client team. That said, you know, if there's an exception, why like it would make sense for you to get a stipend even though you're already on a client team, we can definitely consider it. Yeah, so there's no, like there's no, there's no kind of rule against it, but I would just, if you're especially looking for the stipend, I would try to explain why, you know, you being on a client team already does not like, isn't like working or what not. If you want to apply as a permissionless participant, you know, imagine you're on NetherMind and you want to spend a couple of months hacking your life house and you don't need a stipend to do it, then I'm sure there is no blocker to do that. Yeah. Okay, next question. Is it expected to work alone or can multiple people work together? Definitely multiple people can work together. We had two different projects that had multiple people that were working on them in the last cohort and it worked out really well. So, you know, they were definitely bigger projects. So it was, you know, it was helpful to have a few different people working on them and collaborating together. Yeah, again, it's totally up to you folks like whether you feel like to clean it alone or working in a team, if you're able to find some peers here who are interested in the same topic, it'll be great. What do we notice is that it actually works pretty well when people are just a two person team, but it still works nice in a way that people, it's easier to brainstorm for them. It's easier to solve some issues in a way that they can just, you know, talk to each other first before going to the mentor and have somebody to discuss directly with. So I would encourage to also chat on these calls more and find people to work with. How many permissionless fellows ended up receiving funding during the program? And maybe there was another question about like when permissionless fellows would like be selected to get funding. So can you maybe just talk a bit more of like how we approach giving money to permissionless participants? Yeah, so generally last cover, I believe, by people ended up receiving funding after the fact as a permissionless participant. What we look for in permissionless participation is, you know, consistency, like really being consistent with your development updates and showing that you are working towards a goal and that you are actively making progress on that particular goal, showing up to the office hours meetings and participating in that way is also a high signal for potentially gaining funding as a permissionless participant. There's no, again, hard and fast kind of rule around what you have to do. It's more about, you know, if you're making meaningful contributions, if it looks like you're actively participating in a way that is going to benefit the protocol at the end of the day, then that's kind of what we're looking for. Awesome. Okay, so there's a question. What if I only know high-level languages like TypeScript and Solidity? Do I need to wait until I understand Go before I apply? I don't, yeah. I don't think you need to wait to necessarily apply. We did have, you know, multiple fellows in the past cohort that were, you know, did need to learn new languages and did learn new languages during their time in the fellowship. I think it's more important that you feel comfortable, you know, with your ability to learn new languages quickly and being able to implement those things pretty quickly. So it's not important that you do need, that you do know those things, but that you're able to learn them quickly. Mario? Yeah, just wanting to mention it again, it's totally up to you in a way that depends on which one to contribute to. So like for kind of front-end web-tree devs, there might be some browser-based tooling or this kind of stuff which is needed. One of the proposed projects, you can see like a DevOps wish list from Pari, you know, certain monitoring nodes or the network is definitely needed and it's also like a front-end work which is important. But I would be excited, there is also a host star which is a whole costus client documentation written in TypeScript. So if you are skilled in TypeScript, maybe Java script and interested more into like evolving your skills towards the architecture, towards the clients, it's a great way to learn. And yeah, what Josh said, it's a great opportunity to maybe learn a new language that you wanted to learn. There was even a guy who was like a non-coder, like light Python skills and he ended up contributing to Rust projects in a few months. If you are educated, I believe anything is possible. And no, there is one client in JavaScript. So there is a Theorem.js. So if it's like actually the programming language and TypeScript is not exactly JavaScript, but like pretty close. Yeah, if that's like the main blocker, you can probably still do some protocol work through a Theorem.js. Okay, so there's a question about the interview. So what's the interview format like for applications that stood out? Yeah, so Mario and I will hop on Jitsi or Google Meet or some other sort of video conferencing and we'll spend a half an hour chatting about what your goals are for participating in the program, what your greater goals are for development in general, get to know your skills a little bit more, get to know some of the projects that you've worked on in the past and just kind of get to know you a little bit better. We can only gather so much information from written applications. So it would just be, yeah, some time to chat and get to know you better and see if it seems like an appropriate fit. Awesome, there's a quick question. Is the application form editable once you send a submission? It is not editable. So if you do feel like you need to send some kind of addendum to your application, you can send me an email or a message through the Discord Protocol Fellowship Channel and the ETH R&D Discord. Also, my email is josh.davis at ethereum.org. We'll add it in the chat here if you do have already submitted an application and would like to make an addendum. Awesome, okay, so there's like three questions that are all related that I think I can take. So just Sirk asked, can we put an existing technical writeup where we ask to write about technical topic? Roy asked me a question between two different things that I answered in the chat. And then Manav just asked whether it's best to speak about like a generic topic like if they're a Miracle Patricia tree or something that you worked on in general. So I'd say that the reason for this question, like why is there any application, is to understand like whether someone can like coherently speak about a technical topic that's like, you know, if not directly related to the Ethereum protocol, like of the same complexity or like, you know, the same types of domains rather than just saying a bunch of buzzwords and like not being able to like actually explain the thing that they do. So if you have like a really strong technical writeup that you've done on something previous, that's like, you know, even if it's not like a blockchain or an Ethereum thing, but it's like some, I don't know, like API design or, you know, like networking specification or like something like that. Like I'd say that that's great. I would just say if the thing is just very far away from Ethereum, like I don't know, like I'm trying to think of an example of something like say imagine like UX, right? Like which like doing like UX for like a consumer app which is very different than like client work. Then that's probably less good. But if it's like some other like code project that you've done that has like a really high quality writeup then like that's great, you can share that. And I think in general, it's probably better to speak. Yeah, I'd say if it's an application is I would, if it's an application and the writeup focuses on what's like technically novel about it, then that's really good. So like an example would be like, an example of something bad would be like, imagine you just go to like, I don't know, ethereum.org you take the first tutorial. I don't even know what it is, but imagine it's like deploying your own NFT contract and just like copy pasting like the instructions to deploy your own NFT contract. I'd say that's like less valuable than say you actually wrote the contract or wrote the architecture like for a full application and there's something technically novel or interesting there and the writeup focuses on that. I'd say that's super relevant, right? And like one actually one good example. So on ethereum.org there's like a breakdown of like how Uniswap V2 the contract works. And they, that would be the type of thing that like, it doesn't have to be as polished as that. It's obviously like meant for like a super broad audience, but like that sort of goes over the uni V2 contract and explains like what this thing actually does, why it's set up this way, what's like the sort of supply demand care and all of that. I saw that stuff is super relevant. And in general, I think if you can talk about something you've done, like actually done, that's a better signal for us than talking about like something you want to do or just something that you know. So like if you have say, you know, a project you've done that's not quite about ethereum protocol stuff, but it is, you know, technically interesting and novel, I would focus on that. And like as like, I don't know, number one thing, I'd say if you don't have that, then like just talking about either a project that you're interested in or like that, you know, like some topic like Merkel-Patricia trees, like if you want to do a short write up on that, I'd say that's good because it shows like you can understand a list of projects there and a list of like, you know, topics that we discuss. Yeah. And then there's the last question, can you do more than one write up? I'd say if you submit more than one thing, the amount of time people will spend reviewing it probably won't go up. So like, you know, if you think that like skimming two things is more valuable than like reading one fully like the four molds stop you, but if you submit 10 different things, people are not gonna spend 10 times more effort on your application. I don't know, Josh Miro, anything to add on that? Yeah, I think that's definitely accurate. You know, we do get a high number of applications. So the time that we can spend on each one is somewhat limited. So I would suggest choosing the one that you feel like is most appropriate and submitting that one. But again, the form will not stop you from submitting multiple. And just to kind of piggyback on the last things that you were saying, Tim, we have had like a number of people submitting applications that are basically giving like a walkthrough of their, you know, DAP that they've developed in a much more kind of like product pitch kind of manner. And, you know, that's really not what we're looking for. We're really looking for you to like get into the nitty gritty of like how you made the thing and what the novel pieces are of it. And so, yeah, like your elevator pitch for your DAP is not really what we're looking for in the... Yeah, and I guess related to that's a really good point that Lorenzo has a similar question. Do you actually have to go into the code? I don't think you necessarily have to, but I'd say maybe the... If like pitching this to an investor is like the wrong approach, the better approach would be, imagine you have a new coworker or colleague that's coming to work on your thing, right? And you're like explaining them, it's like their first day and like you have like 15 minutes with them to explain to them the thing. So like, you don't necessarily have to go into like, here's what every line of code does, but like, you know, help them make sense of like the technical thing you're describing. That's like the level that we're at. So that, and again, like the use case for this is like, imagine you get on a call with someone, you know, with a client team, like, you know, can you like show them the thing you've been working on their EPF and like explain to them what it does in like a coherent way. So I'd say this is like the audience you should like aim this for. And if the best way for you to do this is to like walk through line by line, here's like a hundred lines of code, you know, first function does this, first second function does this, that's fine. If the way that's best for you to do it is to like actually have like diagrams and like a high level, you know, architecture overview, that's fine as well. If it's really just like writing words and like there's no code in it, that's fine too. But I'd say this is like the framework or like the mindset you should be in is like you're explaining this to like a smart new collaborator on your project. And you're not trying to like sell it to them but you're trying like to get them to understand how it works. Hopefully this answers your question as well Lorenzo. There's a question, is there a specific set of EIPs the application focuses on? There's not necessarily a specific set of EIPs. As Mario mentioned in the repo there is a list of projects that mentors have suggested that people can choose to work on or not. Again, the program is designed to allow you to work on what you feel passionate about and what the areas of the protocol that you're excited about. So we don't necessarily pigeonhole it to any sort of list of EIPs but if you are sort of struggling to come up with a particular area of interest or something to work on this link that Mario just put in the chat is a good place to start in the terms of sort of the immediate things that people are hoping to see done in the near future. Okay, there's another question about permissionless versus permission participants. So do an unaccepted or permissionless participants still get access to mentors and other tools that accepted participants get? Yeah, so permissionless participants do get the same access to all of those resources that somebody who is officially accepted into the program. The main difference between a permissionless participant and an officially accepted participant is that you don't have the stipend right off the bat that you kind of have to prove to us that the work that you're doing is worth funding and that you're dedicated to participating in the program. Just to say a little more about the mentorship, it works in a way that it's not like direct guidance, hand holding kind of thing but more of a asynchronous feedback provided by the mentors. So again, it's up to you to reach out to the mentor. They're available in the communication channels that you use and you can reach out with more of a specific question with a pitch to you should demonstrate it. You have the insight, you did your research and then when you get stuck somewhere there is a mentor to help you. Most importantly, it's the collaborative work when you are opening some poor requests and you get the review to discuss the problems there, right? So it gets, over time it gets more into the PRs into like the review kind of code review kind of work but generally like the mentorship should be approached with again some self-directed responsible to bearing away where you try to find the answer to your question first if you're going to the mentor and if the mentors might get over helmed and in case there are too many permissions participants it's again, it's not our policy or anything but the mentors end up prioritizing the people who stipend. Or at least we saw that before because for some of the mentors it was like too big interest to work with them even though they try to respond to everyone. And one thing I'll emphasize that you both mentioned is like the idea of like reaching out to the specific question. So like in general, like even outside of EPF, right? All of these people who work on Ethereum like tend to be pretty responsive if you actually like have a question that's like not just the highest level like I don't know what's thanksharing or how can I help with thanksharing? But like if you like are reading the spec and you're like, I don't understand why there's this thing online 68 or that type of thing like generally just posting that in the R&D Discord people will respond to it because like there's a lot of like noise at the like what's thanksharing level of the conversation and sometimes people have to like manage the inbound messages they get like however works for them but there's not a ton of like noise or competition at the level of like, I've read this thing and I don't understand like this subset of it and how it works in relation to all of that. So like if you're able to do that and just sort of get past like the first level of like actually trying to read through the thing understand how it works like highlight the parts that are unclear or like count an intuitive to you and then potentially just like I would search the R&D Discord to see if someone has had the same question as you or like search each research. If you've done like that level of diligence and you still have a question then the odds are you've probably hit something that actually is unclear or under specified or like an area of like discussion or research and then people are usually pretty excited to engage because like that's literally what we're looking for is like contributors who can help with all of these things. Yeah, so there's a ton of value in doing that and if you've done like a relative amount of work and you still feel confused then the odds are it's like the thing that's confusing and not you that stupid. Yeah, yeah, people will usually be quite responsive to that. Okay, I think we had most questions. Let me see if there's anything left. Yeah, I think those were all the questions. Any final questions or things that we missed in the chat feel free to repost in the Zoom chat and we can get it for you up up. Okay, well, thanks everyone for coming. Apologies again for the disruption at the start. And yeah, hope to see you all on the R&D Discord.