• Recordings
• Meeting Notes
• How did the idea of Wells come about?
• What will Wells do/ support?
• Who decides what oracles to use?
• What oracles will Wells use?
• What can we expect in Wells V1?
• What are Pumps and Aqueducts?
• When will the Wells audit be complete?
• What will Wells look like that are whitelisted within the Silo?
• Should FERT holders have governance rights?
• Are Unripe Asset holders creditors?
• Transcript

Recordings

Meeting Notes

How did the idea of Wells come about?

• Currently, there are a lot of issues with AMMs, especially when trying to integrate with the Silo. For Beanstalk to use an LP token, it needs a lot of information there was not a lot of that information on-chain when Publius was coding Beanstalk.
• Current DEXs are not very good in Publius’ opinion. They are not able to compete with traditional finance alternatives. Since MEV is in existence it is very hard if not impossible to update your orders. Market makers want to maximize the non-toxic flow they receive. Non-toxic flow can be thought of as any directional trade. Toxic flow has to do with arbitrage. On the AMM there is some type of mispriced and there will be an arbitrage event to bring the price to market value. The arbitrage event is toxic flow. Current market makers have to expect toxic flow in order to get non-toxic flow.

What will Wells do/ support?

• Wells will be able to support arbitrary liquidity pools. There will be any amount of pricing curves and the inputs to the curves will be arbitrary so they can be a wide variety of things such as on-chain data. In practice, there will be no need to update an order unless a trading strategy changes. This will not get rid of all the toxic flow but it will get rid of most. Current AMMs do not use any oracle, and only have one pricing curve and it is based on the ratio of assets. Orders in Wells can function as oracles, but they do not have to be on-chain. There will be the possibility for multiple inputs for one Well.

Who decides what oracles to use?

• Each Well will encode a strategy that all liquidity providers will follow. It does not make sense to have a bunch of different strategies within one Well.

What oracles will Wells use?

• The Wells that are providing liquidity to the Silo will not use an oracle. Oracles will be used for figuring out the price Wells is willing to give in any circumstance. Publius is unsure how deep an oracle should be to interact with the Silo. For example, if there is a Bean:ETH pool and the price of Ether is coming for a ChainLink oracle is that ok for the Silo.

What can we expect in Wells V1?

• The core functionality of Wells. For Wells to integrate with Beanstalk there still needs to be Pumps and Pumps that work with Beanstalk. Publius has started Pumps and the code is getting ready for audit. Pumps are separate piece of code even though they are related. The only pricing curve that will be included is a constant product formula. V0 will support a Bean:ETH pool. Publius is hoping people will create their own trading strategy and create their own orders.

What are Pumps and Aqueducts?

• Every Well will have a set of Pumps, and Pumps will encode data on-chain for other protocols to use. Every time a Well is deployed you will be able to deploy a set of Pumps. Pumps will be very expensive to deploy on-chain so you are only going to want to deploy it once. Pumps will be able to do a lot of various things. Aqueducts are the aggregation layer for Wells. All a trader wants to know is how much Ether can they get for their USDC, Aqueducts help with this by aggregating data across multiple Wells.

When will the Wells audit be complete?

• Publius is unsure, they expect it to be 4-6 weeks long once they get started

What will Wells look like that are whitelisted within the Silo?

• The Wells will employ a Bean price. If you buy 1000 Beans at $1 you will get 1BDV but if you buy at 0.95$ you will get .95 BDV. The Seeds per BDV will be a function of the asset that is held by the LP. This might change over time according to Publius. The Silo will account for BDV based on what the depositor is willing to trade their deposit against. Publius does not think this is a solved problem

Should FERT holders have governance rights?

• In Publius’s opinion, FERT holders are very close to Pod holders and from a game theory standpoint, it does not make sense for a creditor to have governance rights since they are waiting to be repaid. Depositors can leave whenever they want, because of this it would make more sense for a depositor to vote for something that would hurt Beanstalk in the short term but benefit in the long term.

Are Unripe Asset holders creditors?

