DIP Box: A New Era for Blockchain Governance

Ecosystem Project Demo (EPD) · 25 Sept 2025 · 1:01:58

Tim Pechersky introduces DIP Box, a platform meant to streamline how improvement proposals move from idea to decision. With Pooja Ranjan he discusses the pain points of the EIP process, centralization risks inside Ethereum, and the roadmap for more transparent, community-driven governance.

Speakers

Topics

From Ecosystem Project Demo (EPD), hosted by ECH Institute.

Transcript

It really changed some environments  and expectations of how the the theorem operates. Our goal and what we are trying  to propose here is that standards can be developed faster. We are much more accurate  about what is actually important to prioritize by giving community and basically protocol  users and customers to give us a development of the protocol. If you're using Ethereum,  if you're a customer and this is very like product mindset which I think in Ethereum  generally was missing because [Music] Improvement proposals are an integral part of  continuous evolution of any ecosystem. They hold special significance in Ethereum ecosystem  and I have been a strong advocate for process

improvement and for promoting any tool that brings  these benefits to the community. That already gives away today's theme because we are going to  talk about a project that is very similar to this. Welcome to ecosystem project demo episode  25 brought to you by ECH institute. I'm Pooja Ranjan joined by Akash and Vaelyn from  our team. Today we have a very special guest and with us Tim also known as Peersky the founder of  Pyramid Labs. He will be sharing about his project DIP.box. Welcome to EPD Tim. Hi everyone. Well  we understand DIP.box is an aggregated datadriven view of the activity contribution and health  across major blockchain ecosystem. I'm looking

forward to learn more about the project. But  before we go in there for our listeners, Tim, could you please share a bit about your journey in  the web3 space especially in Ethereum. All right, Pooja, thanks for the intro and thanks for giving  the opportunity to speak up today here. I joined Ethereum I think around 2020 and I got like I  was Bitcoin miner like in very early days just on my work running computer and I sold it off  quite at a cheap price back then and it took me a while to understand uh what was the benefits of  Ethereum. I use d to work as a microwave engineer and electronics hardware, a lot of like signal  processing before and this is why I used to have like a good GPUs, good computers to actually  Bitcoin mine in the evenings when I didn't

need to to run the simulations on my antennas or  whatever. Yeah. And then uh when I got excited about Ethereum, one big part of my life actually  is that I'm building like communities or like experimenting with communities since I'm like  14 years old when I used to play online games and I used to like collect this like huge online  guilds of communities of people where guys of 40 years old age would listen for me something  talking with them like when I was just 14 and uh from there I don't know I was like creating  few communities this in my hometown helping people with creative expression and managing  artist communities and also like doing a lot of business. So also like doing some project  management and team management. So for me this

question about how to coordinate people always  was like run very paramount and in Ethereum one of the things which got me really excited about  Ethereum was the community and uh people around it. So that was my journey. We started doing there  some simple like games and analytics. We crowled actually a lot of data about NFT transactions when  we started doing that created some papers for like research around how people use Ethereum and then  I moved to more serious work. I worked at open zeppelin as security architect for almost 2 years.  I contributed to securing compound dow sandbox and also worked with some big institutional  customers. For me it was great opportunity to see the industry to learn to visit the events  meet great talented people and also learn a lot

about the Dows and uh the very thing which got  me very excited from the security perspective and see a lot of process challenges there and  it also brought me to Ethereum and EIP which is part of the journey I believe of course thank  you so much for sharing this when you are part of open zapping I can understand it is very  obvious that you would get involved with ERC and EIP people are like very much helping out with  making implementation of all those and I loved your like background starting from 14 years old  as a gamer and then finally getting into Bitcoin mining kind of OG even if it is like you know  you joined the ecosystem in 2020 that's not too late because that's when people started to learn  more about Ethereum. So, welcome to the Ethereum ecosystem and I'm so excited to learn about this  platform that helps maybe I'm not sure I'm going

to learn about it that is going to help us manage  EIP in a better way. So, without further ado, mage is all yours. Yeah. So the pyramid laps  is obviously is it it is a game of actually it's a word play around being peerto-peer and  surrounded by peers but creating the kind of hierarchical structure which is pyramid which  we like as society we need some stability and pyramidal structures they are the most stable this  is why pyramids in Egypt you know still stand and um I want to start with outlining what brought  me to the deep.box as a project and these are the first of all excitement about that RFC process  itself which I think like it inspired EIP process

which is more like famously known in the internet  as require request for comments and it brought the Ethereum improvement proposals and also Ethereum  requests for comments but the more I learn about it more challenges become visible and that is  first of all very complicated workspace which basically doesn't exist so You have to know how to  use GitHub, how to fork. There is no just common sense simple collaboration tooling available for  one of the what I found is a cornerstone element of not just Ethereum but modern internet actually  if you take all the FC process in the context as well and then having myself also worked and tried  to contribute to the EIPs and creating ERC's I couldn't not this that there are bottlenecks  which are sometimes not transparent but also

sometimes it's just like very clear I think even  for the EIP editors how to prioritize amongst all of these thousands of proposals where actually to  put them how to just create the the most efficient uh collaboration system for everyone and that also  brings to the third point here is lack of feedback transparency which is basically for me it's  relatively newcomers so five years in the space out of 10 for Ethereum it's been quite a challenge  to understand why there are two forum boards, why there are like half of the forum threads in  ETH research are dead and where should I post if I need to some have some feedback and then if  I create okay I go for ERC's to get the comments where do I actually get the useful communication  from the maybe more mature ecosystem editors or

