All right. We can go ahead and get started here. Thanks, everybody, for joining. Just to recap briefly, so the goal of this call is to dig into some of the the tactical requirements for deploying things like a new being pool or new being LAUSD pool in the short term, and also to talk a little bit about, you know, the the progress on wells and how that relates to prioritization around these sorts of things.

So, yeah. Feel free to jump in if you have any questions. I'll try to just like keep the keep the discussion flowing here and otherwise. Yeah, let's just get into it. So maybe we can start with with Publius. Publius, you want to talk a little bit about, you know, specifically the requirements for creating something like a new a new pool and help folks understand kind of what goes into that.

Happy to. And so guest just to briefly touch on, you know, kind of what the options are for new pools. You know as as you know, most of us are aware when it comes to deploying a new pool on a dex. You know this is normally a permissionless action. Permissionless in the sense that anyone can go ahead and deploy a liquidity pool with whatever tokens they want to have in their the, you know, the main dexs we've worked so far, you know, being stuck has somehow incorporated, having been uniswap v2 being stuck initially launched with it being if pool on Uniswap v2 pre exploit.

We also added a being three curve meant a pool and a being LAUSD playing pool. It's important to note kind of the distinction between a playing pool and a meta pool as it relates to curve, because how the pools function and the amount of, you know, the work that will be required to implement any of these pools to be in stock in any way, you know, varies.

So just because Beanstalk currently supports have been three curve pool doesn't mean that if we launch a being LAUSD pool, it'll be a trivial task to get the being. LAUSD pool whitelisted enabled for converts and potentially minting. And so perhaps let's start with talking about in ether and within ETH pool, you know, as stated, being stuck initially deployed with a uniswap v2 beneath pool and now there are plenty of dexs out there.

Most notably, you know, there's the option of curvy to curvy to allows concentrated liquidity and variable fees. But at the same time, you know, it's unclear how beneficial that is to being stuck in its current state and thus, you know, logically it would make the most sense to probably proceed with the Uniswap v2 pool. Some things to note here Uniswap v2 pools are forced to use a 0.3% fee and 0.3% fee is fairly large, especially compared to the existing 18 three curve pool and what this means is that converts and arbitrage operations both above and below the peg, are likely to be less attractive to, you know, silo members and, you know, any sort of

arbitrage operators because of the additional fee. However, you know, Bienstock survived for, you know, months with the point 3% being if you know pool. So don't think that's very significant in terms of the technical work to incorporate a pool into Bienstock. There are three different, you know, kind of ways in which a pool can be whitelisted, you know, the first of which is whitelisted for siloed deposit in order to be whitelisted for siloed deposit, Bienstock must be able to calculate the value of a given token in being.

This is, you know, most notably done through the use of a BTV function. And I guess to talk a little bit about what requirements for for an Oracle are, you know as as we're well aware, you know, the majority of the being community is aware by this point. You know, when it comes to oracles, we have to make sure that they're flash loan resistant.

And as the merge has recently occurred, it's important to also consider, you know, potential multi block MEP exploitation when it comes to the oracles available in a uniswap V2 pool. Uniswap only stores a cumulative balance. A cumulative balance basically is when every time someone interacts with the pool, the pool will add the balances before that operate edition times the amount of seconds have passed to the cumulative sum and essentially just stories are running some of the price in the pool every second.

This is a arithmetic. You know, it can be used to calculate arithmetic. Smart means and this was used for minting when it came to calculating the BTV of a B in a token before the exploit beanstalk used the system where it and I guess maybe it's helpful to compare that to curve and what is eventually in store for wells.

So just to reiterate that the Uniswap V2 pool is only capable of reporting an Oracle in the form of a cumulative balance, which means in this pool we can do two things. We can determine what the balance in the pool is now, or we can snapshot the cumulative at some time, snapshot the cumulative at the meantime, and calculate the average over that range.

What's significant here is there's no natural way to calculate an instantaneous flash loan resistant price, as in order to use the cumulative balance. Oracle we have to snapshot it at some previous time. That should be relatively recent. In the past, in order to make sure that, you know, in order to make sure that the Oracle price doesn't deviate too far from the spot price.