• Publius thinks that the argument could be made for this. At scale, this is not how the system should work.

Transcript

How's it going? Publius? Doing quite well, Mod. Glad to be back in class. How are you? All is well here. And Sam? I said we had a already some questions about twins. And I was thinking that we maybe dedicate this class and expand on on welfare. That will have it to be the topic of discussion and public.

Maybe we can, first of all, start with how did the idea of hotels come about? What is the problem or problems that you know, was aimed to solve? And then maybe lastly, what were the phases or the versions or the roadmap that we can expect, you know, when to go about? So we know that now it was announced that, you know, wells are being reviewed or the code for Wells is currently being reviewed by contributors.

At a later stage, it will be reviewed by Halliburton and then hopefully will have version one one out there. But maybe we can, first of all, start what how did this idea come about? So there is a a real problem with interoperability in current arms, which Bienstock has experienced firsthand and we've experienced while working on Bienstock in that using the liquidity that is in a uniswap pool or a curve pool for the silo has not been such a simple process typically, and this has to do with the amount of information that is stored on chain in those various protocols pools.

And in short, the practice of very beginning of the need to implement the Bienstock native dacs came from that specific problem that in order for Bienstock to be able to use liquidity in a given liquidity pool, it needs certain information. And that information was not typically easily accessible to the protocol. And given the nature of a curve factory pool deployment, for example.

Even there, I mean, there have been many discussions in the past on adding other liquidity pools and how in particular the current structure of Curv and Uniswap limit tremendously the amount of assets that can trade against billions and be used within the silo. And so that that was the starting point where there was some need to implement, at least at a minimum, a bienstock native decks or a deck that would support natively a bienstock integration such that the the silo could accept the deposits and minting can take place off of the liquidity in the pool and the what that evolved into.

And in our case, we are not really interested in implementing tech that is going to be used one off and then thrown away. The goal is to implement stuff that is sufficiently generalized and of sufficient quality that it's reusable in perpetuity. We don't want to be doing work that is in practice, in the grand scheme of things, meaningless.

We want to be doing work that is helpful to where we're going because there's so much work to do to get where we're going that the question is then how do we get there? And the the Dex is a major part of of Defi and the current state of Dexs in general, aside from just not being particularly easy, will easily integrate ball into Bienstock current dexs are are lacking at best and therefore well, maybe not therefore, but let's talk a little bit about where they're lacking.

So in particular the the decentralized exchange as a concept is where trading activity happens. And if you think about what it would mean for Defi to ultimately compete with Trad by the ability to trade in a competitive venue to a centralized alternative is is a necessary part of the puzzle and current implementations of dexs even the state of the art or top of the line, whatever you want to say.

Curv Uniswap. They are not even close to being able to compete with traditional finance trading experiences and to a large extent this is because of the nature of the networks that they trade on. And there may be two two problems. One is that there's a cost to updating orders, which is expensive for market makers, but more than that, the concept of minor extractable value whereby if there is a potential profit to be extracted by the miners of the network in order to if an order wants it processed or an update to an order wasn't processed or a transaction isn't processed, then in theory, the miners could be the ones that can extract the value associated

with that transaction as opposed to the person that wants to pay to execute the transaction. And so then the question is, well, how much would the person be willing to pay to execute the transaction up to whatever the minor extractable value is? And so maybe you have a happy middle ground where there's some split or fee between the miners and the the users.

But in practice, the existence of MTV makes it such that you really can't update your orders. You're not going to be able to update your order. So if you're a market maker, the this becomes a major problem because from a theoretical perspective, what market makers are really trying to do is maximize how much nontoxic flow they receive. And nontoxic flow can be thought of as directional trades trades that express a direction in the market, meaning people are buying and selling not for arbitrage, but actually to buy a given asset.

Those directional trades are considered nontoxic flow and are the flow that market makers want to maximize exposure to. You juxtapose that with toxic flow, which is effectively arbitrage. So there's some mispricing in a given market relative to the market at large. And toxic flow can be thought of as the trade that gets the market price back to the the or the the yeah, the market price back to the price of the aggregate market.

