• Recordings
• Meeting Notes
• Silo v3.1
• Stalk Gauge System
• What Assets Should Be Whitelisted?
• Minimum Standards For Whitelisted Assets
• Root-Bean LP?
• Deep Liquidity
• Relative Value
• Bribes
• Voting
• Transcript

Recordings

Meeting Notes

Silo v3.1

• Updating the way that Seeds are accounted for, such that the Seeds per BDV for a given deposit can change over time, whereas currently Beanstalk only supports static Seeds per BDV.
• At the moment, the Bean price is at 94 cents, and to a large extent it's likely because of the sub-optimal Seeds per BDV ratio. The willingness of Silo members to convert from LP tokens to Beans is not high enough to return the Bean price to oscillating above and below its peg.
• Fundamentally Beanstalk needs to have the ability to adjust the Seeds per BDV, taking into account the volatility of the Bean price and potentially other factors like the debt level.

Stalk Gauge System

• As the number of deposits or the number of tokens that can be deposited in the Silo increases and the Seeds per BDV can be adjusted in an almost arbitrary fashion, a gauge system would be some way for the Seeds per BDV to fluctuate autonomously based on some governance mechanism.
• The relationship between the governance aspect of it, the market aspect of it, and the economic incentives around it are pretty complicated.
• Given that the Silo work is being done to get to the point that a gauge system could be implemented, it makes sense to have the conversation about what a gauge system could look like

What Assets Should Be Whitelisted?

• You can probably use the Seeds per BDV associated with a normal Bean deposit when depositing the LP tokens from various Bean pairs. The question is around whether or not there should be some bonus in terms of Seeds per BDV around the provisioning of liquidity to Beanstalk in the form of some desired value for Beans to be a) liquidated against and b) priced against.
• While Beanstalk doesn't have a collateral, Beanstalk does have liquidity and there is an open question as to the management of that liquidity and the optimal construction of that liquidity. To some extent the goals around the liquidity that Beanstalk trades against need to be highly aligned with Beanstalk when it comes to censorship resistance, decentralization, and economic incentives.
• The starting point in asset selection should be from a risk management perspective. The value of the liquidity that Beans trade against is often not a function of Beanstalk.
• There are tradeoffs everywhere.
• There is a balance to be struck between permissionlessness and risk management.
• It would make sense to limit exposure to certain assets, but beyond that even certain classes of assets or characteristics, such as whether collateral is custodied by the same entity or in the same country.
• You could prioritize having liquidity against ether, because it's maximally decentralized, but it's also highly volatile.
• LUSD is similarly decentralized to ether and less volatile, but it has less competitive carrying costs.
• There are also low volatility centralized assets. Currently Beanstalk trades against 3CRV, which is USDT, USDC, and DAI, which is mostly centralized collateral.
• The hope is with Wells there will soon be a variety of assets trading against Bean again, and the DAO should decide how to evaluate and manage risk associated with those assets, such that Beanstalk can have a variety of assets trading against it and whitelisted for deposit in the Silo.
• But more than that there's some mapping that needs to be done between the risk associated with any distribution of exposure within the Silo to Beanstalk and what the market has supply and demand for.
• When an asset is whitelisted, there should be some sort of registration of different properties, such that the gauge system can know what risks are associated with that asset. There may need to be some process that needs to happen around verifying that information.

Minimum Standards For Whitelisted Assets

• The asset has to be traded against Beans. There needs to be some liquidity pool or Well.
• In the case of other Beanstalk issued assets, such as Pods, the value of Pods is dependent on the value of Beans to some extent, so it wouldn't make sense to issue additional Seeds beyond what's given based on the Beans.
• The question is around whether assets are adding any sort of liquidation value to Beanstalk as an ecosystem, and if the asset is issued by Beanstalk then it's too circular. Pods having liquidity against Beans would not add value to the ecosystem.
• It is essential to have some qualifications because there are security implications. If you have some token where you control 100% of the supply, you can effectively mint Stalk.
• Currently Beanstalk doesn't facilitate the deposit of Pods into the Silo, and doesn't give credit for that. It probably adds additional complexity that is unnecessary. It's probably better to keep the primary liquidity in the system the same as the one it is denominating value in.

Root-Bean LP?