So now maybe let's jump into curveballs. Curveballs initially were deployed with two different types of oracles. The first oracle is the cumulative balance. Oracle, which is it shares in common with the Uniswap v2, Oracle, the second Oracle is the last block price Oracle, where it looks at the reserves at the end of the last block, creating flash long resistance as if someone were to manipulate the prices in this block, then the last block price wouldn't change.

However, this does not in any way create any sort of multi block exploitation resistance because it's only able to look at the the last blocks price, not some price that's averaged over a longer time frame or from a previous block before or last block. So multi block envy is still possible to manipulate last block price or last block balance.

Oracles as you know say someone was able to propose two blocks in a row. They could just perform the by operation in the first block. Then when the second block gets mined, which they also have control over, meaning they can make sure that no transaction that would sell in that pool gets into that block, someone could perform a operation that reads that Oracle, As the Oracle price is still in a manipulated state, the Oracle result will be manipulated and then the person could sell back down, completing the sequence of manipulating the price, performing an operation and putting the price back to where it was without the ability for anyone else to perform a transaction.

So the current pool has the benefit of being able to use this like last block price. But in the long term, you know, kind of time horizon, it's still not very feasible to use as an oracle for everything, given that it doesn't allow us to use multi block or it doesn't provide any multi block MF resistance. So when it comes to kind of wells, the idea is that oracles will be able to be permissioned Lindsley chosen when a pool is being deployed, meaning theoretically any oracle could be attached to a pool and you know, the whole beanstalk community has done a great job of discussing what multi block MF resistant Oracles would look like and

how come we can or how this can be obtained through wells. And, you know, so Wells, you know, hopefully will be able to solve this kind of Oracle problem that has plagued existing dexs on layer one right now. So I guess now that that know kind of you know, you, you know, an overview of kind of the state of curve, I guess one more thing that's important to note about curve so curve at some point upgraded their factory contract to a version two and the original contract people are only able to deploy meter pools in the new contract.

People can deploy better pools playing pools. And there's another contract that allows for there'll be two holes. What's extremely important to know about the new factory is when the new factory was deployed, all Oracle functionality was removed from the pools. What this means is if someone you know, you know, if a pool is deployed with the new factory, it's not going to have the cumulative balance.

Oracle or the last block. Oracle, which means deploying a plain pool that's capable of being able to mint isn't necessarily be within the realm of what's possible, at least through the base functionality of curve. Given that the Curve Factory does not include any oracles with the original being three or four and the being three curve pool deployed at Replan, we use the old curve factory because remember that allows anyone to deploy menopause.

So for a menopause like a B and three curve menopause, the old factory can be used. However, in the case of a being LAUSD pool or being if pools deployed through curve, the oracles will not natively be included. So now to jump in to kind of what's required to whitelist and use the pool and bienstock going back to kind of the silo, it was mentioned that in order to whitelisted token into a silo, we need a PDF Oracle and a BBVA Oracle needs to return an instantaneous flash loan and multi block MFA resistant value in order to be fully secure based on the current understanding of potential attacks or manipulation on oracles.

So therefore exploring kind of the options of what we've talked about, it should be noted that neither Uniswap v2 nor Curve has any sort of multiple MEP resistant measures in place, which means if Bienstock is going to potentially whitelist one of, you know, another pool that uses or, you know, an LP token that either uses curve or uniswap.

So, you know, vulnerability and susceptibility to multiple MMV attacks will still be possible. Now given that, you know, the cost of an MEP attack is very expensive and requires, you know, you know, kind of some probability to go in your favor. It also would require someone to be able to acquire a lot of beans while simultaneously crashing the price of being in order to inflate the value of an LP token.

In terms of being so kind of from that context, you know, if a being if if a new pool were to be created with being whitelisted into the silo, you know, either new additional risk or additional kind of protection variables would need to be added to prevent MSP, multiple MSP manipulation, or it will have to be kind of risk accepted by the Dow overall, which is never ideal to to discuss the state of development or I guess, you know, now moving on to convert convert oracles have historically used the instantaneous value and you know, whether it will remain on instantaneous value post wells is a, you know, a topic for discussion and but you know,

currently any pool that exists is capable of returning the instantaneous balances in the pool and thus convert can be done in any pool assuming that we're we have an oracle to compute the price of the other asset in terms of dollars. In the case of the beneath pool, what this means is we would need a way to determine the price of ETH in dollars.