And if you think about the nature of current amms, they rely on the latter, which is toxic. Well, they rely on arbitrage in order to maintain their price at the market price. So while you can reasonably expect the price that you're getting on curve or on Uniswap to be very, very close to the market price, the way that the price in the pool is actually maintained relative to the market price at large is typically some arbitrage or trading against the market.

So these markets assume or require toxic flow in order to offer a competitive price to then potentially receive nontoxic. But the problem for market makers in these liquidity pools is that the the updating of their orders to avoid toxic pools of the ether price moves on centralized exchanges, there's no actual way for them to update their prices in the liquidity pools on chain without exposing themselves to MMV, at which point they can actually prevent themselves from receiving the the toxic flow.

And so there have been some pretty good Twitter threads over the past couple of months on the toxic flow problem in Amms and in particular how it's really not profitable to provide liquidity to these animals. And if you think about, again, the goal being for decentralized finance to be able to compete with traditional finance, if market makers cannot profitably make money by providing liquidity on decentralized exchanges, it's unlikely that these decentralized exchanges are going to acquire significant amounts of liquidity, and liquidity begets more liquidity, etc., etc..

And so if if the the market makers that are providing the initial liquidity cannot make money, then it's going to be really hard for dexs to accrue the liquidity necessary to compete with traditional finance. So again, the two problems are one, the cost to update orders. But but the real problem is that the orders cannot be updated in practice in order to avoid the toxic flow.

So with this in mind and the fact that it was necessary for a new DEX to be implemented, or at least an updated Dex to be implemented in order to support Bienstock, Wells became a necessary project and with all of this in mind, the basic idea behind Wells or what wells should be able to support are arbitrary liquidity pools.

And what that means is that the prices over which the assets that are provided to the liquidity pool can be exchanged for other assets can a be arbitrary curves, meaning they can have any sort of pricing curve on them, which is a tack that was originally developed for the pod marketplace, but be and this is where the answer to the MPV problem comes in, the inputs to the curves themselves can be arbitrary.

So they can be functions, they can be data on chain data such that in practice there is no need to ever update an order unless a strategy for providing liquidity has changed because the wells themselves should support the ability to encode entire trading strategies in a single well where the the liquidity effectively and the prices that the liquidity is willing to be traded for within the well are changing in real time.

And by real time I guess we mean block time. So whenever a trade against a liquidity pool happens, the trade is obviously taking into account the current state of the network on which the transaction is being mined and it's being traded against the well. And the well itself is also taking into account the current state of the network.

And so there there is, at least in theory, the ability to encode in wells sufficiently sophisticated strategies such that a toxic flow can be for exposure to toxic flow can be deeply mitigated. So it's not to say that you can get around all the toxic flow, but you can get around a real chunk of it. And that's the basic idea behind a wells.

Okay. To this, I'm going to try to summarize what what you just described and what you what you're describing as toxic flow is it correct to call that impermanent loss? No. So to clarify, impermanent loss is the change in the value of liquidity provided to a liquidity pool based on the change in the price of the pool? Toxic flow has to do with the nature of the trade itself.

If that moves the ratio in the pool. So a liquidity provider could receive impermanent loss from toxic flow or from nontoxic flow, but they're actually different. Okay. All right. Let's let's maybe then try to expand on on toxic flow. So when when the press of an asset changes and because the AMP does not rely on an article, Oracle just relies on a ratio, you know of the curve and it and then you know the price of an asset changes.

So then you rely on arbitrage just to bring down, you know, the price or the ratio of the pool back to the market price. And and when that happens, the arbitrage is the toxic flow in the sense that the liquidity providers lose some value or the value of their asset in the sense that they sell it, you know, maybe less than what the market price as is.

Is that correct? Well, in this example, the toxic flow is the the trade that brings the amp price back to the market price because the market prices moved and there's some risk free trade that can be made by an arbitrage or to sell, let's say the price, move down so you can sell it in the pool and buy it on a centralized exchange.