even developers and well last not least but I  always like since childhood I'm very excited about like you know getting people together to  work building something together and blockchain infrastructure today is very fragmented and from  one side it's a great because it's decentralized so we can experiment but then there is no this  kind of glue together to see all of the picture all of the standards who is working on what so  these are just like few challenges and what we are proposing in DIP and what I was researching  for the last year since I basically left open zeppelin was how do we create streamlined state  machine for proposal life cycle where basically we want to have some fixed pace of transparent  understanding if I create some idea for a system

how actually I should expect it to progress  when I should expect to get the review feedback etc and dipbox largely is about creating this uh  state machine for proposal life cycle uh now I tried here to make it very illustrative I hope  the picture works it tries to like show here a conveyor belt which is like I used to work in  hardware manufacturing terms apply to me if I want to create system which is acting as conveyor belt  I want to EIP start from someone who's you know joining the ecosystem he's logging in he has some  authentication for his outer identity he's getting some collaboration tools to create those CIPs to  improve them share with his friends perhaps and keep them even private but then at some point  publish them for community to get some first

rounds of feedback where community might just push  back and say we don't need that and that would push it from conveyor belt out so the maintainers  and rest of the community doesn't has to work through that later on and then the maintainers  obviously they would also have their opinion and the core developers and u and the rough consensus  of Ethereum which is very interesting to improve but eventually it should get to the knowledge hub  of there is this work in and it was finalized and uh it's either used or is it like in the in the  IP process there is no like rejected but there can be withdrawn so after can be convinced that  his proposal doesn't make sense maybe right now and he could just withdraw it so when we created  this project as I was mentioning one of the key

thing we try to keep in mind is that we want it to  be multi-tenant and we want to support different projects in the ecosystem Now there are quite a  lot of projects that took uh copied basically the EIP process of Ethereum to their own repositories.  Polygon starket is just few of those. Uh but even other layer ones like SUI ecosystem they also have  SUI improvement proposals. So in a way I think I think this is like one of the greatest actually  gifts of the Ethereum community to the blockchain infrastructure and industry is like this whole  concept about that we have these repositories with improvement ideas and our idea here is that like  for multi-tenency it also means that if there are layer 2s on layer ones let's say polygon and  starknet there are layer twos on ethereum that

they can be part of that and we can actually  create the whole holistic integrated workspace for all of these projects. to collaborate  and share. So some of the basic things like you know EIP editing forms today in deep.box we  make them very simple. So uh we copy the field requirements from CI pipeline validation in GitHub  repository of existing ERC's and EIP and we copy these requirements to the forum validation so  that if you're creating EIP you don't have to think about whether the CI will pass or not. the  software takes um care for that. We create some collaboration tooling and we want to improve that.  So one of I can show here is that we can reference the IPS and we can actually show immediately  in the status of the IP which is in review.

So here in 799 which one is the latest one we  can immediately see that it's dependent on the in review stage 7918 which means that they are  in some kind of dependency graph together. Now extending the idea of cross tenant collaboration  it means that it could also reference like layer 2s could reference layer 1 dependencies  etc when they're creating their own standards and well one of the things we really want to  also invite and like I think personally and also discussing from my team and other people  that it's very important to have some kind of community feedback or community validation for the  EIPs and um my assumption which I want to validate I hope validate with you Puja today is that for  EIP editors it's important to understand which

standards which proposals should be prioritized  in the review process I assume today you're doing this based on the author's activity to just push  it for the review or uh maybe Ethereum foundation core developers themselves saying or maybe  contacting manually the uh major layer 2 systems and asking them whether for more autonomous  decentralized system. We can actually easily index say how much was gas used by everyone in Ethereum  over the past quarter or some season and give based on that some ability to give the feedback  in a review for let's say layer 2 ecosystems for node operators or just other community which EIP  should be prioritized for instance and uh this gets a little bit in like kind of DAO kind of um  philosophy here however one year ago I tried to

speak with Ethereum Foundation. I tried to speak  with team BO and Vitalik and I understood that for such big and very important infrastructure  Ethereum today creating circular dependencies on a decentralized governance is a huge risk  that developers would just not take. Therefore, when we create dip.box now, our idea is to create  more indicative uh like features to give this opportunities but not push them as a core feature  of the platform and certainly not make the whole thing fully automated but more just give more  tooling and more visibility and more options for the maintainers and the community as well. So  for community we actually like for the past year we've been doing a lot of research about how do we  make this decentralized decision making streamline

a more streamlined we have some other prototypes  where we are designing like basically reimagining what it is to have a forum board we have it  on another domain that's another thing we're building but there's a lot of stuff we can easily  integrate to dipbox which is including let's say discord forecaster and And we're generally very  excited about you know using research uh Ethereum foundation does on anticonusion infrastructure  modern quadratic voting zero knowledge proofs and just applying creating systems like big  inspiration for me is uh projects like Paul.is if you know there quite famous about using like  Bradletary model for having kind of governance decisions say in Taiwan. So I think it's quite  interesting space which can be like can have a lot