Now this can be done using uniswap the three pools uniswap v2 pool, chainlink, whatever. In the case of being USD pool to enable converts, we will need to be able to determine the price of LAUSD in a dollar. This was going to be done pre exploit through the being or the el USD three curve curve pool, and it can still be done that way when it comes to minting.

We need are Bienstock needs a way to compute the average balances of the pool over the course of a season, which is possible with a cumulative balance. Our call, which both the original Curve Factory and Uniswap v2 support. However, it should be noted that neither of these Dexs have any sort of multi block MF resistance built into their oracles.

And you know, maybe to discuss what multiple MF resistance might look like is I think Uniswap V3 is a first is a good step in the right direction where they use a geometric mean instead of an arithmetic mean when computing Oracle balances, which is something that will be discussed and looked into when building wells. But in general and you know, geometric means caused outliers to be weighted less when it comes to actually computing the mean.

So the effect of someone performing a multi block MMP on a T swap is much lower when it comes to a geometric mean. You know, it should be noted that with geometric mean oracles, you know multi block MF manipulation is still possible. The effect of it, it's just dampened by the geometric mean. Some other things that can be done are setting rates on how quickly the Oracle value can change.

Maybe, perhaps a rate is enforcing the Oracle value can only change 10% a block or something or 20% a block. And again, this is some this specific safeguard is something that has never actually been implemented in an on chain Oracle. But, you know, kind of a combination of, you know, this rate of change safeguard with a geometric mean, you know, is what starts to get us into a place where it looks like we might have potential protection against some anti block MEP resistance.

But just to reiterate, you know, both Uniswap V2 and Curve have no safeguards at all. Maybe just a touch on Uniswap. The three, you know, because it was mentioned Uniswap V3 Liquidity positions are tokenized as NFT is instead of ERC 20 tokens and thus in currently the silo v2 and Bienstock only supports whitelisting of ERC 20 tokens. So in order to use a Uniswap V3 pool, the silo would either have to be upgraded to support NFT is or somehow uniswap V3 would need to be tokenized into an era C 20 token that can then be deposited into the silo which introduces all sorts of assumptions about where people are allowed to provide range liquidity and

how liquidity is shifted, which doesn't really allow uniswap V3 to be used to its full effect, but nonetheless is is possible. So kind of across the board, you know, any pool that wants full functionality and bienstock needs an instantaneous manipulation resistant oracle in order to be wireless into the silo. Currently it needs an instantaneous balance Oracle to be whitelisted for convert and it needs a cumulative balance or call, you know, or, you know, manipulation resistant oracle to be whitelisted fermenting maybe a little bit to talk about where developments are, you know, kind of past developments in regards to implementing, you know, these types of pools and kind of where that code sits now and how

much work would need to be done. Originally in Bienstock, you know, Bienstock, when it was first deployed, supported a big if pool both for BTV minting and convert that logic exists you know does not exist in Bienstock today and was removed with the replant but you know could be added with some serious work you know re-implemented you know, through, you know, the BnB facet and the convert facet and the season facet.

However, you know, any code that should be added should definitely be thoroughly audited and, you know, should be, you know, you know, thoroughly considered. Whether it is worth adding so much code that may only end up being temporary. And, you know, any time where a lot of oracles are being added, changed, modified, you know, there are the amount of, you know, the potential for risk, you know, exponentially increases given how, you know, Oracle, you know, manipulation is, you know, one of the biggest causes of exploits throughout kind of crypto to talk on the being LAUSD pool side assuming that, you know, the Dow is interested in moving forward with a curve being LAUSD playing pool

curve, LAUSD playing pool, being a stablecoin pool between two tokens that are pegged to the same currency will just note that, you know, LAUSD has not proven to be a great stablecoin in the sense that, you know, its value has really only gone up over the past few months. I believe the price is about a dollar in four sets, but it's unclear whether a playing pool is even a good option to use for being a LAUSD pool.

But perhaps the playing pool with an incredibly low A But it should be noted that LAUSD has not been worth, you know, within a couple of sense of a dollar for maybe a month or so and someone please fact check that, if that's correct. But, you know, when when thinking about it being LAUSD, people want to make sure it's considered, you know, kind of obviously the price invariant that is used in this poor.