So there's no risk in the trade assuming that you execute the trades at the same time. And and in doing so, you move the price in the amp back to the market price. That's toxic flow because there was no need for the trade to take place in necessarily. But the trade taking place is, is the amp giving up a bad price?

So the market price has already moved and now the person that is collecting the arbitrage is getting like a price that is by definition better than the real price. And that's what makes it toxic for okay, so let's say let's take an example and say we have I used to see if pool, for example, and then and, and that and that pool is on uniswap and then the price of is increases, you know, in the market.

But that's not reflected in the pool. Yeah. So then arbitrage would come and buy that is for cheap because it's now still, you know cheaper than the market price until the pool balances in a certain ratio that you know then then the price of it becomes equal to the market price. This, this trade or these trades that that moves the the price or the ratio of the pool to bring the price of ETF back to the market price is toxic.

Is that correct? Exactly. And maybe it would be helpful. Jeux to pose that against nontoxic flow, which would be if the price in the amp is at the market price and there is some trade in the amp where price discovery is actually happening in the amp. So the market price is already there and now the person that is trading or the user that is trading against the the AMP is actually contributing to price discovery.

That would be an example of non toxic. BLOCK Okay. And maybe we can also quickly go through how current what what in a way they just follow a certain, you know, curves and that curve depends on the ratio of the two assets or maybe you know there are multiple that's the sort of the two assets that are in the put so uniswap curve and you know, the likes of current let's say amms or the popular ones is that they don't use any oracles.

So the way that they find out the price or define price discovery is just basically purely upon the ratio of the two assets that are in the pool. And Dan Wells, as you described, is that it won't only rely on, you know, just a pleasant curve, it can have arbitrary, different, you know, inputs that then determine what the price of of the of the assets are.

Does that mean that Dan Wells, whether required an Oracle Publius so not necessarily in fact and we'll get to talking about the implementations of Wells, but the the first version of well will just be a basic being a pool constant product pool that has all the same problems associated with it as as uniswap or curve. Now it's worth saying Curve V2 is an attempt to integrate a couple of things.

So we're saying Kirby two is an attempt to integrate an Oracle into the pricing function such that the AMP can actually move based on other data. In this case the Oracle, but it's not particularly generalized. And the other thing that's worth commenting on is that there is probably an upgrade to the network itself in this case. Etherium That would really help in terms of memory where, where if at the beginning of every block oracles were updated before transactions were sent, that would that would enable the integration between these amms and their oracles and basically get the get the lag or the potential toxic flow from a lag in the Oracles updating down to zero because

the Oracles would be updated at the beginning of the blocks. But to talk more about just Wells themselves, the concept is the wells can take orders in wells can be a function of oracles, but the Oracle doesn't necessarily need to be off chain data. So in particular, when you think about the beanstalk economy, there's all sorts of data that exists on chain with regards to Beanstalk that may in fact be the thing that determines the prices of the order.

So if you if you imagine like a stock pool where stock is being traded, the price at which people are willing to trade stock may be dependent on the silo yield, may be dependent on the price of a bean, or may be dependent on a variety of other things. That stock is a derivative of in many ways, and therefore if the data exists on chain, you don't have this this Oracle delay problem.

But in the case where you want like the price of ether on all markets, that would be something that would be much better if the Oracle was updated at the beginning of the block as opposed to at random times. Or like in Chainlink's case, it updates the Oracle price dependent on the the distance of the price from the last price.

So if it moves like half a percentage point or something like that, I believe is the way the Oracle works. So there is built into those types of ways to update the Oracle, some acceptable lag or acceptable misinformation, let's call it, which could be mitigated entirely through an upgrade to the network. And then in theory is the idea that Wells can, you know, or the or the price of the assets that are traded in the wells be a function of multiple, let's say, inputs.

So one would be depending on the ratio of the assets that are in there and also the the depending on the price. Oracle. So it's multiple, multiple inputs in theory that is possible, although what's more likely to be the case is that a well as loaded up with one or more assets and then given curves over which those assets can be exchanged for other assets and the curves themselves take in, let's call it oracles or other data over which to process, But it's like the nature of wells are such that we each the well will be unique to the set of curves over which things can be traded and therefore like the way you were