of opt-in features over time. We create also we're  working at maintainer administrative modules. So that would be basically for people like Sam or  Puja who are working on EIP editing site to get their administrative panel where they can sort  through by todos by the priorities say indicated by the community or just do their regular work  which we are really curious to learn more about uh which would involve also in my opinion one  of the important and missing point right now in EIP process is a formal review feedback to  the authors. As an author of EIPs, I I noticed that it's very hard and it's not transparent today  how to get the review from maintainers and one of

my AIPS down in this presentation will show case  where I submit the proposal into review and then it gets to the stagnant which for me is kind  of surprising because my expectation naturally is that review subsequentally should have some  feedback which I didn't get and I was like hm it's moved to stagnant. Okay, that's that's probably a  feedback I have to take here and the work on the dip dot box. So, and then eventually the knowledge  hub is the outcome of the work. This is what community produced. All of that flywheel which  was spinning there is the set of the standards and today the or website is quite simple. Here we  are adding search by title, by author, filtering by statuses, adding some statistics, analytics  and eventually we want to add their AI assistants

which are today quite common and like good fair  documentation portals. So why Ethereum can have it? So some new student who is learning about  blockchain can come into the portal and just ask AI about something in the EIP process. And what's  important here is that since we are crowling all of the commit history, all of the diff history,  then this assistance, they might have much more context than just like poorly crawling like  like the latest version of the repository. So in deep.box actually this is where we started.  So we want to create this editing experience.

We want to create this collaboration workspace  but it's not a product we can like showcase and get our attention and it's kind of tricky to  get the attention with it. So we started with crawling actually the EIP repositories themselves  to understand what are the metrics what are the how actually it looks like in Ethereum in the  project today we crowd all of the comments in all of the so EIP repository your C repository  and also rollup improvement proposals and we crowd diff from every EIP and we can see how many  comments were there how much days was it out there and we also see a lot of metrics from that like  let's say how this protocols are centralized.

So basically from the all of the authors who  actually tried to contribute to the protocol how many were accepted to the finalized author  stage what is acceptance rates which you can see like the formulas I learned from our code down  here and then yeah we bring this out statistics for instance it's very interesting to see here  that according to our outs page right now like if I take all of the protocols including the crowd  protocols for polygon and start where like Vitalic influence over the standards development which  means like how much of his name is across all of the proposals is around 10%. So it's not actually  that much that many people would expect and uh we also can see that there is some push back  from the community. So it gets some insights about

what is a protocol governance policies applied to  the practice and shown in the historical views. So we see like say for Vitalik that not all of  his proposals go live and u so it's interesting page but it also I think I can open this view list  bit later and show more details but I think it's great actually for contributors who want to grow  in the ecosystem because it immediately shows you which EIP repositories people contributed to  and it's good for career growth. I think it's great for learning and collaborating together.  So our goal and what we are trying to propose here is that standards can be developed faster.  We are much more accurate about what is actually

important to prioritize by giving community and  basically protocol users and customers to give us a development of the protocol. Then we also want  to expose the bottlenecks and obviously we want to have safety first. So here I just wrote that  the duplicated to decentralized storage but in a large way of thinking of this we want to make sure  that it's as robust as redundant as possible and in general give this benefit of increase speed  reduce costs just do automation of manual work and streamline the collaboration which is uh for  me long uh research topic of my life I guess but then there are some less obvious benefits uh few  of those which I'm excited about is that actually

businesses can say issue requests for proposals.  So let's say if someone wants like to focus researcher attentions on the pre-confirmations  then they could issue grant or rather request for EIPs directly on the IP pro portal. Why not?  Having spoken with some academia researchers and professors in universities, I know that there  is this problem that if researchers today want to contribute to blockchain protocols actually  don't know where to seek the information for the grants. So, and and it's very fragmented referring  to my first slides, it's very fragmented. So, you have to go like and seek like across hundreds  of websites. And if you're like say working on a protocol research level actually the like here EIP  is the place you want to go. So this is one then

well it's maybe more obvious but yes multi-tenant  nature you know it allows to compare ecosystems in the projects. So maybe it's more for institutions  today but uh you know if they are asking a question why should we use Ethereum and not SUI  and you can put them in one chart compare their governance policies or layer 2 like why we should  use optimum optimism or arbitrum or starkware uh but also if you would need to have an expert  in sayware and Ethereum the authorship page is is useful for that and then last for me is very  interesting topic because eventually I think that what EIP process creates is intellectual property  and but like actually it is so any of the APS

will have this like CC licensed creative common  license on the very bottom so the whole thing whole idea we're working here actually scales to  decentralized intellectual property and I have an article on that it's uh well it's clickable  link so if you have a link for presentation you can link from there otherwise you can share the  link But I have an article where I'm sharing that basically there should be some of the protocol  improvement proposals or discussions under some kind of restricted access otherwise it creates  game theoretical way which may be not really beneficial for open source community in the long  run. Um so that is like quite long way from where we're at right now but uh there are thoughts in  these directions as well. So I want just like

quickly go through the case study with Ethereum  particularly EIP ERC's repositories. So when we run our crowling and we got all of the metrics  we could see that at this point today what I'm calling bluntly centralization score here is  basically how many authors tried to get to the final stage and they couldn't versus how many  distinct authors actually got the final stage. You can see that 74% of authors actually are not  getting to the accepted uh finalized stage. Uh we can see immediately from our metrics that  there is a clear bottleneck in the IP process.