So on the development side, you know, when the exploit occurred, I believe that, you know, generalized converts in meeting was days away from being proposed formally. This included you know, obviously are obviously the being LAUSD pool had already been whitelisted into the silo, but this would have enabled convert, you know, in the in the being LAUSD pool. It was still being kind of you know, architected how being LAUSD would fit into minting, given that there is no native Oracle in the pool.

But, you know, nonetheless, you know, convert and silo the code was at least traded. It should be also mentioned that turf pools are very complex and intricate and computing the price of a being in USD through a plane pool and a metal pool is an extremely complex action as we're now taking oracles of two different types of pools and kind of using them together in tandem.

And again, you know, sufficient audits will need to be, you know, performed on the code as, you know, generalized convert as it existed in the pre replant state was never audited. And so you know what you know you know just so I guess on the Beano USD side there is existing work for the BTP Oracle in the convert Oracle that could potentially be re leveraged if properly assessed, reviewed and audited.

And so believe that kind of covers everything across the stack, both in terms of what would be needed for a being if pool in a being LAUSD pool guests to open it now to questions, comments, suggestions maybe hand it back to you chat if you have anything to say. Yeah. Why don't we take a second here to open it up to questions from anybody in the audience?

So if anybody wants to hop up on the mic, feel free to ask questions. Or if you're of muted, let me know. Publius, would you say that generalized minting and general convert, you know, minimums before whitelisting any any pull to the silo? Not necessarily and specifically on the minting front like the ability to mint? Yeah, definitely don't imagine that minting will occur and every single pool whitelisted into the silo going forward.

And you know on the convert side, you know the question gets a little fuzzy. As you know we can all look back on that time period pre exploit when generalized minting was not enabled and you know there was clearly a large uptick in demand for being whether that demand was organic or inorganic is, you know, up to everyone's own fruition to kind of determine.

But there's definitely an argument to be made that, you know, kind of the lack of generalized convert across the liquidity pools led to potential inorganic demand. But, you know, ultimately it's up to the Dow to determine whether it's worth it to add a pool of converting minted or not enabled. Okay. And maybe the second point is, given that I believe most of the Dow that interest is in at, you know, changing the exposure from three curve to it.

So I would I would imagine that the expectation is that if we're going to introduce a new pool, then they want to be able to switch their current exposure. So switching exposure from being three curve to being, if would be possible with being to being eve converts enabled, meaning the standard convert that already exists today would be possible converting from unripe being three curve to unripe being if would be a much more significant overhaul that would probably require the barn to be rewritten from the ground up.

The barn is only written to assume and support that or, you know, as you know, support the assumption that only one unripe LP vesting token will ever exist. So, you know, work to migrate unripe being three curve to being if you know, could be done, you know, kind of atomically if the entire Dao was in favor of shifting all the unripe liquidity into being if but supporting both options as you know, independent, passive, you know, independent options for, you know, existing unripe being an unripe being three cup holders is, you know, a very serious overhaul.

Thank you. And I think I think this is clear. And now Jack mentioned that the main reason we're having this conversation is, I guess some some members of the Dow have a lot of somewhat is on strike of. So I would imagine, again that the expectation is if we're going to introduce a pool that farmers want to be able to switch, switch that exposure.

And as you said, that's that's a lot of work. Awesome. Maybe. Do you want to go to to Bryce? Bryce, are you with us? Yeah. Can you can you hear me? Yes. Awesome. So, yeah, had I only sent more like to food for thought kind of kind of things. And then do with that with what you may. Let's see.

So the first thing is right now liquidity is realizing there is a serious need for a new is these based liquidity instead of stable swap against all the stable. And so kind of just waiting that here you know you have your plans but maybe there is a way to kind of make the to convert. So we're going to put some efforts to other end in the coming months week.

And so, you know, if one way or another, the bean integration is also achieving something that kind of this that could be of of interest, let's say. And the second thing is I can't remember when, but like a few weeks ago, some community members from beyond reach out about a potential the chicken bonds for. So I don't know if that rings a bell for for B so I just wanted to check out on that like have you guys give it it all salt all What's up with it?

Yes, I know some community members have been interested in the chicken bonds model and looking at how that might work on the beanstalk front, I think Bryn in particular, who's here with us, has spent some time on that. Brian, I don't know if you want to comment on that briefly, but definitely, you know, open to having a conversation about that that as well.