talking about it almost makes it seem like it's one big well that is being updated from an oracle as opposed to that. That may be how people experience trading against wells or trading through wells because the liquidity is aggregated in aqueducts. But at the individual. Well level, it's more likely that the orders themselves are somewhat taken effectively arbitrary inputs and process them at the at the individual curve level.

Okay. I want to go back again to the example of the US to see if pool and maybe say how will that, you know, be like in a lot. And the reason we're using it as a series of the idea that you know, we're imagining a heart attack or or you know uses is always equal to one. And in this example now, you know, we go back again to the price of is and increase sort of went up what would this well then in theory be able to reflect you know the change in price and also account you know, the ratio of the different assets.

And as you said it will be the input would be one thing. But that one thing could be a function of multiple things. So it will first of all look at what is the price of is and then also check what are the ratios and the in the in the pool. And, you know, as a liquidity provider, how much of this I have left and then also what is the price of it?

And then eventually it gives the price to, you know, the traders or whoever wants to trade against the well. Is that an accurate. Yes, that would be possible. Now, it's just worth saying that there would have to be some oracle with the price of ether that the well is using. But yes, that is certainly possible. Okay. All right.

So from here, maybe I'm curious, we can go to to talk a bit about the Oracles or how, you know, do you imagine or we imagine well as well will utilize articles you said or you're thinking about it can be you know, any any would it be first of all and any arbitrary you know Oracle can be used or sort of before going to the Oracles maybe maybe we would ask another question.

Well, the liquidity providers, well have and choose their own inputs into the same well or but each well have a set or a predefined way on how it calculates, you know, the prices and then everyone that's providing liquidity into that well will follow would follow that those rules it's the latter. So each well is effectively the encoding of a strategy and that strategy can can be arbitrary as we've already discussed, but it's not going to be that multiple strategies are added to the same.

Well, Okay. And then do you imagine that a trader would, you know, you will find an aggregate of those, you know, the same asset across multiple wells or with a trader have to choose one. All right. Well, well, the trader should the trader can specify the wells they want to trade against in theory. But that would be a the hope is for aqueducts to aggregate the liquidity that can be accessed and for people to just trade against all of the wells at once.

Okay. All right. Going back now to the Oracle topic of bit. And you touched upon you touched upon it a little bit. You know, with the media discussion, how do you foresee what kind of an oracle do you foresee Wells utilizing? And you know, how how will that be used? And maybe what are the current challenges with Oracle's in general today?

So from from our perspective, it's unlikely that the Beanstalk native Wells or the wells that used the wells that are providing liquidity for the silo are unlikely to need oracles. Now, there's an interesting question that is posed here around what what will be the acceptable well to deposit in the silo and if a well used as an oracle, would that necessarily prevent that well from being used to deposit liquidity into the silo?

And I think to some extent it's unclear earlier, but it's it's unlikely that the use of oracles would prevent liquidity from being added to the silo. It's just that the the oracles will be used to derive the prices that the wells are willing to provide and given circumstances which is distinct from any sort of centralization that's introduced into the system itself.

So if let's take a a being East pool, for example, or being well, where the ratio of beans to ease that the well is willing to offer is a function of the price of ether. There is an interesting question as to whether or not the if the source of the price of ether is coming from somewhere else, like chainlink, for example.

Whether or not that's acceptable to the silo and at this point I don't think I have a good answer to share. So that's something that will well be will have to be considered in the future. But the general idea is that the wells should support anything. Okay, maybe we can discuss a little bit now on the roadmap as well.

So what is the current version that is being, you know, reviewed and we expect it to be launched? The V1 What features can we expect in it? And then what, what, what is the roadmap that you expect? So what will be a V2? Is there a V3? So the thing that is currently under internal review is the core functionality for Wells and in order for Wells to go live and be integrated with Beanstalk, there still remains pumps.