• You could do a Root-Bean LP token, but it might not make sense to give it additional Seeds. You could make an argument that it qualifies for slightly additional Seeds if it's in the interest of Beanstalk to have Root liquidity.
• If so, that might also be an argument for a bonus for Pod-Bean liquidity, since Beanstalk wants liquidity for Pods to some extent.
• This is something a sophisticated gauge system could ultimately handle. It could set a maximum additional Seeds per BDV on Beanstalk native asset pairs to be 20% of whatever the Bean Seed per BDV ratio is. You could have a cap on the bonus, but you could have some bonus and the bonus could be changing based on some other factors. The gauge system could handle any sort of arbitrary rules like this.
• Maybe there is an argument for temporary or full time bonuses for certain Beanstalk asset pairs.

Deep Liquidity

• Should Stalkholders care about incentivizing assets that have deep liquidity?
• This becomes interesting when you have N-dimensional Well orders where there are multiple assets being put into a single Well potentially. This is in the future where you have more than one asset trading against a single Bean. Now you really have to evaluate the value of the assets individually, but now the question is that the liquidity is somewhat triangular. Do you double count liquidity and what does it mean to actually have liquidity?
• It's important to assess the real liquidation value of the entire system and whether a marginal deposit actually creates additional liquidation value for Beanstalk.

Relative Value

• In the grand scheme of things, decentralization is essential when it comes to liquidity against Beans, but it's also important to recognize there is limited available decentralized endogenous value on-chain. A lot of the value is either going to be wrapped Ether, or some sort of centralized collateralized asset, or some wrapper thereof (like how FRAX is a wrapper of USDC).
• Instead of saying that there needs to be a maximal focus on decentralization, the issue is managing risk in real time with the market and allowing the market to do its job in regulating exposure that Beanstalk has, but also creating principles or rules that the gauge system can enforce that the DAO has whitelisted effectively.
• For example, a rule could be that wrappers of centralized collateral can only be incentivized with additional Seeds per BDV when it has less than 50 percent of total liquidity trading against Beans in the Silo, for example. And the Seeds per BDV could be adjusted based on some function that is calculating the liquidity trading against Beans and how much of it is collateralized by some sort of centralized system or whether it’s an endogenous value or wrapper thereof which is decentralized.
• Whether you then affect the marginal deposit or new depositor, or do you dilute everybody if people continue to deposit, is an implementation question or an incentive question. But the point is that these sorts of rules are probably the best way to create a good risk managed system.

Bribes

• The inevitability of bribes should be considered, especially in a world where deposits can be borrowed, which will be the case in the near future.

Voting

• Something of an open question. It is to be determined how voting power will be distributed across different assets.
• One major question is how to balance the seeds per bdv of beans vs the liquidity that beans trades against. The overall liquidity ratio is a separate axis from the distribution of the liquidity. There needs to be a mapping between the votes for each.
• What are the things that should be optimized around and whether that is something that should be voted on or just totally autonomous, versus continuous vote (is this too volatile or not?)

Transcript