But probably want to stay focused on on the pools here. Yeah, we can talk about it, but I don't think it's 100% like on topic like you said right there is solely like community driven and not flowing from being stock forms. Right. It's really being about initiative. All right. So just narrow that down and then maybe we can all have a chat sometime soon.

Yeah. Yeah. So I guess here regarding the pool, that my main point is really around this is the in and yeah, thinking about how essentially liquid your wife instead of you know stable swap liquidity against all the stable. We kind of have enough of that for now this is not what's going to help us to pay so we're more looking in our if there are more X times y, One key type of distribution is LAUSD or some slightly adjusted flavor of that, if that makes sense.

Got it. And you're saying that's specifically what Liquidy is interested in at this time? Yeah. And so that's the kind of thing I guess, where we'd be much more easy to align, you know, support or I mean, will support, of course, you know, you're building something on top of a That's really cool. Maybe I should start with that.

Thanks to you guys to actually take this seriously and not be like the other projects going for you as CEO or, you know, things like that. That's obvious. I think, but still worth noting. But yeah, so I guess my point is more, you know, I would typically be able to allocate more resources to that align toward this goal of diversifying liquidity in that direction.

For us to Great. That's that's certainly helpful to know. So thanks for for adding that context and yeah I mean I think we should stay we should stay in touch as the Dow considers sort of the path forward here, particularly if we, you know, decide to launch a LAUSD pool, we should we should be in touch. So, yeah, I'll reach out to you.

Awesome. Thanks. Great. Maybe any other questions in the audience on what Publix was discussing earlier? And can you guys hear me? Yes. Uh, got well prepared. Thanks for that explanation. And I guess my question would be it sounds like there would be risks to pushing out new code, especially pushing it out quickly. Can you give us a feeling of just your sense of which option you would have less net risk for being stuck there?

Just talk a little bit about that, because obviously we wouldn't want to vote for something that introduced more risk vectors. So I'm just wondering what your thoughts are there and what options, I guess, of the ones discussed. You know, likely a uniswap fee to pool, you know, specifically with ether, just because that has been implemented on may net before it has been, you know, audited and you know, you know, it would be likely easier to reuse that code and and there's just in general less code you know that be so you know, from a pure security risk perspective that would be the best option.

But that's not to say that, you know, a uniswap fee to be an LAUSD pool wouldn't only be slightly more difficult or risky, you know, kind of when it comes to curve playing pools, you know, kind of in the case of being LAUSD playing pool, you know, that code has never been deployed. I mean that before. You know, some of it has been written for convert.

But, you know, that definitely introduces slightly more risk. Okay, great. Thanks for and maybe extending on that briefly published, you want to talk about kind of what the sequence of of things to do would be to ship a Uniswap V2 pool again, particularly with respect to, you know, reusing existing code and that sort of thing. You know, first step is, you know, would be to deploy the pool and seed it with some base liquidity and then, you know, propose a bit to do any of the, you know, any combination of the three, whether that's whitelisting into the silo convert or minting in terms of what it would take to get the code ready from a

development perspective, you know, kind of first step would be implementing the silo BBVA, Oracle and this would likely you know kind of are a good place to start would be to kind of go pull the beanstalk code pre replant and look at how the BDP function for the Uniswap LP token in that code was performed and try to copy over some of those libraries when it comes to convert again, pull the pre replant beanstalk repository and look at the kind of convert facet and take the, you know, basically take the paths for being able us or being if to in from copy and paste those over into the current convert logic and then for minting

you know copy over the oracle that was used pre replant incorporate that into the existing one and just make the existing oracle add the result of the two oracles together. And you know, at this point there should be kind of three different pieces of code that were added to the existing repo, the first of which is just an upgrade to the BDB facet to include a view function that computes the price or the value the PDP of a, you know, Uniswap LP token.

The second is to new convert types to convert from being to being Eve and from being Eve to being will just say that a lot of that logic is incredibly messy and don't believe that the upgrade to generalized convert from just beneath was ever audited. But it's probably likely to better to start with the generalized convert logic copy to send over that commit hash.

Probably going out to do some digging to find it. If anyone is interested in pursuing development on this issue. And similar for minting, you should. You know, I guess the third piece of code would be upgrading, you know, the Sunrise facet to incorporate both pools and maintain these storage reference variables to the old oracle that was used for beneath pre replant still exist and those references could just be kind of re re you know, reused in the beneath Oracle if it was implemented.