There has to be a pump implementation completed and the integration with BIENSTOCK and the pump has has to take place. So it's not that all of the code necessary for a wells deployment within BIENSTOCK is done, but the majority of it is done and is getting prepared for audit with Walbourne. And due to the composable nature of this, the pumps really are a separate piece of code over there obviously related and the beanstalk integration between the the pumps and and the wells is also separate, but this was the big chunk and in practice, I mean maybe it would make sense to call this like ab0.

My understanding is that the only curves or pricing curves that will be included in this wells core launch is a constant product formula one that takes two assets and another one that takes an asset. And the constant product formula is not the most sophisticated formula that exists for Amos. And more than that, as we were talking about before, the hope is that people will ultimately deploy custom trading strategies in their own wells.

But the the V0 wells should support a being E well on a constant product which will not require any oracles and therefore will be exposed to some toxic flow and that's what V0 looks like. Beyond that, the hope is to have a variety of different pricing functions implemented into wells and a variety of pump implementations beyond the the V0 pump implementation that will be used for, for the silo integration.

And so over the next couple of months, the hope would be that the sophistication of orders that can be supported by wells increases. But to some extent we don't necessarily intend to do all of that development. The hope is that the the MVP is there such that the integration can happen with Bienstock and then all of the architecture is there for people to go on and create their own additional bells and whistles to their orders that they want and create very sophisticated orders if they want.

But that's probably not work. Then it makes sense for us to do and instead just kind of leave it out there for the world. But over time, the hope would be that Wells support all of the the different pricing curves that are popular today in Defi. And then over time, maybe a library of different curves or pieces of curves that people are using will get built or aggregated such that people can pretty easily plug and play into into, into using a bunch of different curves and composing them together for different assets and such.

But at this point really just focused on getting over the finish line to try to get a been pulled back up and running within be in stock, which from our perspective is very, very important given that currently all of the liquidity that trades against beings has some centralization, exposure to it and it really is the the, the best asset for beings to be trading against on Etherium.

So very, very much focused on getting the MVP over the finish line. Okay. And probably as we we spoke a little bit about pumps and aqueducts, but can you maybe tell us again or summarize what are these and how do they fit, you know, to the overall world architecture? So pumps are every well will include a set of pumps whereby the pumps are the the thing that encodes the data on chain such that the liquidity in the pools can be used by other protocols.

So if we go back to the very beginning of class where we were talking about how uniswap and curve liquidity pools, factory pools don't lend themselves to being easily used by other protocols, the concept is that each protocol will may need certain data from a well, and any time a well as deployed it can be deployed with an arbitrary set of pumps that encode the necessary data.

Now, the encoding of necessary data on chain is very expensive and therefore the pump implementations are should only be used if the liquidity needs to be used for a given purpose. And in short, the different pump implementations pumps can be pretty generalized. So you can have like an exponential moving average over different times, a geometric moving average over times.

You could have a like an interest rate pump that that determines the interest rate of a given product or something or from a given. Well, so there's a of a wide variety of different things that the pumps can store on chain. But the basic concept is that each pump will store or encode a very specific type of data or piece of data on chain and aqueducts are the aggregation layer for wells where you may have a well that provides liquidity in USD in that usdc can be traded against a bunch of different assets, and then you're going to have a bunch of different wells that all have different orders for different assets along different curves.

And at the end of the day, if you're a taker, if you're trying to just against liquidity, the only thing really that you want is to know how much can I get for trading my ease into Usdc, for example, and so aqueducts is the aggregation layer over which the information or the the the assets that are stored in wells and there are curves will be aggregated in order for for the for users to be able to understand what is actually available to them, even if what is to cross a variety of different wells.

The aqueducts will provide a a clean interface for the aggregation and querying of that data. Okay. Before moving to to another topic that's out of wells, maybe we'll give it a few minutes and see if any of the audience have, you know, any more about Wells. Otherwise, Otherwise we can move to another topic and see that. Harry asked, When do we expect the audit to be complete?