So there is like 137 last call proposals, 173 in  new review with only 132 in the finalized stage. It means that like it's quite scary I would  even say because if tomorrow last call like expectation for the last call as a name would be  that tomorrow they will be finalized. If tomorrow there is 137 finalized proposals it's a huge  change for the ecosystem. And then we also can see that there is almost no process of actually  withdraw the proposals. So there is almost no the send key diagram flow that someone would get  to the review or to the last call and actually withdraw his proposal after and most of you can  see like almost 50% of the ecosystem proposals

they just go directly to the stagnant. So it's  either like either it shouldn't be published at all or there was some problem why they couldn't  actually get forward or just withdraw them. And we also see that average proposal life cycle  is 156 days in Ethereum today. And then one of the explanation for say why there is so stag many  stagnant proposals maybe is a screen on the left here which is what the IP editor or proposer  has to go through in order to just submit a pull request valid once. So you have to go through  the form validation CI pipeline which is like not necessarily someone need to know how to fix that  at all. it doesn't has a correlation of skills to being a good protocol researcher in my opinion  for instance and in the middle you can see like

the example I mentioned before so I created the  EIP which I believe is quite important and I think it's quite cool and it could help a lot on a large  scale for protocol but obviously I'm not a core developer so my opinion uh it's hard to get review  and get it's hard to get feedback on and I can see from this analytics so basically when you can see  from analytics it was in a draft stage page and it went to review and it's been in a review for  almost 150 days and then it was moved to stagnant state and uh well I cannot here have some explicit  marker that they didn't had the review but that's uh that was my case and then another one which on  the right hand side here is another my personal experience so when there was a review for 7702  there was a lot of security concerns about

what it's going to break. It really changed some  environment and expectations of how the Ethereum operates. Now there was no incentive for me or  any kind of uh renumeration I was getting for going and seeking for these vulnerabilities but I  was able to prove that if the proposal already in a review I think it was review or last call if it  passes as is today that it actually causes bunch of smart contract application level protocols  to be uh vulnerable because they rely on uh some pattern which will stop to work as they expected.  And the problem there is that like just writing this post on discourse and getting like likes  or whatever it doesn't gets in any kind of uh it doesn't propagate the value back to me and any  contributor. So there is no incentive to go and

like actually actively participate as a community  and push back let's say on a proposal which uh is very hard to just account if you don't have  platform for that right. So what we create for uh EIP and EIP's repositories right now is that  when we try to think how we can actually make Ethereum actually use is that I assume that from  my personal just enterprise experience that most likely it's not going to happen that we can just  create some solution from scratch and Ethereum Foundation says great we want to migrate to  move all of our EIPs to your platform. So it most likely must be something lean where you can  just start to improve what you already have. So in current state in DIP we have GitHub integration  where we have written an app. So when you do the

addits on the EIP so we create new EIP. Uh what we  actually do is we just create a pull requests and um it requires some permissions in the repository.  Obviously we don't have it with the AIPS today. We have our own fork where we test this but  you can see it on the side. Basically, it creates a pull request with the file changes and  eventually in a lean way allows us to propose this um integration path. Now, this is a bit scary  diagram, but I'm almost done. I think it's the last one. So uh it just shows that there is  a lot of like in this lean approach there's a lot of manual work because we need to you know  actually the like when we even when we crowd the IP repositories we learned how much the formats  changed the markdown the the font matter on top

with the metadata for the protocols it changed  and the names of the statuses also so and some of the proposals moved from one repository  another and when we tried to do analytics it was quite hard to actually got through all  of these boundary cases. But eventually like if we want to use it the Selen approach, we just  use repository master branch as source of truth. We just follow whenever something is merged to  main branch and we synchronize our service to that. all of the contribution back whether this  authors or maintainers doing some edits. It just creates a pull request or perhaps for maintainers  uh it could uh give some more permissions but in the current diagram in the current proposals it  doesn't require any really permissions except for

create like managing pull requests. So there is  quite small uh security footprint for integrating such a system for existing repository. So I'm  almost finished. I just wanted to note is that obviously there is like two ways of managing  those repositories today. So one is a GitHub which is Ethereum foundation does another is  a Dow which they use platforms like tally or snapshot and snapshot for instance something  what we propose is like kind of opportunity for this community feedback system but they don't  have this visibility of EIP like repositories of RFC like standards. So if you're trying to find  say arbitum improvement proposals it's actually very tricky. You can see the vote you can see the  discussion but where is actually the standard that

they created it's not rendered. So we envision  that deep platform will be able to actually go and get to this one ecosystem multi-tenant uh  infrastructure also protocols like lido arbitrum etc which also they contribute important uh pieces  of all of that puzzle blockchain protocols and uh so my personal motivation in this is that for  my personal projects in the real world I want to build real world solutions we have uh in Latvia a  problem with a forest cut out by the government. So we're trying to create a nonprofit society  there to fight the and just buy out the land and have a nonprofit to govern the forests so  that we can teach our government how they should