The exact same way. You know kind of the final piece will be upgrading the existing oracles to account for any multiple lock and MVP resistance when it comes to minting implying the same cap that was applied on the being three curve pool might make sense here and you know, happy to discuss kind of, you know, potential options for the for the the BTV side off line but guest just in general to discuss how the beneath Oracle currently or worked tree replant and so in the being pool as mentioned earlier there is no oracle to determine the balances of the pool at the end of the previous block.

So what the beneath oracle does is it first checks if the pool has been used in the current block, if a pool has been used in the current block, if the pool has been used in the current block, then it uses that to top over the season. So far, if the pool has not been used in the current block, it uses the instantaneous values and if it the season, the sunrise, there's this weird edge case where if the sunrise occurred in the same block that the person is depositing and there was a swap in that block, then the transaction won't allow execution to happen as there is no way to kind of compute any sort

of historical value. You know, plenty of options here. It might make sense just to use the to swap over the entire season so far and, you know, not allow, you know, deposits to occur in the first two or three blocks of a season or to incorporate that Oracle resistance again or, you know, I guess truly not an ideal solution.

But given that, you know, the Oracle the only Oracle available in Uniswap V2 is, you know, an arithmetic cumulative sum, it's hard to kind of, you know, speculate on what other good solutions may be to the multi block MVP problem. So in terms of development time, how does this compare to issuing wells? And just switching over to wells, what was the question?

How difficult would it be to switch over to Wells or how much work is that relatively? Yeah. So I think, you know, the question the DOE has to look at is, okay, how long will it take to build out this being a Uniswap V2 pool versus, you know, how much more time we're looking at just to finish wells and use a switch over to that, which seems to be like the final solution to this problem thoroughly.

So I guess just to talk maybe a little bit about the state of Wells, the core well, functionality has been finished for a long time. You know, the core well functionality being able to add, remove liquidity and swap the Oracle logic, which are these pumps that have been discussed that can kind of be permissionless Early added to wells is also, you know, pretty much wrapped up at this point, which means what is remaining on the Wells side is the kind of the three pieces of code that were discussed earlier where, you know, the ability to, you know, support well tokens as stylo deposits, the ability to support well tokens for convert and the ability to

support, you know, minting in wells. The plan for these three pieces of code were to generalize them as much as possible, such that they would only have to be written once and thus, you know kind of when, you know, we you know, wells could kind of be moderately added to kind of, you know, silo convert and minting all at the same time know and kind of that that level of generalization will require, you know, will take significantly more work than just like a base implementation of, you know, BTV for, you know, siloed, depositing, converting and minting.

If the Dow is interested in, you know, releasing a build maybe only supported convert in silo white list for specifically just the beneath pool you know that might be able to be extradited. But there's also another kind of topic that was recently brought up for discussion within the community, and that's the matter of should wells exist within the Bienstock Diamond or exist as independent contracts as currently implemented Wells Wells would exist in the Bienstock Diamond and thus all tokens stored at wells would also be stored in Bienstock.

This introduces significant gas efficiencies, but also introduces potential security risk as one Bienstock is an upgraded contract that is currently controlled by, you know, a MULTISIG and two, you know, if there was an exploit that allowed funds to be stolen from the Bienstock contract, then all of the tokens in the wells would be able to be stolen. In the case where wells exist as separate contracts from Bienstock and if the LPI tokens are not deposited in the silo, they would not be able to be stolen if there was a way to basically extract all the funds from Bienstock as we've seen in the April exploit.

You know, however, anyone who adds liquidity to a well and then goes into deposits, those LP tokens into the silo and you know, there's no difference in regards to that person's or I guess those funds as if the LP tokens can be stolen, so can the, the actual balances of tokens in the wells. So if, if you know the majority of LP of well tokens are going to sit in being stock anyways, there's marginal benefit to separating the wells out as external contracts.

However you know, you know, we have seen several events pop up. Obviously in April there was an exploit. So it's it's very you know, it should definitely be considered by the Dow overall whether, you know, kind of the general sentiment is to have wells be external contracts that are going to, you know, be, you know, maybe 20, 30, 40% more expensive from a gas from from a gas price, but introduce at least a marginal additional security from the fact that people who add liquidity and don't deposit the you know, the LP tokens have feedstock will not, you know, be able to have their funds stolen if there is the next way.