We don't know yet. Probably something like 4 to 5 or six weeks of audit time once they actually get started and so that probably puts us at sometime late February, because just to be clear, the audit didn't start yet. It's currently under review by the Conservatives. Correct. And so even if the audit starts tomorrow, which may or may not, there's a weekly call, a tabloid tomorrow, I'm not sure if the Dems have or will be able to get through all of their review prior to that meeting tomorrow.

But even if it starts tomorrow, it's probably going to be at least four weeks or so, maybe six weeks, maybe eight weeks until the Dakotas been audited by Halliburton. And then thereafter, I think there's been some discussion on a Katrina audit of wells. And so it's still it's still going to be a little bit of time likely until the the code is deployed on chain and integrated would be in stock.

And as we also mentioned earlier, there is some other pieces of code necessary for that. Integration would start to be implemented, including pumps. And so we're still probably looking at late Q1, early Q2 for actually deploying this within being. But it's this is the completion of the core wells architecture is very much a a huge step in that direction.

You can see there is a related question. My take it here that was posted, maybe sometime ago and I can read it and maybe we can see if there's an answer to that Publius. So the question the question is with regards to Dan, in the sense or one's in the sense that, you know, what what will that what are the wells be like that are deposited or are whitelisted into the silo?

And and here is a question and maybe you can start with an example. So let's say that you want to add $1,000 of of LP into the silo at some certain price price point or price curve that you know that, that that well better choices and then you know the price of the price of being as as different or changes according to you know because you know the price has been fluctuates less then you know that that well would offer a different place than you know other wells that are whitelisted.

And how will being bienstock you know take into account you know that when it comes to seniority and and seats as well. So the first question is around BTV and then the second is around seeds per BTV with regards to the BTV question, the wells themselves will effectively imply a being price. So if you load up 1,000 USD fee and you're willing to buy beans at a dollar, the system should credit you with a thousand BTV, Whereas if you're only willing to buy beans at $0.95, the system should credit you with $0.95 on the dollar.

So 950 BTV. The basic idea here is that the the value of the liquidity in the pool is is only good to bean stock because it's being used to buy beans. And therefore the question is well out at what value, are those beans being purchased? Now, there is an interesting thing here where in practice the thousand dollars buying beans at $0.95 are actually buys you more than a thousand BTV.

But the point is that the liquidity is being provided for someone to trade against. And so if you're willing to buy beans at $0.95, someone that has one BD, one bean can actually only receive $0.95 of value against that. And so the it we think it makes sense to credit have the silo credit depositors of well tokens based on the value that the well itself is pricing beans.

Now there's a really interesting question here around well what if the what if the well contains multiple assets and is willing to buy it, buy and sell multiple assets along multiple curves. How to handle the feeds think that it probably makes the most sense to have the seeds per BTB be a function of the asset that is actually being held by the liquidity pool and and that may change over time.

So someone may load up USD C into a well and give it curves over which to buy beans, which then you get a PD credit for if you deposited in the silo. But it may also have a a curve over which that usdc can be exchanged for ease. And if someone comes and trades against the pool and takes out the usdc fee and adds to the pool or to the well, at that point perhaps the seeds per btb of the well should change to reflect the fact.

Now Usdc is no longer being provided in liquidity against to beans, and now it's instead E and so that that type of update to this that would require an update to the silo to support are really flexible feeds for BDB. But economically that would probably be the most logical answer. So is it accurate to say that we expect the silo to award, you know, stock or, you know, accountability not based on the price of the asset that's whitelisted, but the price of the asset plus?

Or maybe just, you know, what is the depositor waiting to trade that against? Probably now, I think that this is not a solved problem. Don't necessarily feel like this answer is the best possible answer, but it is probably sufficient to to launch it. But over time, the system may become more proficient in pricing. The BDB of a given deposit.

Okay. I would pause here for a minute or two again, see if any of the audience have any questions that you'd like us to expand on on Wells. Otherwise, we'll move to another topic. Okay. Publius in the town hall chat side of Chad linked to a question by in and the question is whether God's to governance and maybe we've discussed this topic before, but here's here's a question or to ask some excellent and asks as that, should ferret holders have a sway with respect to governance, given that they, you know, provided or helped support or see the current liquidity?