Okay. I think we can get started. How are your problems Doing well. How are you? Things are well. Here. Put this post thinking we can spend some time. This class talking about a specific part of, let's say, the site of it all. And that's the gift system. And maybe we can start off with what is the system and how is it different from, you know, how being operates today and why would we need something like that? Well, I don't know if we can call it silo re two, because there's already a bit that's in discussion around silo B 3.1. So this may be a silo three, 3.2 or something like that. But what that would or just from a nomenclature perspective, feel like it's important to be on the same page, but Silo V 3.1 is updating the way that seeds are accounted for, such that now the seeds per PDB for a given deposit can change over time. Whereas currently being stock only supports static feeds per PDB and at the moment being the pin prices of $0.94. And to a large extent it's likely because of wrong seeds for PDB ratio or suboptimal seeds for PDB ratio. When it comes from the perspective of maintaining the being price oscillating above and below its peg, meaning the benefit or the willingness of silo members to convert from LP tokens to beans is not high enough to return the bin price to oscillating above and below its peg. And it's fundamentally been Docker needs to have a system where the the ability for the protocol to adjust the seeds for PDB takes into account the volatility of the being price and potentially other factors like the debt level. So the question is as the number of deposits or the number of tokens that can be deposited in the silo increases over time and the feeds per BDB can be adjusted in an almost arbitrary fashion, what a gauge system would be would be some way for the seeds per BDB to fluctuate autonomously based on some governance mechanism and the relationship between the governance aspect of the market aspect of it and the the economic incentives are that are pretty complicated. And so it's probably helpful given that the base, the base silo work is, is being done to get to a point where engaged system could be implemented. It probably does make sense to start that conversation on what a gauge could look like. And I know, as I said, that, you know, we we don't or this is something that has been discussed in discussing this for a while. And I was hoping that we can talk more about, you know, what what I guess some look like and how how would the community or the stockholders want to want to look at it or how to use it and published maybe before talking about the GIS system itself, because that impacts wireless assets. We can take a step back and think or ask the question of what assets do we think? As our stakeholders, we want to whiteness enter into the silo. So maybe the question is what are the minimum requirements for an asset to be whitelisted into the silo to begin with before even giving it, giving it any energy support or any any suits on to say different, different number of seats because they would all assume getting seats once their whitelisted. Well, it's important to note that the genes in an LP token so we have been to them for access. There are some you can probably deposit the gain access token in the silo and have the seeds per BDB associated with a normal bean deposit. The question is around whether or not there should be some bonus in terms of seeds for BGP around the provisioning of liquidity to beans stock in the form of some desired value for beans to be a liquidated against and be priced against. And so while bean stock doesn't have as collateral, bienstock does have liquidity. And there is an open question as to the management of that liquidity and the optimal structure of that liquidity and the to some extent the goals around the liquidity that bean stock trades against need to be highly aligned with the goals. The beanstalk, which is censorship, resistance, decentralization and strong economic incentives. So there is some open question as to what are the optimal assets to be trading against. But the the starting point is that you has to think about the selection of assets from a risk management perspective, first and foremost in the sense that the value of the liquidity that you trade against is not solely a function of being stock and often isn't a function of bean stock. So on the one hand, and there are trade offs everywhere on the one hand, you can prioritize having liquidity against ether because it's maximally decentralized, but it's also highly volatile. You can have liquidity against LAUSD, which is similarly decentralized to ether and less volatile but has less competitive caring for. So there's some open question as to the the optimal I mean, then you can have, you know, low volatility, centralized assets currently being stock trades against three curve, which is tether usdc and DAI, which is not of itself mostly centralized collateral. So currently being stock that's exclusively centralized collateralized stablecoin exposure. And the hope is that with wells there will soon be a variety of assets trading against being again. And there's an open question as to how the Dow should evaluate risk associated with any given liquidity and managing that risk such that beanstalk can have a variety of different assets trading against it and whitelisted for deposit in the silo. But more than that, the there's some mapping that needs to be done between the risks associated with any set of or distribution of exposure within within the siloed of being stock and what the market has demand for on supply for, which is sort of a very interesting open question. So those are maybe the axes on which this optimization can be thought about. Okay, let's maybe try to redefine the minimums. So you mentioned one of them is that the assets, first of all, has to be traded against banks, right? So we can we can assume that it will be some sort of a liquidity pool or. Well, and that's the first minimum. You mentioned another point for this, and you said that that asset, you wouldn't want it to be issued by being stuck. I'm going to ask a hypothetical question. If pod's where what do you mean by that? I don't I don't think I said that. Okay, maybe I misunderstood it. So I'm going to give an example and tell me if you think this is something that can be, you know, such an asset can be what if pods, for example, where like liquid an on secondary markets or you know, there where liquidity is at which you can somehow price upwards. Maybe it wasn't a great example, but we're going to assume that they're fungible for a moment, too. But the the idea being you should buy by being stock. What would that being versus another asset? And, you know, in this case, we're using puzzles, an example. So of being an asset issued by the SEC as well. Can that can that appear to be what always has to be an asset traded against being? But is not issued by by buying stock. So the issuance doesn't matter per say. The point is that it's a question as to whether or not there is some sort of additional seeds per BDB to credit the deposit in addition to the beans in the deposit. So you create a being partnered LP token. The the beans in the LP token can be credited with seeds, but the pods cannot be credited with schemes in this instance because the value of eggs is derived from the value of being as you were suggesting. So I guess it does sort of matter about the issuer. Now if you have any sort of value outside of beans stock, there is still an open question as to whether that quantity qualifies for additional needs for BDB, which is where the gauge system would be introduced. But there are certain qualifications that are essential because if you have let's say there are security implications here if you have some token, that's why it can't just be totally arbitrary. If you have some token that you control 100% of the supply of, you can deploy the token against being at a crazy high valuation for your token and then add a significant amount of liquidity in your token. On one side of the liquidity pool. Token to your token is a high Oracle price, high BDB or high token for PDB ratio and if you're getting credited for depositing those tokens in the silo now you can just mint stock effectively and take over the system. Whereas if you're only getting credit for the beans in the LP token, it's effectively the same as just having deposited beans in the silo, which makes sense. The question is around whether assets are adding any sort of liquidation value the beanstalk as an ecosystem and if the asset is issued by being stock, then it's two circular pods. Having liquidity against beans would not add value to the ecosystem, whereas if the pods had some sort of liquidation value against ether, you could make an argument that if the pods could be liquidated for something else because there's some other value pod per pod LP token. But, but to some extent then Beanstalk would really just want to pay for the need. There's no benefit to Beanstalk for giving credit to the pod bean LP token holder for depositing it on the silo. Is whereas the there is a benefit to bean stock for encouraging an each pod LP token for example, which is interesting. Now currently bean stock doesn't facilitate the deposit of plants in the silo and doesn't give credit for that. There's an open argument as to whether you could deposit some sort of LP token to bid for any bean stock asset and deposit that in the silo, but probably think that that adds additional complexity that is unnecessary to the model and better to keep the primary liquidity in the system, that the silo is denominated in value and in bean. But perhaps could be wrong on this. What about root, do you think? Root A bean root pool would make sense to be whitelisted or would it be like a royalty pool similar to what you suggested? Well, you could do a root bean LP token, but don't think that it would necessarily make sense to give it additional beans. Although you could make an argument it qualifies for slightly additional seeds. If it's in the interest of bean stock to have root liquidity. So there's some argument there, which is interesting because that would actually be an argument in favor of even having the potential to give a bonus for being pod liquidity on the pod side because bean stock wants liquidity for pods to some extent. Think this is actually something that the gain system could ultimately handle. A sophisticated gauge system would say the maximum additional feeds per PDB on Beanstalk bean to be in pairs are beanstalk to Beanstalk. Native assets is is is you know or 20% of whatever the beet being per PDB. I guess the bean feed for PDB ratio it you can have a cap on the bonus but you could have some bonus and the bonus could be changing based on some other factors. So a sophisticated gauge system could handle any sort of arbitrary rules like this. And as we're thinking here out loud about it, yeah, there is an argument for, you know, maybe temporary or full time bonuses are for certain bean to gain for beanstalk, the bean stock asset pairs. Interesting question. So yes, I think as we're more talking about this, more we're getting more questions, but interesting questions Guy asks when thinking about what Beans offered to incentivize particular behavior, for example, incentivizing conversions, when when the time between that crisis is increasing, when should it offer more stock versus more seats? Look fascinating. So the stock is really a mechanism that is focused on the ownership distribution of beans, senior edge, such that bean stock becomes more decentralized over time and from that perspective, and then also to introduce opportunity cost for leaving the silo when the system is not minted. And the there's an argument to be made that the seeds for PTV should trail off excuse me, the growth in stock for BDB on any given departures, it should trailer as the age of the deposit increases. So there are some maximum seeds for BTB excuse me stock for BTB on a deposit that could really have some sort of effect on the decentralization of beans over time, particularly in terms of the advantage of older depositors. But that's sort of a marginal benefit. But the point is that stock that's focused on the long term ownership distribution of the system and decentralize using it, whereas seeds are the marginal incentive around which assets do deposit in the silo and sow the seeds for BTB and fluctuating that are changing. That is a way to, at the margin affect the construction of deposits in the silo that bin stock is incentivized. And. WHEREAS, changing the way that stock is distributed in the grand scheme of things in terms of is it linear growth from seeds or is there some sort of function over time and based on the age of the deposit that that that question should be answered in the context of ownership, distribution of bean stock? Okay. All right. So probably now we have assets that are whitelisted into the into the silo. And you mentioned a few axes. Let's say that the stockholders or the Dow members can optimize around. One of them is decentralization or how decentralized that asset is. Maybe another point of it is the stability of that asset. So it's versus something something like use C or a STABLECOIN What about how liquid is that that asset or, you know, how is there deep liquidity or how you know, how much liquidity is available to that asset? Is this something that stockholders will want to care about or it doesn't matter? Well, things get particularly interesting when you have like an end dimensional well order where now you have multiple assets being put into a single well, potentially this is in the future where you have more than one asset trading against a single being net. We really have to evaluate the value of the the assets individually. But now the question is that the liquidity is somewhat triangular. Right. And how do you double count liquidity? What does it mean to actually have liquidity? So, sure, liquidity of an asset is something that we should certainly consider. But in the grand scheme of things, there's some open question as to the real liquidation value of the entire system and whether a marginal a marginal deposit actually creates additional liquidation value for buying stuff. So yeah, it's an interesting question as to what liquidity actually means. And in this context. Okay, following that, how do you think or how would you thank, you know, the stockholders again would want to evaluate each of these of these axes. Is decentralization more important than the asset as stable or or volatile? Is that more important than, you know, how liquid that asset is? And and maybe maybe it's not like one is important, but the other is like, depending on the time, then one thing becomes more important than the others. So think that in the grand scheme of things, decentralization is is essential when it comes to liquidity against beams. But it's also important to recognize that there is limited, available, decentralized endogenous value on chain. And so a lot of the value is either going to be wrapped ether or it's going to be some sort of centralized issued collateralized asset, and that's or some wrapper thereof, right? FRAX is a wrapper of usdc due to have usb-c. You can have FRAX, you can have ether or you can have rye or you can have value usdc. So there's all variations of endogenous to value or exogenous value and volatility, low volatility yield generating, non yield generating. And instead of saying that, you know, there needs to be a maximal focus on decentralization at any point, one, there are some question as to managing risk in in both in real time with the market and allowing the market to really do its job in regulating exposure that Bienstock has, but also creating principles or rules that the game system can enforce, that the Dow has whitelisted effectively, for example, that you know, rappers and rappers of centralized held collateral can only be incentivized with additional seeds, probably one that has less than 50% of total liquidity trading against beans in the silo, for example. And the seeds for BTV could be adjusted based on some are some function that is figuring out what is the liquidity trading against beans and how much of it is centralized, centralized, collateralized, collateralized by some sort of centralized system, or whether it's an endogenous value or wrapper thereof, which is decentralized. And that would affect there's a couple of ways to then change. How do you do you effect the marginal deposit or like the new deposit, or do you dilute everybody if people continue to deposit, that's an implementation question, but or an incentive question as well. But the point is that this is these are the rules like that are probably the best way to think about how to create a good risk managed system where there are certain rules that the game system is enforcing with with incentives. Okay. We have a question from Switzerland beings, and it's regarding once and they ask, can an additional pump be added to a well which has already been deployed, or does adding a pump require deploying a separate one? So as of now, the wells are immutable, as I understand it. And therefore the pump cannot be added after deployment. And so there is some question as to whether or not that's the optimal way to construct wells or whether there should be governance at the well level. In theory, the owner of the well could could change, could change it. I guess. But it's it's also probably better practice, particularly if there is a well designed gain system to encourage the deployment of new pumps, that then people can move their capital over to manually as opposed to forcing people onto new new wells, if that makes sense. So the real goal is to a system that has very low friction around deploying similar competitive wells that have the exact same benefits in terms of seeds per BDB, and then users or depositors of the system can choose which wells they want to deploy liquidity to. And they are totally unaffected by technical things like pumps, unless Bienstock wants to encourage particular pump implementations because it's beneficial to be, in which case that could also be added to the to the gated system. Publius Do you think there is some logic or thinking behind limiting what percentage a certain asset has within within the silo or, you know, this is something to be decided by my stockholders? I mean, it is something to be decided in the end by stockholders. But do they want to like, say, for example, let's you know, we don't want over 50% to be a system asset or maybe it's best practice to limit a certain asset to be no more than 15% of the overall system. Yeah, And there's a question as to how those rules should be implemented. And those rules should probably apply not just at a token level, that certain property level, I forget who issued the assets. Maybe there's multiple assets that are collateralized, but they're collateral custody by the same company for custody in the assets or custody in the same countries. And there's certain ways that those limits can be put on not just individual tokens, which certainly make sense, but also are the property with. And when a token is whitelisted for additional seeds per PDB in some capacity, it's when the whitelisting takes place, whatever that consists of. It should ultimately come down to different properties, different properties, some sort of registration of different property such that such that the legal system can know what the actual actually what risks are associated with the asset. And there may be some process that needs to happen around verify, verifying the information around the properties is accurate. So to some extent there is a balance here between permissionless MIS and risk management that there is some sort of verification that should happen around the properties that are listed for a given token. And while we're at or discussing risk, do you foresee some sort of a bribe system happening once a system like this system goes live? And if yes, is that is that positive or negative? Maybe it is good to have, you know, some sort of a bribe system where you can really help it to some extent. It's one of the philosophies that we've always had around is that if if you can't prevent it, then you have to embrace it. And so ultimately there probably will be some sort of market arrangement providing liquidity to a given assets or providing seeds for gauge for a given asset and that's probably something that should be factored into how the marginal seats for BDB are voted on by a given stockholder. And this also factors into the more general decentralized governance question around bribing depositors to vote on. Given the given things, once there is some sort of ability to borrow deposits, which is going to be going to be possible pretty soon. So bribing applies not just at the gauge level, but governance in general and should be should be factored into the discussion. And however, the gauge is ultimately accountable. All right. We have another question from Swiss audience about once they ask, would the liquidity be fragmented if there were many different wells with different pumps but containing the same asset, or would the liquidity be aggregated somehow when trading against wells with different pumps? From a user perspective, the liquidity would be aggregated. So I believe it's the aqueduct that performs the aggregation of all of the different wells. Right. Okay. So we now have again, maybe just to add a little more color, the aqueduct is a registry of pumps. And so the the idea is that you have these wells that have problems, that have some sort of information about what is going on in the pumps, in the wells. And then those the information that is pumped is then aggregated at the aqueduct layer. So some of that information may be used to create great user experiences where they just are able to trade directionally against the most efficient liquidity. So from from a user's perspective, the the sum or the amount of liquidity available for an asset would be the sum of all of the assets available in different forms. And then which what exactly are they fighting against would be the efficient. Well, but you know, what is the most efficient? Well is this would be decided I guess later what I agreed on. Okay published. We now have a system of flows and stockholders can vote for which asset they think is, you know, has more value to the to the system. And then they would value with more with more seats. How often do you think this this process or this vote, you know, goes as it continuous and live all the time? And just depending on someone's changing the vote, then, you know, this is what change or would it be periodic maybe once a week, once a month or once a quarter? It's unclear what it should be. There's something to be said for a continuous meaning real time or every season. But that type of question is probably best answered in the context of what the game system actually will look like and what the mapping is from stock voting, giving cents to the actual associates for PDB and I think the first question on that front is, will, many said, can you vote for it for a given stock? Are you distributing your stock across? You know, if you have one stock, if you distribute that stock voting for and different assets with one stock, or is that stock does that one stock have to be divided up across that so that you vote and think that it's probably necessary to make it such that the one stock is divided up. So you have to choose where you're stock decreased. Now maybe you've put out some sort of quadratic system where the more that you vote on the value of your votes across them decreases, but it doesn't pass you to divide it linearly, which is worth considering. And then based on the stock that is allocated for a given set that needs to then get filtered through the set of rules and mapped to some feeds per PDB and the teams for B divvy needs to be at a range between the B and the seeds per being deposits and there's also an open question as to the the ratio between beams and liquidity, which is the current imbalance causing the price deviation veering off the gauge system and stockholders should be able to vote on the general relationship between seeds for Bean and seeds per LP tokens. And then separately, the voting around the distribution of the liquidity, the beans trade again, if that makes sense. So there's two axes, which is the beans liquidity ratio, and then separately the distribution of the liquidity. And there needs to be a mapping between the votes for each of them. All right. I'm going to pause here and see if our audience have any questions that they would like to ask about the guest system wells or any other topic. So you can talk with town Chatter again for free to join John on stage. You can raise your hand or bingo on stage. Okay. Probably before ending this class. Any thoughts or closing comments on how the Dow once will want to approach the guest system? And is there anything to think about from now until such a system is implemented? Well, there seem to be a variety of open questions, right? There's the question as to the properties that are important for the to vote on in terms of limiting its exposure and risk management. There's a question of how to implement that in as permissionless aware as possible. There's a question as to how to actually value real liquidity. There's a question as to how to wrap stock votes for the distribution of given liquidity to seeds for BTB in the context of the rules that the Dow has whitelisted. And there's also the question as to how to map the stock that is being voted on around peg maintenance in terms of the bee versus liquidity incentives and what are the what are the things that should be optimized forever on that front and whether that should be something that is voted on or whether it's just totally autonomous versus the continuous vote, Meaning is this is this too volatile or not? Maybe that's a separate very interesting question. Is that something that does make sense to leave up to some sort of more fluctuating incentive based on volatility? Okay. We have a question from Swiss ratings and they ask what ideas have been discussed regarding the appropriate implementation of a network layer Oracle that updates option data at the beginning of every block to ensure that ones have accurate pricing. Deathly So maybe to give a little bit more context on the question wells facilitate the implementation of full strategy. Is any given order in theory? And the idea behind that is that you never need to update your order and the reason for that is that in a in an environment with MEP, you can actually update your order. So by creating orders that never need to be updated, you fix because you're encoding for strategies, you get around the fact that you can update orders and the there's a couple of network layer problems around encoding for strategies on chain. There's there's two primary ones I highlight. One is privacy, which is that you don't really have to publicly show what your full strategy is. And two, which is what three red beans is asking about is that if the Oracle data that the order is using to come up with its price is is receiving data on the chain and the Oracle is not on chain entirely. The issue is that if the Oracle isn't updated before the well the order is traded against, then you lose the property that the order is always up to date. And so there is some need to have at the network layer the ability to enforce the fact that the the Oracle has been updated before the well can be traded against this problem also applies to liquidations where you will need in order to ensure that there is no risk of a liquidation failing or a lending protocol taking on bad debt failing because liquidity was removed, making it such that bad debt would accrue. So there are certain integrations between Oracle and the network layer that seem essential to creating a a financial an environment for decentralized censorship resistant financial activity that can be out competitive of print or centralized financial activity in trading environments and lending environments. And that's that that's the problem. In terms of the solution, think that you're probably way too early to comment on exactly what that would look like. And at the moment, really just trying to do our homework as to what would something like that might even look like. And obviously at the moment there's a lot of short term priorities and projects being passed and there's a balance between figuring out the long term, the long term solution and what the time horizons are on various L2 developments that could make something like this possible and think that's more and more it's becoming clear that spending a lot more time doing research on various altitudes and in particular zero knowledge, zero knowledge proofs and their ability to ensure or to assist with doing a lot of this. The Oracle computation off chain and integrating that with the with the network layer, it's going to be really important. So the more research that we can do collectively and get a handle on where the space is going and what's going to be the there is some notion of still needing to have oracles excuse me, orders that don't need to be updated. But the question then becomes how to integrate oracles that facilitate the updating of of orders and liquidating and guaranteeing liquidations into orders can be integrated. And yeah, at least on this, I'm not quite ready to talk about the appropriate implementation but very, very interesting questions that we have a question from guy and they ask where are those liquid stock fit into the critical path of implementing a system? Does one need to come before the other? It doesn't need to. If it's one of those things where what is liquid stock? It's a it's an early 20 token that in theory comes with the governance and yields and to some extent that anyone can do that. But there's also an argument to be made that the that it would be in stocks interest to actually issue a variety of different types of liquid stock and to have one liquid stock to be associated with maybe before governance, one liquid stock yields, one liquid stock be associated with engaged governance or even distribute yield in terms of multiple gauge governance votes and distribute it that way to make it totally modular. So don't necessarily think that it makes sense to implement liquid stock before the game system, because the game system may may help offer a following how liquid stocks should actually work. And one can assume that the negation or vote delegation may somehow do that indirectly. Analysts right where you can get your your stock to someone and then someone can vote in the case in the system as a vote delegation, it always happens I think what at the end of the tunnel chat questions so pause here again for a minute see if anyone else has a question that they would like to to ask. Otherwise we can discuss. Thank you all for joining us today. And as always, thank you probably for taking the time to answer these questions. And we'll see you all next week.