And bienstock again if the Dow wants to consider, you know, continue forward with the path of leaving the wells and bienstock you know then, you know, spitting out some sort of solution to whitelist the beneath pool, you know, can be done quicker. But if the well once or if the Dow wants, you know, you know, once the general community wants to consider decoupling the wells as separate contracts, then, you know, they'll be at least, you know, several weeks of work required to separate that out.

You know, so a lot of considerations still to be made on the Wells side and kind of I guess the you know, kind of the options are, you know, trying to push out a MVP P, B being if well, that's not as abstracted and generalized as, you know, ultimately Wells should be versus just waiting for the full well implementation and spec to be ready.

And then the second question is, you know, continue forward with Wells as a part of BIENSTOCK or move wells to external contracts. So those three things that you listed in the beginning that need to be done to add wells to the silo, there's also need to be done for the Uniswap V2 pool if there were to be a being ether pool, correct?

Yes, Correct. The one point that was noted is you know, that logic has previously existed and thus does exist in some form, but definitely adapting it to the current bienstock is going to be, you know, a non-trivial amount of work regardless. But you are correct. So just curious how what kind of time estimation would you put at doing the work for the Uniswap pool versus the MVP of being ETH with Wells?

Apologies? What was the question? Yeah, sorry. The question is basically how much time would it take to get like an MVP of Wells with being it versus an MVP of the Uniswap v2 with Beneath? You know, development times are always incredibly difficult to estimate and you know, would argue on a relative basis, you know, probably getting the wells ready is going to take, you know, probably to x the amount of work that would require to get a uniswap beneath pool going.

You know how much work that actually is is obvious. It's incredibly hard, you know, to estimate that given, you know, there'll be at least, you know, probably between you know, you know, probably 2 to 3 weeks of dev work for the beneath pool and then it will need to be audited for, you know, probably somewhere or, you know, up to a month and then, you know, a week of friction and maybe a bit.

So regardless, you know, just deploying kind of any code to bienstock is going to be, you know, potentially a multi-month process regardless just if, you know, obviously, you know, only if the Dow, you know, cares about making sure code is audited, which is, you know, probably a good standard to to hold. But, you know, just it's hard to move fast regardless, as you said, given basically an eight week minimum to get the Uniswap V2.

I'm curious, what are our backup options if USDC starts to fail? You know, we wake up tomorrow and it's 99% of the curve pool three core pools with USD, then how can we preserve the value that we have invested into being stuck in its current form? If tomorrow, you know, you asked is 99% of the curve pool, then you know, 99% of liquidity will be with, you know, USD two, you know, in the short term, you know, ways to mitigate that, you know, given the majority of liquidity currently sits and you know, erb being three curve and as discussed, it's incredibly hard to migrate that you know there can you know, potentially other solutions to

maybe migrate a piece or part of that could be considered, you know, like permanently. You know, we'll just do a one time migration of 50% of the being three gave underpinning urban three curve to beneath or something and then new new fertilizer will continue to create being three curve but you know there'll be some proportional representation of every urban three curve owns you know some proportion of being three curve and some proportion of being enthalpy.

And, you know, that could potentially be an option. But then again, it's like without without, you know, introducing new code, you know, moving that urban three curve away from 100% being three curve exposure is, you know, it's hard to see a path forward that doesn't code that entails of a four hour audit also published. I know you need to you need to jump now so wanted to say thanks for for jumping into all of this all this stuff Maybe we can keep the other the other publishers around and continue this continue this conversation.

Awesome. Thanks.

I want to circle back to questions from from Nasdaq from a little bit ago. So to start with, the first one it reads, the main reason we are having this conversation is because of potential USD t d peg risk. Do we have any emergency plans in place if usd t begins losing peg such as perform ex action at USD $0.90?

Are there any ways we could quickly act to preserve our liquidity? Maybe a public If you have if you have thoughts on this, if you happen to hop here in a second. The short answer is at the moment there is nothing to do in theory because the BTM, the owner of beam stock, they could do whatever they wanted to the contract.

But at the moment there's no way to do that in a in a semi-autonomous fashion. And the BCM doesn't have any sort of approval from the Dow to do that, to do anything like that. Generally, it let's play out a scenario where the BIP like a bip was passed to authorize the B team to act in certain instances.

