Plus, we had an earlier call today about a development that's called Back East. Ask a question there that we we said that we'll take it in class. And I was thinking that maybe this could be the topic of discussion or we can talk a little bit more about it. So I'm just going to copy the guy or the link to it or link to it and the town hall chat. I'm just going to copy it so it's easier to read, but so and maybe before taking the question and we can take it a step back and just set the scene on, you know, what, what do we mean or what what do we imagine or think when when we're talking about sports? So and one of the governance codes we discussed a little bit on, you know, what what a fourth may be maybe what is the advantage of having of having a fork or why would you want to just read out the question for those that are just listening? Yes. So so the question talks about about for let's say a four could happen, you know, or being so called fork back as question is what would that mean for pod holders, shareholders? And, you know, third party protocols are basically you've been stuck. So maybe before before answering this specific question, I was asking if you can maybe summarize and tell us why would we end up in such a scenario, What would happen or what is the scenario that we envision in which a fork happens? And then maybe we can answer this question and see what happens to, you know, pod search holders or the participants. So one of the facts of operating in an open source environment is that in practice, anyone can take your ideas and your implementations and create copies. And there is some aspect of survival of the fittest that is core to the environment that the beanstalk operates in. And to some extent that applies both from an economics perspective as well as a technology perspective that the nature of money as well as the nature of open source technology, makes it such that the environment beanstalk exists and is is is as competitive as it gets. Now, if if we assume that Beanstalk is somewhat successful and you can define success as where it already is or some point in the future, it is entirely unrealistic to expect that there will not be copies of Beanstalk. Our system is very similar to Beanstalk that ultimately arrives to try to compete with it and the competition is perfectly healthy in our opinion. But with that said, there is some aspect of the system being designed to succeed in the highest chance possible, to give it the highest probability distribution of success. When you consider all of the potential scenarios that it may find itself in that it is, it is the scenarios in which being sarcastic compete with forks is almost certainly a reality that it will face if it continues to be successful. And then the question becomes how to how the system can best prepare itself for that environment such that it it is most likely to succeed in perpetuity. That's the starting point. Now, the reason why there has been, at least on our part, some discussion about forks is within the context of governance of Beanstalk. Ultimately, the question as to whether or not to propose to change Beanstalk through a bet or create some sort of copy of Beanstalk or an explicit fork, it is fundamentally a governance question, and therefore, at least from our perspective, the the discussion around how Beanstalk itself should deal with Forks is has to be taken in the context of the system of governance that is being implemented. So it's both an economics question and a governance question in practice for being stock. But forks in general are something that the the open source environment effectively manned it in practice and at least, you know, from our perspective, there has been some conversation around Forks of Beanstalk springing up because of dissatisfaction with the current implementation or its growth thereof, and therefore it probably is really healthy for for the conversation around how Beanstalk should operate, assuming that there are forks to happen sooner rather than later. Now, in practice, the implementation of a system that could enforce a somewhat autonomously or entirely autonomously whatever fork in protocol makes sense in theory is going to be significant. It's going to take a while. And so to some extent, we may be getting ahead of ourselves to try to to try to think that this is a problem that can be solved in short order, but at least it's a topic that hasn't been discussed much to date, at least to our knowledge. And it seems like given given all of the questions around funding of Beanstalk farms and the right way to govern the system and as well as just the general environment that Beanstalk finds itself in, it's not a bad time to have the discussion, although to be totally honest, having having dug into it to the point where we feel like we have resolution. So we'll be thinking through a lot of this out loud. You know, right now. Great. And maybe this could be in our first discussion or maybe even the terms of discussion of many others who are with us today or later can almost join us as it matures, allows the conversation matures, published before or you've described before as, let's say, a peaceful transition and maybe one, but is not useful. Can you maybe explain what you meant by that? And you know what what what is what is a peaceful transition in a so the what we meant by that was that there is some ability to exit the system freely and from an ethos perspective, the idea is that anyone should have the ability to leave the system as they choose. Now, currently, the way that you can leave the system is by selling your being, which is perfectly reasonable. Now from the perspective of Beanstalk in particular, if there is going to be a fork where a significant amount of demand for beans leaves the system, it's certainly worth considering whether or not it's in the interest of bean stock to allow people to or encourage the fork by lowering the friction associated with something like this for the fork to port over as much of the beanstalk state as it would like, such that people opt instead of selling their beans from the original version and buying the beans in the fork version to burn their beans in the current version and mint beans in the new version. That would be at the margin. The only real reason for being stock to implement some sort of forking protocol natively. And it is worth thinking through a little bit whether or not in practice that would that would be the case. But if we grant that it is the case that that some people that some I guess the fundamental question is, is there ever an instance where the fork of beans stock would want to honor the old the old beanstalk state in any capacity and as opposed to spinning up from scratch? And if that is the case, if there does seem to be some economic incentive fundamentally for a fork of beanstalk, instead of spinning up from scratch to migrate some or something, some portion of the or maybe all, but at least some portion of the state of being stock in terms of outstanding beans, pods and fertilizer. Then if there is some incentive for that new implementation of Beanstalk to honor that old state and I guess additionally would be the stock, the grown stock in particular, that if if that's the case, it may be in the interest of the old version of Beanstalk to make it as easy as possible for the fork to honor as much of that old state as possible. And there are a couple of reasons for that. One would be, I guess the first reason that we already mentioned would be the burning of beans to mint them on the new chain. Presumably you'd really be burning deposits to mint deposits on the new implementation of being stock, not necessarily a new chain per say, but the, the the, the other way where there's potentially some indirect benefit to bean stock would be that if the likelihood that a fork honors the debt of the current version of being stock pods and fertilizer, that that may increase the value of pods and fertilizer and that is inherently beneficial to beanstalk. So there is some some indirect benefit and then some more direct benefit where instead of having the being sold on the market and the need to either borrow or through convert return the price to the pay by by making it potentially seamless for people to burn their deposits on one version of being stock to mint them on another, the system could dramatically decrease potentially the sell pressure associated with competitive versions of stock. Okay, I have a few follow up questions on that, but we will read maybe the comments from Chance. And they're asking if we're thinking about forking and who would initiate that fork. And then what's the difference between the OG Beanstalk and the fourth Beanstalk? I think the last question was probably what we're discussing, but are we thinking about forking and who is initiating the fork? This is just, you know, talks on general, nothing concrete is happening now and that's probably a cover that maybe earlier and then you can maybe share some answers. This is that we're having a discussion, but maybe we think hasn't hasn't been discussed yet and where you can extract more as being Pip, I want to just explicitly say that we progress have no intention of working bean stock. However, people have come to us and talked about forking the stock and therefore do feel like it's a a relevant topic to be discussing. And furthermore, the the real a separate from the fact that people people may for be in stock as has always been the case. I think there was actually one for I don't even remember what it was I think it was Korean themed a while back. I could be mistaken on that. But the other thing is there is an active conversation happening around governance and trying to figure out a permanent system of on chain governance that beanstalk can survive with in perpetuity and fundamentally feel like forking. It has to be considered in the context of on chain autonomous governance. So the question is whether or not being stock from a governance perspective should welcome forks because of the potential benefit to Beanstalk, or whether it should maximize the friction around forks to prioritize its current network effect. And that's a debate worth having around what would be the marginal benefit to Beanstalk of facilitating something like this. It probably also has to be had in the context of whether or not the debt, meaning the pods and the fertilizer, would be honored by the fork. From our perspective, I feel like it's almost impossible for the network effect of Beanstalk to be copied or duplicated without honoring the debt, because the debt is funded as a credit based system. The current debt and the ability to repay the debt is fundamentally where the value of the system derives. And so the honoring of the the outstanding debt of beanstalk seems to be almost necessary in order to to to take over the network effect of beanstalk, particularly at scale at the current stage, that's more questionable. But the the bigger point is that these are just fundamental questions that need to be addressed and answered as we are as we are constructing a governance system. Yes, agreed. And I see some of the comments that are, you know, maybe shying away or or prefer not to not to have the forking or the fork discussion. But I think all discussions are eventually positive, are maybe talking more in-depth about it clears up or explains reasons on why not to do such a thing or maybe even why to do it if it's a good thing. And then how to do it. Okay, publish. Want to go back to the example then that maybe was started with that to some extent. Just what I want to say, sort of agree with Harry that this is probably not the most constructive thing to be talking about at the margin, but people have questions. And fundamentally, we feel like class is a place where any time that there are questions, it's important to address them. Last time we mentioned the forks in the context of the governance discussion, perhaps that was a mistake too, but only if you think that this is not something that needs to be answered in the medium term, let's call it and while there has been some productive discussion to fix or improve the governance situation in the short term, hard to think that this isn't a very relevant piece of the puzzle. And, you know, we're not going to shy away from talking about anything that we feel is important for a final autonomous version of Beanstalk to exist. Recognize that from a from a strategic perspective, talking about forks may make forks more likely, but at the end of the day, from at least from our perspective, forks have always been something that are expected and it's really about how the system would operate in a competitive environment. And to shy away from those types of questions is probably not optimized. And over a long, long time horizon, the system ultimately really does need to be competitive in all situations. So recognize talking about this stuff may make people a little uncomfortable, particularly if you're thinking about, you know, we're going to go fork the protocol again. We have no intention to do that at all at the moment and feel like honoring honoring all of the current again, debt of the system is sort of fundamental to the the nature of the system and to create a new beanstalk would be totally against the point. And from this perspective and honestly, this is actually maybe a good point to make from the perspective of if the system is going to have all of the outstanding debt of the system, what what does it actually mean to be a fork, Right. It's a copy of the the the software of the system with some alterations. But fundamentally, the previous state of the system is somewhat being there. And so if we talk about this from a theoretical perspective, particularly in the context of the environment that beanstalk exists and like a chain, you have a hard fork in a software where the hard fork effectively makes it such that the new version of the software is not backwards compatible with the old version of the software, but the state of the system is still retained. And. Whereas in a saw fork, the the the old version, the old version of the software is still valid. Excuse me an old. Yeah. I think that's a decent way to put it. Probably not the best, but the, the concept is that when you have, when you have the system go into a, a hard fork, you have a bifurcation in the future of state of the network. Whereas when it's a soft fork, there is no, there is no duplication or separation of the state of the network. There's just two separate versions of the software that may be coming to consensus on the same thing. And this is fundamental. The difference between the way that bits currently work and being stopped, which are all in practice Soft Forks was something that would more closely resemble a hard fork where there are some honoring of and anyone can obviously just copy beanstalk and deploy it from scratch. But what we're really talking about here is the honoring of pods and fertilizer and at least in some capacity, maybe according to some multiplier plus or minus, you know, could be a bonus to encourage people to come to the new system. Or it could be cutting the debt in some capacity. But there's an honoring of the previous state of the system. And then there's a question of if you think about the the depositors in the silo, the holders of the value in the system are somewhat the the validators of the network in the context of network forks. Then there's a question as to making it such that the depositors with the liquid value of the system comes from can just migrate through the two different versions of the system. That's probably what the most competitive low friction version of the system would look like. And the implications of something like this are pretty meaningful in the context of at the moment. If you think about what happened with the merge, we've spoken about this before in practice. All of the the the, the decision around which chain to honor went down to or came down to very few centralized participants in the system who are the issuers of the stablecoins on the on on the chain and they have the in practice the ability to decide which chain is valid because the majority of value on the chain, other than either itself is coming from centralized issuers. And they they can only honor a single version of the stablecoin. So they basically have to choose or they could create some sort of system where people, after they could honor both chains, but people have to in advance opt into a chain. So there's some ability to to opt to opt into the new chain in advance or into the old chain in advance. And that's in practice what we're talking about implementing here. And so you can really think about this as from a forking perspective, a larger problem than just being stopped. It's a problem that extends to the network layer. And this is the type of solution because Bienstock is in the same position, it really doesn't make sense for a fork to just duplicate the entire state, including the liquid beings, because you can't really double the supply of money and expect both of them to retain value. So you have to cut you at you, at least in theory, you wouldn't expect to be able to just double the supply of money and maintain the price of the both monies. So there's some question of making it as easy as possible to opt into the new or old system. And it's low friction that's possible. And that type of model could extend to, again, not just bienstock, but to a governance at the chain layer as well, or the network layer. Yeah, I think this is maybe a sad comment, but typically one of you know, when when you're talking about a non collateralized stablecoins or, you know, Stablecoins, the argument is always, you know, why this wouldn't work if I just thought that I was double the amount of money without of course, you know, here we're talking about why, why that's not the case. Okay. Published. I want to go back to the example of let's say that is a fork right now. And then for all and for now, let's want to talk about, you know, stockholders, since that's easier for them to exit and enter the system versus, you know, board or shareholders. One way for you to go to the new forth, let's say, is that you exit the silo, you sell all your beans or whatever it is that you have, and then you enter the new fork and then another way and then maybe this is what we described as a split, is that there is some sort of an agreement between these the status quo or the original protocol. And then you can you can just switch to two to the newer one or two. Then you would talk. Is that is that correct? So far in the scenario of the correct code, it's either selling or the peaceful option is to have some sort of opt in? Correct. Okay. Do you think what what reasons do you think or can you think of why why would anyone specify maybe why would the new system want to accept, you know, all all that or, you know, holders and then the some of that on why would the older ones also want to want to move Do you see any any advantages in doing that. Well the system would want to honor the debt of the the the the new system one would think would want to honor the debt of the old system, because that is fundamentally where the network effect comes from. And in practice, what would it mean to be a better implementation of being stuck? It's a better capacity to pay off debt. And so the concept of honoring the old debt is sort of the way to take full advantage of the current network effect of the protocol or a significant amount of it, and demonstrate efficacy in excess of the the the old version, if that makes sense. Now, there's some argument to be made that just the growth of the new system could cause there to be a strong enough network effect in excess of the old system. But there's a question as to whether or not that new network effect is as strong or sustainable as the old network effect. These are things that sort of fundamentally are likely to play out in the market. Yeah, I think you raise very interesting points, especially if this is a credit bears system. So, you know, you create a fork and you just let go of all of your previous stuff and expect, you know, people to move into their what what will you know, why would new creditors trust you at that extent? You can just look again at them and then move on. Exactly. And why would one of the holders of the system want to move over? So I think that if this question best applies to depositors, that's the the short answer is that there is probably some benefit. Well, there's certainly some benefit if the new version of the system is willing to honor the grown stock. So they're basically burning all deposits and then you get these new deposits and there's no opportunity cost there to migrating over. That's probably some marginal benefit. But to some extent, the if you're if you're going to buy into the new system, you do want to buy into the new system within as smart as possible. But the the issue is around dilution where at the individual level, if you're a participant in the new system, you want to get as big a chunk of it as possible before you get diluted from the system getting paid back. But it ultimately makes it such that the system is likely to overheat, right? So if you started zero and everyone's now rushing in to to a very small door, it's much less likely to be a sustainable growth than if you start with a slightly bigger pot and grow from there. So again, it's a question of being stock in many ways solves tragedy of the commons problems and there is some sort of a question as to whether or not that the the tragedy of the Commons in this case would make it such that the protocol overheats despite honoring all of the old debt. Probably unclear how that would work out in practice. But certainly from the perspective of the old being stock, it is in its interest to have people burn their deposits for new deposits in order to minimize sell pressure. Certainly from the perspective of the newbie in stock, it's less clear what is the benefit in terms of the network effect and the likely volatility in the price around having the ability to migrate deposits. But certainly there is some benefit to being stuck. And again, this is one of the fundamental questions that we asked at some point earlier in the discussion, which would have to be answered in the affirmative in order for it to make sense for some sort of forcing protocol to be implemented. And at this point, don't feel like it's it's clear that there is a benefit to the new protocol to honoring the ground stock at the margin. It may be, but it also may not be. And therefore, there's an argument to be made that, you know, it's not worth it to implement some sort of native walking protocol, because, again, the only place where this really makes a difference is on the the silo side of things. It's relatively simple to honor the the state of the debt. The more difficult part it's around facilitating the migration of the deposits. So yeah, it's a interesting open questions here. I would think that there will still be some sort of maybe resistance to all, let's say stockholders moving to the new one. If they were going to lose you know, the their that a grant stock or at least introduce some you know some some sort debt and I would imagine it would be easier to migrate older ones or older stockholders by honoring some sort of you know, will will maintain. But given that you've been there you want to do the switch. But and it was all of this stuff and maybe maybe no one may know the new position as one kid or this is something that is, you know, one value for this one. To expand a little bit more on this now and, you know, bring it from a governance point of view. And I want to think about this. If this maybe, you know, the idea of forking is not negative in general and it could be, you know, maybe even a point of strength on sort of being stuck. So one of the reasons and maybe one of the main reasons why shorting happens is not the only one. Maybe it's not the main one, but I would say it's one of the main ones is that there is a disagreement in governance. People want to, you know, go different directions and hence you get a fork, which, you know, each fork thinks that they will run or manage that fork in a better way if that bill does implement this, you know, peaceful transition way. And in a sense that, you know, any fork can happen and then participants can switch and migrate between one fork to another. And and the example that we gave when it comes to the stockholders, you can anyways do that. You don't really need that this organization there are advantages. But anyways, you can accept, you know, some of the system that entered the system. So you have that ability to do it. If the forks or you know, peaceful to each other where one person can switch from one to another, doesn't that more or less contain all of the flawed scenario into one big, you know, ecosystem? So does it really matter? Where are you? It does matter to an extent, but then the total shock value would be the total value of all of these forks, just given that they are all, you know, they can be they can move from one to another, It well, there is there is a network effect here such that it's unlikely that there are a bunch of different being stocks all issuing the same assets. You could make an argument that the market may prefer to have different bean stocks issuing different assets of different denominations as opposed to a single being stock issuing assets of different dominant denominations. We would probably disagree with that idea and think that the network effect around credit is pretty strong, such that it's better to have a single system that socially everyone opts into. But but the market may decide it's better to have competing credit or systems of credit. And from that perspective, you could make an argument that it's all the bean stock ecosystem and therefore it's beneficial to to who is. I guess the question and from the perspective of a pod holder or a shareholder or a stockholder, the real question as to who it's beneficial to is around financial value. And the key here is around creating a system that is most likely to remain credit worthy, right? Beanstalk is a credit based system. And so the fundamental question is around creating system that is likely to remain credit worthy. And from that perspective, if you consider that the market is at least going to test out a variety of different competing versions of the system, there's certainly an argument to be made that the system should be optimized around planning for that. Now, another aspect of this discussion, which we haven't really spoken about or considered thus far is if the underlying network itself, forks So let's say that there are two versions of Etherium that now exist. There is an open question as to when will being stop should operate such that there is not a fork in the network effect of being as an issue of money or a system to this is how being should should operate in a multi-chain environment where the network effect around being stopped remains in place. And so, yeah, this is a very layered, sophisticated question that is not going to be answered so simply. But to neglect the question would be a total mistake. Okay. We'll take a question from from thinking of it and their discussion or the question is regarding governance, mainly on maybe vote for the position. And they highlighted how some, you know, stockholders have grown stock and, you know, that's because they're not active or participating and then they're thinking or their question I would maybe I'll try really to sort of I don't Mismas most summarize it so in the context of recent governance discussions and considering being stuck is now six months plus three planned, was it not be helpful for the data to start to reflect on how much of an advantage Android assets have in terms of both vesting and governance power plus seniority and how that may well may very well impeded. The appeal of the protocol to new LP is in the final. So they they didn't continue on saying that instead of a fork why not required unripe asset holders to opt into either taking vesting but forsaking their stock and seats or retaining their silicon seats to keep the governance power plus in it, but give up their claim to vesting. What are your subscribers? So this is exactly where at the margin if you stock's had a since says instead of a for this is why a forking system make the most sense because you can now deploy a fork of beanstalk where all the unripe and ripe asset holders can opt in. And so the system now moves over to this new rule base and the unripe asset holders may not move over. Only the ripe asset holders may move over. All the debt is maintained. But the point is that if the thesis is correct that the unripe asset holders are holding back the system, and because of the way that the system is currently structured, they have a significant hold over the governance of the system. So they're not going to create opt in, they're not going to vote with a majority for a rule change that diminishes their their ability control the system they have it captured, and therefore the system to stop this type of forking mechanism is exactly what would allow for the minority of governance holders, but perhaps a significant amount of value holders in the system to migrate over to a new version that they think would be competitive with the current version that they think is captured by the unripe asset holders. So this is in practice exactly why this type of discussion is important, because perhaps this is the way that it's most likely to have a rigorous competition around the model itself. But the highest likelihood that participants in the system ultimately get paid okay, on purpose, what are your thoughts and candidates? So now maybe you touched on why an advantage of having an offer could be, which is, you know, to do this and then to set out to see what the market wants. But what are your thoughts in general on, you know, on the asset holders and the sort of the comments they have slash the best thing and maybe the senior something up. So stockholders, they succeeded or they are running a fundraiser. They managed to raise whatever amount that is currently raised and it is this amount that is it is just providing liquidity and providing, you know, the perfect cover for being is why they have, you know, stock. And that is as a percentage or as, you know, size or scale according to how much was raised, do you think or see that there is anything unfair about you know, the current structure? And maybe also, what are your thoughts on it being inhibiting or impeding any new participants? Do you think that this is the case that currently we are not getting new participants because of how much the older ones have accumulated? So fair is not, at least from our perspective, in a in a free world where people can do whatever they want, there is probably not the right metric. And given that the participate in being stock after the exploit was clearly defined, the the the the the Dow is ultimately the thing that was borrowing the money. Right. The protocol is governed by the Dow the the Dow approved the rules by which the protocol would borrow the money from the market. And so anyone that is lending to the system or then participating in the system after the system was replanted understands or certainly has all of the resources available to them to understand exactly what the rules of the system that they're opting into are. So that's fair. But don't think that beyond that, it makes sense to make any sort of value judgments on the fairness of the rules of the system. Instead, want to talk about the second question, which is based on the rules of the system. What are the current incentives, incentive structures created and how does that affect the system, and are they good or bad? The there's a an interesting point that guy made recently, which is that the unripe asset holders are also owed by bienstock similar to our pod and ferred holders are owed by the system and typically, or at least from a principal perspective, being stock tries to make it such that only the value they can leave the system immediately is in charge of governance. There's some aspect of being able to leave freely that makes you most likely to be a good governor of the system that you're a part of freely. Whereas if you are owed something by the system, it's your views on how the system should grow or change are somewhat. Now, I think that this principle must apply here as well, and it's important to recognize that compared to the value that based on the rules of the system, compared to the value that can be freely removed by depositors compared to the value of the the stocks that they exercise in governance is greatly disproportionate at the moment. And there is some incentive there that they get. They get an outsized number of voting power such that they are encouraged to get themselves paid. Now, at this point, why not have the pot holders or the fertilizer holders participate in governance? So to to some extent, I think there's a very valid argument that from a philosophical perspective or a theoretical perspective, it doesn't it doesn't bode well for bienstock that a group of stakeholders in the system that are owed by the system are hold such a significant portion in governance or any portion of governance for that matter. And there certainly an argument to be made that only only the ripe asset holders should be able to or not even the I don't think it's the ripe assets. I think it's just the the normal assets according to the Bienstock lexicon, it's just the normal assets being being three of the people that have deposited regular assets in the silo. Those are the those are the primary stakeholders in the system. There's certainly a valid argument to be made that that that's a better system of governance. I don't don't know how true that would be in practice, given that effectively you have to assume that the the participants that have come in after after the exploit are largely new participants. And there is some question as to the Dow that got the system restarted continue to have a significant amount of influence on the system as opposed to the Dow getting the system restarted and now immediately ceding all control of the system to the new members of the system. So from that perspective, feel like there is probably some sort of nice balance between the old Dow members and the new Dow members having joined control of the system. And at that point, once you grant that, that's really the way that things need to be. Then there's a question of, well, given that the current system does do that according to some rules, can those rules be improved? I'm sure they could be improved at the margin, but they probably do a pretty good job of aligning the incentives. And it's to some extent just a question of where in these arbitrarily defined terms we currently are at the moment from where in the incentives created by the arbitrarily defined of course, are we at the moment. So yeah, experiencing perhaps a little bit of inefficiency in the system itself, but it's hard to it's hard to imagine. It's it's a really significant marginal improvement that can be made around straddling the old down members and the new down members because you just need to make some sort of decision around what accounts. That account. They're their their ownership of the system and contributes to governance. And no matter how you slice it, it's not going to be perfect. So at that point it's like, well, how are you going to slice it? It was already decided how it was going to be sliced to re to re rejigger. How it's going to be sliced is probably suboptimal, but, you know, or at least a suboptimal use of time, we should say. And I think if you had follow up questions, you can type it or Twitter, Jonathan says you can continue continue the discussion. Otherwise. Well, most of the next question from Turbo and Turbo ask How are devs hired and Anonymous that environment? It appears there's a lot of interest. Some people working with the. But how can one trust these people have the right intentions or that's the only way to catch bad actors? Probably you can answer it honestly. Also maybe sort of chatters here. He can come on stage and share some some of this or some of those first thoughts. Yeah, I was was going to ask if Chad wanted to come up here and give an answer. If not, we're happy to give an answer, but feel like they're they're doing a lot of the hiring and also a lot of the communication with the auditors. And therefore, they're probably a great person to answer this. What's up, everybody? Yeah, great question, Turbo. So I think there's there's two components here. The first is on the hiring front and figuring out who we decide to collaborate with. And the second is around how are we verifying code before it goes out, so to speak, to the first one, think to zoom out a little bit. It's important to remember that everything that we're doing is open source. And so at the end of the day, anybody can come contribute to the code base, whether that's on the front end or on the subgroups or even on the protocol. And I think, you know, at the protocol level, there is a fairly clearly established process in terms of pushing code updates to the protocol. And and that's the bit process which will probably continue updating. With respect to the rest of the stack, you know, I think developing a process by which other developers can contribute to that code autonomy ously is something that we're we're looking towards. And as it works right now, you know, ultimately anybody can come submit a PR and folks on the Bienstock Forums team will take a look at that code and decide whether to merge it in. And we've actually had a number of contributors, including some folks who are here on the call tonight who have just you know, we've found out about that way. The point being is that, you know, with with all of the code being open source, ultimately we invite a pretty wide range of people to come contribute in terms of how we hire for being staff form specifically, you know, happy to address that. I think it's a little bit more nuanced, but ultimately, we're we're interested in working with anybody who, you know, has worked in Defi and wants to help build Beanstalk. And there's a whole lot of ways in which people can can help in that regard, I think, with respect to bad actors. So there's really a couple layers of of protection here and obviously always something in terms of security and other things that we want to keep a close eye on. But ultimately, I think we have, you know, a system that's that's in place now that puts a good number of protections on things. So at the first layer, when we're looking at upgrades that are going to happen, in particular to the protocol, we spend a decent amount of time as a team sort of bouncing ideas back and forth and often reading over specifications before things begin development. So typically there there is some shared understanding of how features and other things should be built before before, you know, a developer starts writing code. I think the second sort of extending on that is that often developers will will pair up to write to write code. So it's not, you know, sometimes there are people who write things independently, at least in the initial version, but very frequently were were were collaborating. And so I think that that reduces the, you know, potential surface area for for problems from there once once anything is completed and, you know, it depends to some degree on what the code is affecting. But we we do team code reviews. So particularly over the last couple of months, we've really started to hone our process in terms of, you know, before any code even goes to an auditor, how do we share it amongst the team? What is a code review process look like? And I think, you know, the the conclusion we've kind of come to, particularly in the last couple of months is that those that process needs to be pretty detailed and so, you know, myself and Publius and Breen and other folks who have worked on the solidity contract side have spent a lot of time reviewing each other's work and really getting into the weeds and have found that even when, you know, even for the best developers, it's good, it's good to have, you know, input from other folks. And we find a lot of really interesting improvements that we can make during that process. And then I think finally, you know, all code that hits the you know, the head beanstalk is going is audited by is audited by somebody and sometimes by multiple people when I say hits. Beanstalk right now I'm referring to specifically, you know, contract upgrades that go out in BIPs and then also other, you know, components of the beanstalk ecosystem that Beanstalk farms develops like wells, for example. And you know, there may come a time down the road where we also do continuous audits on other pieces of the infrastructure like the the SDK and the UI, but right now focused on the solidity side and we work pretty closely with auditors to really get in the weeds on, you know, every level of the code. And a lot of that also comes down to the process of preparing documentation of how the code is expected to behave ahead of time and then, you know, walking them through that. So I think the I know it's a bit of a long winded answer, but I think the combination of all of those things together gives like a pretty, you know, pretty good coverage of, of of, you know, making sure that good code makes it makes it on chain. I would just add that in the context of building composable technology that ultimately modifications and additions to what is being built are likely and it's ultimately up to the users and the user interfaces to ensure that the versions of the contracts that they are using are safe and from that perspective, there's not much more other than audits and potentially multiple audits that can make it really easy for users particular to verify that whatever they're using is safe. And so to some extent, at the end of the day, getting all of this code audited by one or more auditors is very important to creating an environment where users can verify for themselves, even if they're non-technical, that the the code that they're interacting with or the contracts they're interacting with have been vetted, are safe, as safe as they can, they can check for themselves to add one more thing to that. This we'll talk more about this in the meeting on Thursday. But Beanstalk Farms is working to engage additional auditors to help kind of give a a spread of folks who are looking at Beanstalk and we have a new auditor who's working on some code starting this week. So I think that's, you know, another way in which we're trying to keep more eyeballs on this thing and, you know, never have it be one one individual who ship in code. Yes. Thank you, Rachel and Tobias, and maybe one, you know, one thing to note on is that these are firms as as stocks as it has them. You know, since day one, it wasn't long ago when there were not only add ons, but there was also voice moderators. So we've gone we've gone almost a long way or have come a long way since the good old days and good old days and good, pleasant days. And, you know, to the future as well. We have a minute and we have a minute or we can spend a few more minutes. Let's see if folks have any any questions that they would like to ask before we end the press. All right. Thank all for joining us today. And probably a thank you for taking the time to after this discussion. Chad, thank you for coming in. And to those who are joining us, if you have any questions on our on how can you contribute or add to the development of them so you can reach out to the side of Chad or to guys who are with us here. Thank you all for joining us again.

https://www.youtube.com/watch?v=svRNuqKBcEg