treat the forest uh management because they  just like cutting an unsustainable manners. we have similar projects in Indonesia and  basically when I learn about DAO and governance space I realized that we need to have a platform  we can streamline those discussions and it's less about just having a DA where the people have token  and vote and more about how do we actually decide on some complicated topic together and make sure  that the merits and the end results matter really. Um so it's pretty much it uh I hope uh I hope you  part with me and I'm looking for some questions. Thank you for the presentation, Tim. I have  been in the space since 2019. I feel motivated whenever I hear that people are having hard time  understanding what's going into the ecosystem,

what is the right way of sending a proposal or  making a comment or providing feedback. I feel motivated because I understand that this is an  area of improvement for us where we can ensure that these information are easily available. So  thank you so much for sharing this presentation as well as your personal experience providing  us some insight about what are the area for improvement for our team. During the presentation  you have already covered a few questions that I had in mind yet to clarify a little bit more.  I have some questions to go over if that's okay with you. Sure. Let's go. All right. So let's  begin with like with the one core problem in blockchain governance that this platform is  trying to solve. I know you have mentioned

about multiple issues in this ecosystem but if you  have to suggest that this is the one core problem in blockchain governance DIP dunbox is solving  for us what that would be I would say this is facilitation of intellectual property like that  would be just very abstract it allows me to cover like everything in a very non saying anything so  I don't know if it's a good answer for you I think I was trying to understand what DIP stands for  but you very well explained it's decentralized intellectual property I like to play with the  words so I would call like from one side I call it decentralization improvement proposals on another  hand I don't know it's just part of my nature I like to play with the names so if I can like put  the two names in one I'll do that but I think like

most probably what we are trying to really achieve  is to make Ethereum and standards development more transparent and more efficient and more engaged  and scale the great thing which Ethereum invented which is this repository to help communities maybe  not who don't even know and don't want to think about blockchain but they also have the same  problem of coordinating in decentralized world coordination can be challenging very well I'm  going through the website and it suggests that this is an aggregated datadriven view of activity  contributions and health of major blockchain. So let's talk about Ethereum in general. So if  we are considering Ethereum, which all repo information does it include? So today in our  website we did crow of Ethereum EIP repository,

Ethereum ERC repository and as a separate track  we crowd also rollup improvement proposals. So if you go today to ethereum.dip.box box the view  you are getting is ERC's and EAPs the rollup improvements are not there yeah I just wanted  to be sure of that because I was just trying to relate with the numbers countings and everything  we'll get there but before we go there I wanted to look into another aspect of it you already have  mentioned multiple benefits of the website who in your mind would be the main user or the consumer  of this particular website could it be author editor or the community it's a good question I  I think all of those it obviously has to start from so in the forum right now the honestly the  editing experience is just something proposed on

the table and it's envisioned that EIP editors and  uh maintainers would be the core users eventually scaling it to community who would get the tools  and it would get this incentives basically if we have some feedback system we could invite more  community to join and on board more people to becoming editors and maintainers eventually.  All right. Uh that is great. Maybe to begin with editors and then authors and then invite more  people. It's a great idea. I'm curious the data that we are reflecting here. Where can we find  that data that supports the chart available on the website? Is it downloadable? How can we actually  validate the correctness of it? I can share the

link for my repository. I made it open source.  The data itself is in the database which is not available but you can run the crawlers and you can  crawl the data set. It takes it takes somewhere around maybe 1 hour or 2 hours and you get it  and I'm happy to help to set it up. I was curious because I was trying to understand in your one of  your slides of safety you mentioned about storing this data in decentralized storage. It's like  standards are duplicated to decentralized storage. What does that mean? Are you trying to store data  from from the GitHub? Yeah. So I generally I don't trust Microsoft that much. So if we are speaking  about like now now it's like network state is very popular you know term like people say about like  you know self-s sovereign etc. So what happens if

tomorrow GitHub goes down? So you have to relay  on the fact that some contributors had the GitHub like the repository checked out locally. You have  to hit them basically on Telegram or somewhere and like hey who has the last comet from like this  branch or whatever. Obviously like GitHub is super stable. If it goes down like a lot of projects  will go down. It doesn't cost much to duplicate that. And uh we are you know I I'm actually a  big fan of Swarm by Victor Thrawn and the Swarm Foundation. I know they used to try to build  this decentralized store layer. So I think it's interesting to explore this. Of course it would  be. So as of now the data is not onchain. Is that a correct understanding? No, no, no. We are so  we're crawling right now this into our database.

The next step would be just to make our database  IPFS and we are not storing anything on chain. The only thing I was uh proposing to do on chain  and I'm looking to you know your feedback is basically what I would propose is let's index  how much people have spent gas on Ethereum last quarter of the year and let's give them some kind  of vote credits not necessarily tokenize them but just we can just like have internal record you  know for some big wallets which are automated bots who do not have this like ability to  climb those we can just like you know like Ethereum foundation or it's a arbitum or it's like  coinbase just give them manually this assignment and give them based on that ability to you  know support the IPS so that that would be

probably the most onchain thing I would imagine  right now however I want to notice here that we have a another project it's called rankify  where we are creating basically a DAO bootstrap algorithm where people design like basically  they participate in a forum like discussion And that discussion results in governance power  and there we put everything on chain but it's an optin feature and it's on a separate domain  right now. So in the deep dobox there is no web integrations. Sure. I mean I'm happy to hear  that there are more pro project in pipeline that's going to support the ecosystem. Well my next  question is with respect to one of the challenges called as bottleneck in the ecosystem. One of the  charts that you shared during the presentation