Frankly, not even sure that's something that the BCM would want, like a responsibility that the B team would want to accept. And in such an instance, it seems like the more prudent thing to do would be simply to migrate all of the liquidity somewhere else at one time, and that's what the devil wanted to do. But but at the moment, there's basically nothing to do in theory because there's no other liquidity pool that being traded to migrate liquidity to.

The only thing that could really happen would be the removal of the being trigger from the liquidity pool by the BCM and the liquidation of that curve into either ETHE or USD DE and die or something other than USD. But the point is that this is a very ugly regardless. It's an ugly solution that would require a lot of manual judgment and input, and that's very much antithetical to being dark.

Now, with that said, hard to let it does get in the way of life. And if Usdc did collapse this is a scenario that we we've all considered and spoken about pretty much at length. But just to reiterate, it's unlikely, at least from our estimation, that USD would go to the euro as opposed to trading at some somewhat significant discount to to a dollar, in which case, as Publius was saying earlier, if all of the being trigger liquidity was trading against USD, that would basically mean that billions were now worth whatever USD was worth more or less and it is.

Yeah, that wouldn't necessarily be in stock other than from the perspective that its liquidity was down and now the value that it was trading against was is lower. And I guess in theory in its current state, also the value that it can do would be lower because it assumes the value of the recurve or excuse me, the sense of value of each token under the three curve to be a dollar and.

So yeah, there's no pretty solutions at the moment. And frankly, this is one of the main risks that from our perspective underlies the stock. And that's why from our perspective, there is no time better spent than time spent on the wells to get Beanstalk to a place where it's not dependent on any any single currency to survive. And currently the fact that being straight against the curve, that is the case.

So yeah, would that also have to hop shortly but maybe can take a one or two more questions before the bottom of the hour here. So any questions for Publius from from the audience? So if we wanted to go with a MVP option for a been this pool with the silo, we're going to skip the generalized silo option, but instead just go for an MVP of let's let's get the is well out as fast as possible.

What kind of a time difference would that mean in terms of being a deployed and also would that require a vote pull down. Yeah so ultimately anything will require a bit and a vote from the Dow in terms of upgrading beanstalk to support a given LP token. But perhaps the only thing that at this point really needs to be decided is what is the optimal path forward for us collectively in terms of exact timelines?

Yeah, very hard to say, but it seems like it's the margin is on the on the order of a couple of weeks in terms of doing it on Uniswap versus the wells. And obviously the wells gets us a lot closer to where we're hopefully heading anyways. So yeah, that that seems to be where we're at at the moment.

So it sounds like what this would prefer to do is continue on with the wells, with the more generalized solution for the silo. So from our perspective, think that we're going to continue to work on the wells but are very much happy to support and help anyone else that wants to work on the Uniswap implementation. Perhaps, perhaps it's reasonable to say we're amenable to changing course there, but at least in terms of what what we'd like to spend our time doing, I don't really see much fruit in the Uniswap option.

Awesome. We're going to need to wrap this up in about about 2 minutes here, so maybe we'll take the last last few to kind of summarize everything. Everything here. I guess, first of all, you know, everything's recorded here, so we'll get the recording up. Canadian Bennett can if you could drop that link whenever it's ready, that'd be awesome.

So if anybody wants to review it, there's a lot a lot going on, I guess, to kind of to ask the crowd here, curious if there's any questions we feel like are still are still pending. And you know, I would love if anybody wants to shout those out or write them down, Barnyard Chat, that would be that'd be great.

And, you know, I think this from the beanstalk farm side of things can try to circle back and help get some of those answered. Yeah. So any any questions on the brand remaining on just so we can continue this discussion as well on tomorrow's class to anyone you know think about it and want to continue we can continue the world class as well.

That sounds great. Yeah. Just as a reminder of people highlighted this a moment ago, But you know, ultimately Beanstalk as an open source piece of code and the commit history with respect to previous implementations with Uniswap V2 is still available. And so if there's any developers out there or you happen to know any developers who are interested in, you know, taking a stab at this, there's there's plenty of resources available will certainly require some re-engineering and refactoring to account for all of the the upgrades that have occurred to Beanstalk over the last two six months or so.

But if the if you're interested in doing that, you know, ping ping somebody on Beanstalk farms and we'll help get you get you that information. Awesome. What what's that. Thanks everyone for for joining and hope to see you in class tomorrow.