So from our perspective, the fertilizer holders are very similar to pod holders in the sense that they are a creditors of bean stock. They have lent assets to bean stock and are now waiting to be paid back. And from a game theory perspective, it's probably suboptimal for a creditors to be able to participate in governance because they are owed something by the system.

And in particular, I mean the question is who should govern bean stock? In a perfect world, Beanstalk wouldn't need any governance. That's that's not reality. And so amongst the shareholders in the system, you have your creditors and you have your depositors. And unlike the creditors which have already lent their assets to be in stock, and while they can sell their assets on the secondary market, the concept is that they are waiting for repayment from the system.

Depositors already have the ability to leave the system at any time and therefore the expectation is that the depositors are much less likely to vote for something that is short term beneficial to printing to repay debt but long term detrimental to the system as opposed to if you allow creditors to participate in governance. It's not unreasonable to think that at some point the creditors will vote to have the system do something that then ultimately gets gets the creditors paid back sooner, but compromises the integrity or the long term sustainability of being.

And so the basic point is that while it's true that fertilizer holders have been the most recent or I guess when you consider sized, have been the most recent participants in in the system, and there is some desire to ensure that the participants in the system are able to effect control over it in a reasonable way. The the issue is that the incentives around being a firm holder or being a holder make it such that it's it's unreasonable to expect the creditors to to be able to vote with a long term success of being stock in mind.

And again, the difference in all cases, the stockholders, the potholes, as the first holders, everyone has some expectation of future returns from the system. But the thing that separates stockholders from the creditors is that stockholders can leave the system at any time with their full value as opposed to lenders are actually waiting for the system to grow in order to receive that value.

So primarily it's an incentive problem where it doesn't really make sense for buying stock to give creditors the opportunity to vote in governance, because that would that would potentially jeopardize the integrity of the system if the creditors were voting to ensure repayment in the short term at the at the cost of long term sustainability. And the the stock system really emphasizes that long term mindset amongst depositors where the primary reason to stay in the system is a long term upside right.

If if the the reason to be in the silo is to short term exposure, the stock system is less likely to have a meaningful effect on on on use of the silo in general as opposed to where the stock system really shines is over longer periods of time. And so given that the goal is for being stock to be able to exist in all market conditions over all periods of time, the it's important that the voters, from an economics perspective are also aligned with that, with that incentive.

And so it's a combination of you don't want creditors voting and the people that you do want voting or have voting are already, from an incentive perspective, long term aligned with the protocol or at least should be. Well, again, Guy expands on this question asks, Do you think of the concept of being odd by being stuck is somewhat true for unripe assets as well, although they aren't creditors per say so why?

That's true that unripe depositors could withdraw at any time they feel or guy feels that the argument that they could or would vote on the short term interests in mind is also true to some extent. Definitely, that's definitely true. And the the current setup of bean stock is unique in that way, in that a lot of the stockholders are also owed something by the system.

But yeah, it's a very good point. It's a very good point. It's just at scale. That's not the way the system should work. And so yeah, we kind of have to just deal with the current situation as it is. But keep in mind what what the optimal situation is the same time, but it is important to acknowledge right now being stuck basically owes all participants obvious.

Would you say that this to an extent was addressed by scaling stock, hence, you know, unripe holders stock changes and it wasn't, you know, just equal to what was the amount previously. I don't think it was a it's a it's a it's an answer to it, but it is a factor that helps mitigate this issue. But it's certainly still there.

Okay.

All right. We have 5 minutes till the hour. We will pause here and see if folks out of the audience have any any other questions. Okay. Before ending this class, I see that we had a relatively good turnout and today's today's timing. So to those are with us, you think or you prefer this timing over you know, the regular time that we scheduled class, Please let us know.

And you know, maybe we can we can we can have this time to be the permanent one. Otherwise. Thank you all for joining us today. And PBS, as always, thank you for taking the time to answer some of these questions. See you next week. Thanks, man.