was like okay bottleneck is visible. We want to  understand what is how to withdraw proposal. There are with proposals in stagnant statuses and all.  I'm curious to hear if there is a particular plan or proposal in mind how can we actually resolve  this bottleneck. Yeah. So what I I think right now maybe there is one things one thing I really  I don't know how that should be done but it has to have some answer coming from yeah for you is  that there is no rejected status actually just to add a little bit more here the withdrawal  is a process is an action but it is also as a status as a status we call is it withdrawn and  because EIP process is more author-driven. It

is on the author if he or she wants to withdraw  the proposal. If they do not take any action, the proposal by default will move to the stagnant  status. While a stagnant status is resurrectable, withdrawn isn't. All right. Yeah, I think  I got I I got you. Yeah. Yeah. Yeah. So, it's like author driven. So well there then  inherently some bottleneck might persist because some author can just like make a comment  automatically once or 3 months there and keep it in review. Well I mean I would say that maybe like  I don't want to comment on like whether it's right or not decision. I don't know the rationale  behind but the proposal we have what we can do right now is what we proposed basically let's  say that there is a seasons because we know that

the core developers want to release hard forks  on a a specific pace uh in project management and also in the hardware more like you know supply  chain management industry there is like this very well-known thing is just in time management where  you don't store anything in your factory you just get the supply whenever it's time to actually use  it So why don't we have EIP just in time standard management where all of the phases are strictly  written. So uh I was showing in our diagram the flywheel where basically it there was like Q1  Q2 Q3 Q4. One thing we could explore say if you create a draft EIP it cannot be in review faster  than one quarter. So it has to you might create it maybe one day before the quarter ends and then  it gets to review but it still is quarterly based

then when it gets to the review stage obviously  this is one quarter for maintainers to review the piece and if there is too much of those then  it's literally a bottleneck which is just depend on how many maintainers is there in Ethereum  protocol therefore there must be some way of prioritize which one you take first from the heap  so you have to take the heap and make it a stack and take from the stack like for like by  some priority. This priority I suggest uh doing what I was saying like let's index the  gas used on Ethereum give community ability to vote. So if you're using Ethereum if you're a  customer and this is very like product mindset which I think in Ethereum generally was missing  because in traditional product companies you would have this like not promoter scores where customer  can give actually review to your product and say

like net promoter score it basically stands of  how likely is your customer recommend some other of his friends to use your product but also  just you know this kind of feedback systems they are important they must be set up and they  would help to prioritize and then obviously that last call status it's uh also could be like  say if it's in the last call it means that in 3 or 4 months it's going to be included in the  next fork and then when fork goes out you could make it just in time obviously there is a lot of  probably needs of uh perhaps even re rethinking that state machine statuses because let's say if  EIP editors passed it through and they consider that this is great and core developers are agree  all agree ree the hard fork inclusion. Obviously,

it also requires node clients and execution  clients and consensus teams to catch up with that. So perhaps there could be like some status  which is like in progress or something which describes it. So in a way some things we can start  doing now without doing drastical changes but over the larger period of time I think there needs  to be some improvements in the status machines complexity itself as well right I love the word  that you have added for state machine and a proposal around that but just for information at  present this status progress is not dependent on time except for one which is called as Last call  for uh status changes on EIP section. Generally,

it is dependent upon the stage the network  upgrade stage on which this proposal is. Now, if people are curious how we can go for acceptance  or rejection of a particular upgrade in the first place, my recommendation would be all core dev  call. So, all core calls are very public. There is an agenda on Ethereum/PM GitHub repository. This  meeting happens every Thursday at 1400 UTC. So anyone with a proposal that wants to be included  in one or the other upgrade should talk about that proposal in all core dev call. Once there is a  signal from client team that this proposal seems interesting and they have bandwidth and h and  they would like to prioritize it that particular

proposal will be listed as proposal for inclusion  in the upgrade meta e. That's how we begin. And the status change for all core proposals moved  based on the network upgrade stages. For example, if it is in PFI proposal for inclusion, it could  be in draft/re. But when it goes on test net, then it goes for the last call. And when it  is finally on the mainet, then it goes to the final. So here the time dependency on the upgrade  size. However, for ERC proposal, that's not the case. For ERC proposal, there is no dependency of  selection for an upgrade. It is mostly on author.

When they find their proposal is ready, they can  move it from draft to review and from review to last call. On last call, they have to be there for  another 14 days just to make sure that they are closing everything they received as a feedback  and there are no open feedback or pull request suggestion otherwise they can move the proposal to  the final status. So this is on a very high level how the proposals are managed at this time. So  it's less on maintainers, it's more on the person who is behind this proposal or the group. So I  would want to add here some personal experience that first of all the core dev calls and they are  not scalable to the worldwide and we spoke about that. I'm personally located in Asian time zone.  Uh for me it's like 9:30 right now. So I cannot

imagine Ethereum to scale as a global system if  you cannot invite all of the global community to participate. There's a lot of smart people around  the world who would not join these dev calls. not at any case because it's just in the wrong timing  and it's a strategy of having a planet a circle but I think the solution for that is that you like  there is there just needs to be more a synchronous communication and more formalized a synchronous  flow which people can read through leave the review get give the formal review perhaps even  just have a call and then record some some deep does also about that fact that I like having live  calls but it's not it's not scalable really and uh and also from the outsource of ERC repository  my personal impression is that well if I can just

myself push it to the like finalized stage as an  author without having real support by community then I don't think the standard really like worth  of much but otherwise yeah it's very interesting to know that uh you help the processes around like  and synchronizing hardworks It's exciting, right? Maybe they won't be able to move it to finalize  because that's where EIP/ERC editors comes into picture. They will definitely go back with some  kind of recommendation. Show me the implementation of it like if there are projects interested in  implementing these proposals and things like that. But you raised a very good point of uh the  time constraint. Not everybody is very comfortable to join the ACD calls. Maybe because they are  living in different part of the world. But we

have in the meantime find out a solution for that  and there is a series called PEEP and EIP in which we invite author to like share their proposal  demonstrate the proposal how it is going to help to the ecosystem and we can perhaps share that  with the all core devs. So we are working around uh mitigating all these issues all the challenges  that present contributors are facing and to help with new ideas we invite them to participate  in EIP IP meeting that is a place where you can provide feedback on the process you can help us  improve the process because all these processes are documented in EIP1 and with the discussion  in EIP IP meeting we can perhaps update EIP1 And so we are just trying to fill the gaps here.  We will invite people to reach out. You're doing

great job. You're doing great job so much. I tried  to support but I really am big fan of everything you do guys. And it's I don't think anyone in  the world really is doing that brilliant work in this direction right now. And even like things  you're mentioning right now, I immediately think, oh my god, but we can put that like you know all  of these calls, all of these opportunities for editors could be integrated in deep. So I could  have email notifications for authors. They're invited to actually go to some call and have  more visibility because as an ERC or EIP author, I might not know this. So yeah, I have like all of  these ideas immediately how we can actually build it even more better for everyone. I'm glad we are  collecting more ideas to have a better system, more robust one. Well, let's move on to the next  uh question that I have on my list. It's about

the historical trend chart which I noticed on  their website and it talks about something called as centralization chart. Taking a look at the  table, it seems like Ethereum mainet and rollup on Ethereum are highly centralized. That's my  understanding with the number. Can you talk a little bit more about that? What are the criteria  for determining uh that they are centralized or what do we want to say exactly from highlighting  this centralization part over there? So just first disclaimer first of all is this is my bault  figuring out this metric and I'm sure it can be improved. It's just a query perhaps is too simple  right now. Right now it's showing basically how many like it counts distinct authors in the ERC or  AP repositories together and then it compares how

many distinct outers are in the finalized stage  proposals versus how many distinct authors went to the like haven't withdrawn their proposals. So  basically they got and then the query might be not the perfect right now because ideally we want to  write a query where we want to go like they went to the review stage and then they couldn't get to  the finalist stage which means that they tried to get accepted and it's a distinct authors they  could not. So the way to think of this is like let's say Vitalic Bhutarian creates a proposal  about 7702. I was around there when I saw it and like immediately everybody talks about 7702  because he's obviously a key opinion leader in Ethereum space. So his influence over the protocol  has a negative black flick of the same coin which

is a centralization of the protocol of like if  tomorrow Vitalik is gone like what are we going to do? So roughly this is the centralization  score is about this. There is another which is acceptance rate uh which is not about it's  counting exactly the Yes. So the acceptance rate it counts uh proposals not the others. It  counts how many finalized proposals are there versus eligible proposals which I counted as total  proposals from which were withdrawn and stagnant removed. So there's like two metrics to show this.  Yeah. No, that's great. Um mean I think I'm going to correct my understanding here. Earlier the word  centralization was giving me a negative impact of it like the system is dependent on one thing  but I would like to take this centralization as

a committed contribution. So more centralized  that means we have a good or a better holding of contributors in the ecosystem that they are  coming up with new and new proposals every time. For now it is because perhaps he is one of those  contributors who has been in the ecosystem for long like since the inception of the ecosystem but  perhaps this can change in future and it would be a good metrics to showcase that we have retention  of developers and contributors to the Ethereum ecosystem. Yeah and for this we need to have some  you know some visibility over the metrics. So actually here we have uh the authorship screen and  if I just filter it to down to ethereum. Now there

obviously like there is some dduplication work  I have to do because like and this is one of the challenges with working with GitHub because there  is here's vital here's vbutarian and we did a lot of dduplication already at this point but still  like we have we should actually sum that up but I wanted to show something that okay like we can in  mind combine these numbers his influence in my way of counting that is not that crucial is maybe yes  15% of proposals are authored by vital tellarian. But if you say take a look on um like accept the  success scores like there are people who had much more success in creating proposals and actually  getting them finalized and they had quite a few proposals as well. So you can see we can clearly  see and the idea is to showcase it also for you

know institutions when they decide now which  protocols are using they also are locking in this metrics. So they will want to compare which  rollups to use. Uh and this is a great stimulus for rollups for protocols to invest in their  researchers and invest in the support. But what I wanted to share here is that I don't think this  metrics are that bad today. I like I think they're great. Maybe could be better but uh still and also  like centralization score. I mean it's obviously a balance between having quality of contributions  versus diversity of contributions. So it's not necessarily good or bad thing and perhaps we can  also coin it somehow better at a later point but when when we will start adding their other  protocols I'm actually very excited to add

the sui or some other like layer ones to see how  they will compare to that because I assume that there will be protocols that will climb they have  huge total value locked or whatever and then when we analyze who is actually contributing there will  be like one or two persons right I would also like to share one pie piece of information for people  who are following this podcast. The way an EIP is documented, accepted and implemented, it actually  does not begin with the draft status. It begins with a forum called ETH research. If you have any  research, you first go ahead and document those research. Generally speaking, those researchers I  by default added as an EIP author because the idea is coming from them. a champion can pick it up  and have further discussion on ETH magician forum.

ETH magician forum is going to be a place where  all sort of uh comments are invited especially with respect to proposal like we don't want to go  for technical comments which are only limited to documentation of the proposal but we focus more on  the specs related comments on ETH magician side. So the next step is like documentation of proposal  and it goes on ETH magician for community initial feedback like whether it could be passed as a  draft or not. If there are any similar proposal already existing or not but if a proposal is  passed through all these phases they find it to be unique then they go into review and other  stages. So generally speaking if we find Vitalik's name all over the places it's not because he has  authored all the EIPs. suggest that maybe some

of the suggestions that he did was picked up  by a champion and that was further converted into an EIP. So it's not more of influence. It's  just a reference. I think this is also a problem in ecosystem because people when they create EIPs  they're creating their own personal career often they contribute years of their life and there is  no visibility of that. So you cannot go and like find all of these topics and understand how much  they got support into the particular EIP and I was showing this was one post of uh my finding for  EIP7702 but say before when I was working at open Zeppelin you know we talk there with contributors  with ARC's and uh there was also a frustration

about that sometimes they contribute some  ideas and they don't get an authorship and it's uh understandable that there are this champion  system today in my view it's also a lot dependent just because there is no workspace so DIPbox  imagined as a platform where eventually we would want to have the vision that with research  and medications are either integrated as API or fully migrated but it becomes cohesive one  space discussions as well because then we can track the author's wallets author's GitHubs  everything and they can get this recognition back easily and it can be automated. So very well  in continuation of that would you like to maybe share around 6 to 12 months road map for DIP.box  or what's there that we can expect like in near

future? So honestly right now I spend like one  year uh doing my personal research about this governance problems in the DAO space. My dream  personal dream as an engineer and entrepreneur is to build a products that help people that  helped communities to scale. So obviously I'm trying to build this as a product today. uh but  uh we are at the stage where we uh are basically talking to foundations looking for the grants and  eventually offering them as a product and you know it depends whether we have a grants or not or we  can just or we have to go this way of directly offering a product uh without initial support  but uh optimistically if we can have support from Ethereum Foundation say in six months from  now we would be happy to have community feedback

modules where uh we would index the gas usage.  We would give the ability to support the APS. We would create tenant administration log where  maintainers could add their contributors and uh would have tools they need to easily manage  the statuses. Now depending on the conversation and the needs of particular organizations say  Ethereum foundation we would need to discuss do we need to build a specific GitHub integration or  not but generally speaking yes I would say editing experience certainly is would be there maybe the  forum and discussion things would not be directly integrated but uh some simple notifications for  instance the part you mentioned about EIP calls well I would certainly imagine simple workflow  where we can send an invitation email to the

contributor or author inviting him for particular  uh events which are related to his initiative and then in a 12 month period obviously we would start  to adding there more ecosystems on board perhaps even some DA who could try to use the system  because one of the problems I was mentioning that like say for arbitrum you can just like you  cannot see those proposals at all they are not that transparent at all at the end phase of them  which is I can go and read this Thunder and also we would certainly try to more you know store it  in a decentralized storage is ensure the platform is secure like one of the risks factors here  which I'm taking seriously that if I'm creating EIP editing workspace there will be high net  individuals joining that platform so the platform

will be constant attack vector for anyone who's  trying to make bad things to and hack and we just literally just now we saw this like vulnerability  with npm packages on debug and um what was it uh chalk dependency and I scanned by the way I have  a Twitter post I can share the links with you guys I scanned Ethereum Foundation repositories and I  found bunch of dependencies which is like you can use a GitHub query I wrote and it's like popping  up but uh obviously like just like a lot of risk so we would make sure that it is safe secure  transparent to use we would robust we would refine the analytics as well so it's well defined and uh  really comprehends the truth. It would be fully open source so everyone could validate and verify  and yeah and we would talk to editors community

would look for what kind of features we can  implement more. Thank you so much. We are going to remain optimistic about it and I understand as you  being a past security architect that is definitely in there in your mind and the system that we are  going to see eventually would be robust and we will have a very good platform for all these EIP  editing and governance related stuff. Tim, thank you so much for taking out time and sharing this  platform with us. I look forward to collect some more feedbacks from you on the present process and  would love to invite you for future EIP meetings. Those meeting agenda are always available on  Ethereum/PM repository whenever you think you have some ideas and you would love to suggest those  to editors to incorporate in present process.

I will be happy to have you on there. Thank you  K. Thank you for giving me a stage today. It was a pleasure talking to you and I'm happy to share  uh and join the calls for EIP calls. Certainly, I'll check the repository for that later. Very  well. That concludes today's talk. Listeners, please check out the show notes for additional  links and resources and we look forward to bring you the next episode soon. Until  then, take care of yourself. Cheers.