• Recordings
• Meeting Notes
• Seeds per BDV Rewards
• Bean-ETH Well
• Conversions Between LP Tokens
• Oracles Used For Conversions
• Transcript

Recordings

Meeting Notes

Seeds per BDV Rewards

• The Silo is being upgraded to use cumulative Stalk per BDV rather than Deposits being indexed by Season.
• There is a whitelist for depositing ERC-20 tokens in the Silo, and at the time of deposit the depositor is rewarded with Stalk and Seeds. Seeds generate Stalk every Season. When Beanstalk was deployed, there were two tokens whitelisted: Beans and Bean-ETH LP tokens. Beans were rewarded with 2 Seeds per BDV, and LP tokens were rewarded with 4 Seeds per BDV. The rationale was that the 4 Seed reward would incentivize providing liquidity for Beans.
• Currently Unripe Beans are rewarded with 2 Seeds per BDV and Unripe Bean-3CRV LP tokens receive 4 Seeds per BDV. There have been discussions going back several months around whether there should still be any incentive for holding Unripe Bean-3CRV LP over Unripe Beans, given that holding Unripe LP in the Silo does not necessarily benefit Beanstalk more than holding Unripe Beans. There has been general agreement that the two should be rewarded with the same Seeds per BDV.
• There was a suggestion that setting the rewards of both Unripe assets to 1 Seed per BDV would be beneficial because it has the potential of encouraging new deposits by giving them a relative advantage in terms of Stalk growth.
• There's value in the protocol explicitly highlighting new Deposits relative to the Unripe assets which are sort of forced.
• The two questions at hand are whether Seeds per BDV should be equalized for both Unripe assets, and how much Seeds per BDV should they be rewarded.
• A major benefit to equalizing the Seeds per BDV for Unripe assets is that it would remove the opportunity cost of conversion. There would be no loss of Seeds to deter users from performing otherwise profitable arbitrage.
• There are important differences between Unripe assets and regular Deposits, and they should be evaluated separately.
• Beanstalk ultimately should prioritize liquidity. Seed parity across the board would imply that Beanstalk prioritizes low volatility instead of liquidity long term. If Beanstalk incentivizes people holding LP tokens, it is prioritizing systemic liquidity rather than demand for Beans outright. Prioritizing liquidity is a healthy policy because if there is no marginal cost to holding Beans without pairing them with liquidity, eventually the system will have a lot of Beans and not a lot of liquidity. Prioritizing liquidity minimizes both the excess Beans that are minted and the downward price movement during down cycles.
• The interesting thing about the Unripe liquidity is that it is locked in the system. So the question turns to what's the most beneficial use of that liquidity. Currently it is just sort of anchoring the system independent of price. Beanstalk could incentivize that liquidity to maintain a relatively tight peg through Seed parity, or even to maintain a very tight peg through inverting the Seeds per BDV.
• Given that holding Bean-3CRV is a risk minimizing strategy, it's likely that we would still see significant converts above peg with Seed parity.
• There is enough Unripe liquidity to absorb the sale of all outstanding Bean. If all Beans in circulation were sold, there is enough Unripe LP available to convert and restore the peg while retaining a significant amount of liquidity.
• In the case of Unripe assets, there is less benefit to performing arbitrage since you don't immediately capture any additional value. This calls into question how strong the incentive to convert will be even with Seed parity.
• Everything considered, there is some marginal incentive to convert below peg, along with the positive externality of the Bean price returning to peg and the negative externality of a decrease in liquidity.
• A straw poll in the barnyard chat was overwhelming that people would be willing to convert deposited urBEAN3CRV to urBEAN with Seed parity.
• A second straw poll showed widespread agreement that such conversions would be beneficial to the protocol.
• Peg stability is one of Beanstalk's best forms of marketing.
• There are two scenarios that would result in Beanstalk not having enough liquidity available for convert against every single Bean. The first is that there is too much external minting through BIPs for things like budgets and audits. Given the pace that Beans are being minted for those purposes, it seems like it would take several years for that to happen. The second scenario would be that there was an excessive amount of Beans being minted, which would probably only happen if the incentive to convert above peg is too low.
• There seems to be consensus favoring Seed parity.
• Given that there is no reason not to hold Unripe assets in the Silo, the question becomes whether they should be awarded any Seeds at all. Since Grown Stalk creates an opportunity cost for leaving the Silo and it doesn't really matter to Beanstalk whether Unripe assets are even held in the Silo, you can make an argument that Unripe assets don't deserve any Seeds at all.
• It might not be realistic to reduce the Seed incentive to zero, given that Unripe asset holders hold so much Stalk. But there's an argument to be made that it should be lowered to one or less.
• A straw poll in the Barnyard chat showed a preference for <= 1 Seed.

Bean-ETH Well

• What should the Seeds per BDV reward be?
• The Stalk Gauge system is intended to allow Stalkholders to decide in real time what they believe to be the optimal ratio of non-Bean value for Bean to trade against.
• As an example, in the scenario where there are only two liquidity pools, Bean-3CRV and Bean-ETH, the DAO can target something like 75% ETH to 25% 3CRV, favoring ETH's decentralization over 3CRV's stability.
• Prior to exploit, both Bean-3CRV and Bean-ETH were rewarded 4 Seeds per BDV. Liquidity was growing quickly for the Bean-3CRV pair, despite some friction from having to create the position on the Curve site.
• The data confirms that the Seed incentives are an effective tool to direct the flow of liquidity.
• Beanstalk might prefer ETH exposure versus 3CRV exposure for the time being since all the Unripe exposure is 3CRV, but in that case you're going to create arbitrage opportunities between the two pools which will bleed value from the system. That may exist regardless, though.
• Beanstalk probably shouldn't take a strong position on ETH versus 3CRV exposure.
• The gauge system will dramatically improve on this decision making process.
• Bean-3CRV provides more utility because there is far less slippage using the stableswap AMM compared to the constant product pool that Bean-ETH will launch with.
• There is also value for Beanstalk in limiting its exposure to 3CRV, which is the least common denominator of the tokens it's made of.
• There are clear tradeoffs of stability and peg maintenance benefits for 3CRV and decentralization with ETH.
• It is important to note that even the Bean-ETH pool will convey some exposure to the USDC price. The Bean-ETH pool will likely be using multiple Uniswap V3 pools to determine the ETH USD price, as that seems to be the best on-chain indicator of the off-chain price of a dollar. If USDC was to lose its peg, Beanstalk would have an inaccurate Bean price via the ETH pool as well as the 3CRV pool.
• A straw poll in the barnyard chat strongly opposed having the same Seed rewards for Bean-ETH and Bean-3CRV.
• Seed parity between Bean-ETH and Bean-3CRV might have been more effective prior to the merge, when there was some uncertainty around that. After withdrawals are enabled, Beanstalk and all other DeFi protocols will be competing against the risk-free rate offered by staking. Parity might not be good enough for ETH holders to consider holding their ETH in the Silo as opposed to simply staking it.

Conversions Between LP Tokens

• Converting between Bean-ETH and Bean-3CRV LP is a difficult mathematical problem to solve. It will be important to guarantee that it never contributes to an increased magnitude of the deltaB away from zero. There should always be a way to convert between Bean and either of the LPs, but the scope of converting between the LPs is not yet understood.
• There is a possible attack vector involving a flash loan into one of the pools that causes a lot of slippage on a convert, which could result in a change to the deltaB when the conversion is performed.

Oracles Used For Conversions

• Currently, Silo conversions use the instantaneous price of Bean relative to 3CRV. It uses the virtual price of 3CRV, which is inherently manipulation resistant. But since it uses the instantaneous value, it means that converts can be sandwiched or front run.
• When converting from Bean to LP, from a user's perspective there is no way that somebody could use a flash loan to make you have a worse execution price. But from the perspective of Beanstalk, a user could use a flash loan to convert more than would otherwise be allowed and thereby increase the absolute value of the deltaB.
• As far as publius is aware, this has never happened and it is unclear whether the incentives exist to the point that somebody would actually perform this manipulation, but it is worth considering whether the oracle should be changed.
• If the oracle is changed to use an instantaneous manipulation resistant value such as the EMA to convert against, that means that you're no longer converting against the current deltaB at the time of execution. This is arguably less efficient, since it could result in an increase of the absolute value of the deltaB.
• The question is whether the previously mentioned attack vector is significant enough to warrant changing the oracle.
• It is worth considering that using the EMA value would be quite tricky to implement. There would need to be some way to adjust for conversions that have already taken place against an EMA deltaB.
• In a non-zero fee pool, the operator realizes some variable cost in addition to the fixed cost of transacting, but if the Bean-ETH pool is a zero-fee pool, the atomic operation would essentially be free and potentially more attractive to manipulate.
• Reading the EMA oracle will cost more gas, making every convert more expensive. Publius argues that it is almost always worth increasing the gas cost to the end users if it results in more manipulation resistance.
• The EMA alone is not sufficient to prevent manipulation, since you would be able to convert many times against a lower value. The optimal solution is probably one that takes both the EMA and instantaneous price into consideration.
• Some sort of throttling mechanism could be used to limit the amount that can be converted against the EMA.
• It is more important to figure out a solution prior to Seeds being fungible, because the ability to sell the Seeds would make this manipulation more attractive.
• The best solution in the short term might be to use the minimum of the EMA and the instantaneous value, and then address the decreased effectiveness of convert through additional optimizations.
• It remains unclear what trade-offs are optimal for the system to make. It might be that it's not worth introducing significant inefficiencies into the system. Beanstalk might just have to accept this type of manipulation.
• It is particularly important to preserve the ability to convert from Beans to LP when the price is over the peg, as that is a mechanism for Silo members to preserve systemic liquidity.
• There does need to be a decision on which oracle to use so that the Beanstalk integration of Wells can proceed.

Transcript

Why don't we go ahead and get started? So have a couple of items on the agenda for today. I dropped them in the announcements yesterday, but will will restate. So there's two things I wanted to get to discussing and deciding on what the seeds probative rewards should be for Unripe LP. That can be changed as part of Pizza Man's work on updating the silo to use cumulative stock per BTB rather than deposits being indexed by season as well as the seeds reward for the feature being eat well that is planned to be proposed to the Dow after wells are deployed. So the only other item to that we can get to don't think the seeds for BTB discussion will take terribly long is what type of Oracle we should be using or being stock should be using for convert. And what that means is that currently converts based on instantaneous oracle i.e. the amount you can convert is based on the delta B at the time of conversion, rather some rather than some time weighted average or or something or other. So happy to set the scene a little bit for the seed for BTB discussion and anyone should feel free to fill in the gaps and speak up as we walk through this. So currently there's a waitlist for depositing different ERC 20 tokens in the silo and at the time of deposit the depositor is rewarded with stock and seeds and seeds generate stock every season of course, and at the beginning or when Bean stock was deployed, there were two tokens white listed beans and being if uniswap v2 LP tokens and the seeds per bit of rewards for both of those were two for beans and four for beneath LP tokens. And the rationale was that when someone comes to beans stock in order to incentivize providing liquidity for beans rather than buying and simply staking them in the silo, which does not help Beanstalk as much as providing liquidity. The idea is that the four seed reward would greater incentivize depositing liquidity or providing liquidity for beans, rather than depositing beans directly in the silo. And so currently the breakdown of the deposit waitlist is that beans and unripe beans are rewarded to seeds per BTV and bean three Curve LP tokens and Unripe Bean three Curve LP are both rewarded for and probably there's probably six months ago at this point. But I think that backers to open the thread and in discord and think Sink had a lot to add to this discussion as well. But essentially the question is whether Beanstalk should necessarily be rewarding more seeds for unripe rather than unripe beans. Because when someone approaches beans and is interested in depositing an asset into the silo, I mean, for one, there's no liquid market for unripe LP, but also depositing unripe LP in the silo does not benefit Beanstalk any more than depositing unripe beans per say. So I think that some of the consensus or discussion had arrived at resetting the unripe LP seeds per BTC reward to two, which is the same reward per BTB for beans and unripe beans. So that's a little bit of context, but we'll open up to the floor to see if anyone has any thoughts or want to fill in the gaps in terms of anything I may have missed. So perhaps to ask a more specific question, what are folks general thoughts on the current set of seeds for BTC rewards for unripe assets and and what they potentially may be changed to or should be changed to? I'll I'll chime in and kind of start the discussion, if that's all right, please. Sure. Yeah. So yeah so well six months plus ago, Abacus and I had originally drove this discussion and happy to see it's kind of moving forward personally, you know, at the time we were thinking, you know, to two seeds, one stock to seed ratio for unripe being deposits and right being LP deposits would be appropriate, but you know, since then we have more analytics to look at in terms of the growth of the protocol, etc.. You know, my personal take on this too, speaking for myself here, a 1 to 1 ratio may even be appropriate for both to really emphasize the fact that, you know, new deposits, whether through wells or, you know, whatever well, is incorporated and whitelisted into the silo, would be much more favored. But, you know, obviously that's up to the down stockholders who are going to have to agree to that. So I don't know how practical that would be. But, you know, we our original take was a 1 to 2 ratio, but personally comfortable with a 1 to 1 ratio as well. If that is something that other stockholders are open to. Well, can you explain the rationale for for either of those cases? Well, sure. So I think we kind of saw this a little bit pre exploit with think also just be more specific on when you say ratio what you mean Sure yeah so currently on right being deposits are allocate are one stock to seed per BTV whereas unripe being three curve deposits are one stock four seeds per BTV. And our original proposition was to just equalize them such that they're both one stock and two seeds per PDB. However, I'm personally comfortable with a one stock, one seed per BTV for both types of unripe assets. But again, that's up to the Dow to decide we kind of already have before the exploit. Pugliese You may recall we had the been LSD pulled and at the time we allocated one stock three seed per BTV for that. And in retrospect I actually think that perhaps and I'll oh, now because I think I made that suggestion along with some other farmers, but I don't I think we kind of saw that we didn't get a lot of traction in that pool and probably and you know, going back, that's probably a good thing given the exploit. But given the circumstances, we still saw a lot more interest in in the ETHE pool, in the three core pool because of that slight differentiation or favor favor in terms of the seeds for versus the LAUSD pool. And so kind of thinking about that and applying it here, I would imagine that it would be to the protocols benefit to clearly draw a line in the sand and say, hey, you know, we really favor new deposits, whether it's the being equal pool, etc., more so than, you know, unripe deposits so that new users coming into the protocol feel like, you know, they have a greater say in governance right there and not just governance, but also seigniorage through their growth and stock over time. So that's kind of the rationale. But when you say you're more comfortable with rewarding one seed per BTV to each unripe asset, what do you mean by that exactly? I speak for myself as a unripe holder myself. I mean, if it came down to it, I wouldn't mind voting for that just because I know it would be a much greater hit for me personally. But I'm thinking about the protocol over, you know, the health of the protocol and the the appeal of the protocol to new depositors. I think we would send a stronger message as a DAO to new users to say, hey, you know, new users coming in, you're going to have grown stock that appreciate accrues at a much more rapid pace than unripe asset holders and that's you know the the protocols way of extending, you know its appreciation to new users who are coming in and participating and I feel that that'll help with a lot of the you know, with the growth and just in general just participation and new community members, etc.. So that just my personal take on it. And the only rhetoric I have again guys to kind of look back on is maybe the being USD pool and the short period of time that that was live. And like if you looked at the growth of that, I think it launched maybe a week or two before the export. I think we only it grew to maybe up to like at its largest it was maybe a $2 million total. And there was a big question at the time we were thinking about this internally within the Dow and the community. We were asking, well, why aren't there more LAUSD U. Holders coming into this pool? And the only thing I could think of personally was that maybe we were we miscalculated on the seat allocation. So kind of extrapolating from that, maybe this would give us some insights onto how to approach this moving forward. So maybe we should bifurcate the discussion into whether we think that unripe beans and unripe three curves should be rewarded. The same number of seats per BTV, which we can talk about later and maybe first. Yeah, I think the point you raise I think is pretty interesting. And maybe the first thing we should, you know, reach some consensus on is whether we should be slashing both, if you will. And I think your point is, you know, more heavily favoring new depositors with regards to seed rewards. So what do what do other curious what other folks think? You know, say that I like I like were saying said that, you know obviously it seems like we've got a kind of a disproportionate situation and having folks being incentivized to convert. So any type of quality in the I'm right on unripe assets makes sense whether it makes sense to to have that fee distribution be different, different between ripe and unripe. I'm not exactly sure. Maybe we talk about whether they should be equal or not. First, they being the seeds for BTB rewards for both unripe beans and unripe three curve. You know, folks typing in the barnyard chart would definitely encourage you to speak up. But I see. Bring in Sophocles are talking about equalizing the seeds rewards for both unripe beans and unripe I guess one one dynamic that is introduced by that that hasn't been the case with liquid beans and bean three curve is that there's there would essentially be no opportunity cost to converting given that you would only benefit from the arbitrage in the bean price and there'd be no loss of seeds or gain for that matter, on the way up. Well, at the margin there is some benefit from a like a volatile perspective and hold. They like being three curve LP relative to just bean during periods of downside volatility. There is some three curve exposure. So while there is impermanent loss, it's still better than holding straight beans. And so there is some incentive at the margin, but particularly given a high chop rate, it's very marginal. So to your point guides, it's effectively the same, but that would decrease over time as the chopper and decrease. Are there any particular downsides that you see that we should be considering with regards to making the seeds for BTB equal? I guess. QUESTION open to the group? I mean, one potential marginal benefit is that on with upside volatility, people would be probably more quick to convert. Not sure if how how, how relevant that is to the discussion. But you know, just something that I was certainly considering when converting you know pre exploit in April. Oh Mr. Moti says the seed parody discussion feels more difficult as I feel there are arguments for both sides. Just depends on what you're optimizing for. Curious what you think we should be optimizing for. Agree that much is highlighted a very important distinction here, which is there's a difference between unripe versus regular acid irregular deposits and the seed parity between the unripe assets and those should almost be evaluated separately. So the the argument that the unripe holders have too many seeds compared to compared to new depositors is very true. And there's an argument to be made that which I think you've made quite eloquently, that there's there's value in the protocol explicitly highlighting new deposits relative to the unripe assets which are sort of forced, and then that that's a that's a separate argument or discussion from how to treat type assets and more. This conversation applies more generally to how to price out the seeds for the eat well, which is coming soon, and beans versus LP tokens in general, which is that Bienstock ultimately should place some sort of priority on having liquidity. Meaning to have seed parity across the board would be to some extent to say that Bienstock wants to prioritize low volatility instead of liquidity over a longer time horizon. So the counterargument to that is that once the once the outflows from the system have occurred, the system should try to incentivize depositors to repay the system relatively quickly after the outflows have occurred. So it's a question of the you know, this now gets into how the good system should work, but if we if we talk simply on the static front at the moment around seeds and in particular the unripe seeds for unripe LP versus beans, to make them exactly the same would be to encourage unripe holders to convert, to convert their in almost all instances on the downside to try to, you know, preserve, preserve the peg, or at least there's no disincentive to do so. Whereas right now there is. And that would likely lead to a the liquidity being used more aggressively. So if you think about even though bean stock doesn't have control over the liquidity that is in the system directly through incentives in an efficient market, you can assume that the incentives can guide that liquidity. So the idea is that if bean stock is incentivizing people to hold liquidity pool tokens instead of beans in the silo, the beanstalk is placing some sort of priority on people holding liquidity pool tokens, which is to say that it's trying to prioritize liquidity in the system as opposed to demand for beans outright. And that is generally a pretty healthy policy because if people can buy beans and deposit them in the silo and there's no marginal cost to not pairing that with liquidity, the system is going to have a lot of beans and not a lot of liquidity, which will ultimately lead to more downside volatility once the one once the system enters some sort of down downward cycle. And the the concept is that in order to minimize both the excess beans that are minted and the the downward price movement during the downside, both are the down yeah, the downside volatility during the downside fall bean stock does play some sort of priority on having liquidity. Now the interesting thing about the unripe liquidity is that it is locked in the system and so there's some question as to what is the primary value that that liquidity is provide. Is it just that it's anchoring the system sort of independent of price, which is what's happening now or should be used to incentivize that liquidity to maintain a relatively tight peg or a very tight peg through seed parity or even through inverse feed incentives, where you could say that if Bienstock pays you more seeds for BDB for having been deposited as opposed to LP tokens, then you'd assume a very tight peg. So the concept is how should, how should bienstock incentivize this liquidity to behave? And there is an argument to be made that right now it's not being aggressive enough. The question is how aggressive to make it. And if if ultimately this is going to be kept static, which it seems like the for the for the beginning implementation of this upgrade, it will be static before a basic gauge system has been implemented. Now it's like, well, should bienstock really incentivized through parity some sort of should it not incentivize or take a position on what the liquidity should do explicitly? Should it should it incentivize the liquidity to convert more than it is now, but not as much as, you know, parity? This is this is sort of the question at the moment. And see the she left. So we'll sort of pause for someone to read that out and also for others to comment. I'll go ahead and read out Mr. McKay's comment. They say I believe a 1 to 1 ratio partially solves, for lack of unripe converts below peg. But at the risk of longevity right now, people have to exit below peg to and don't extract as much liquidity. Once people convert upwards, you rebalance the pool, but you give out the unripe liquidity at a faster rate to if you go for a 1 to 1 ratio and unripe and people do not convert convert above the peg, the unripe liquidity may not regenerate again quickly enough for the next outflow, which lessens the potential peg maintenance stored in the unripe LP and creates a spiral effect. Yeah, I think Mr. McCain provides make make good points that if there are going to be outflows and the and the rewards are are at parity such that people are converting immediately and the peg is very tight, the people exiting would be extracting more liquidity than they would be otherwise, which is an interesting, interesting argument. Now, I guess I would just add on that, you know, there is a fixed cost to converting and that fixed cost is a cost in, you know, ether for your transaction fee, you know, So even if there was stock C parity. Well I guess and then secondly holding D in three curve is a less risky position from holding being from the perspective of a significant downside peg in the case. You know, so holding being versus being three curve in the case where or being goes up, it's better to hold B but in the case of being goes down it's better whole being three curve think most you know being is extremely good at returning to the peg on the upside but you know kind of seems to be hanging out a little bit longer on the downside from that perspective. You know given that the biggest risk is some sort of bank run holding, being three curve is always strictly better than holding being from that perspective, given that, you know, kind of, you know, on the downside, you're going to see way less drop in value than if you're holding being. Now, from that perspective, you know, kind of let's assume there's parity between being ab3 curve, right? So for every convert, the user is imposed in sort of fixed cost. And you know, at the margin, the user is willing to hold being three curve. You know, so just just would say if there's already incentive to hold being three curve from the perspective of it's a risk minimizing strategy he you know would imagine that you know still see significant converts on the upside, especially from participants, you know kind of helping to benefit the system. You know, I guess the next kind of side of the question is, you know, where does the externality lie? You know, from converting down, there's a positive externality to being stock, you know, converting down from a but, you know, from converting at all. There's there is a positive externality to being stuck in the sense that, you know, the peg is being restored quicker. And, you know, however, on the downside there is the fact that the liquidity decreases overall from the upside. You know, it's a strictly beneficial position for being stuck in the user of now the user is holding a less risky asset, you know, in being three curve, and that's assuming you think the risk of holding being is greater than the risk of holding three curve. But, you know, so from that perspective, it's like converting down. It's a better position for being stuck is the peg is restored and you know, it's restored quicker, liquidity grows and the user now has is holding a less risky asset. You know, from the perspective of other users, there could be argued that there is a negative effect from the sense that now there is less being maintained. And you know, however think you know, you know, that kind of mentality isn't necessarily aligned with the success of being stuck in the long run. So I would argue even if there is doxy parity, there still is significant incentive for users to convert. On the upside. Guess the question is, is that incentive, you know, greater than the cost of submitting a transaction to convert, as everyone knows, converts can be quite expensive, especially, you know, during periods where gas prices are high. So, you know, from this perspective, the goal should be to kind of set the convert incentive equal to the cost of converting. You know, maybe that's already the case and maybe it requires some deviation in stock. C parity for that. But you know, from the perspective of, you know, obviously once there's a stockade system, this problem gets alleviated. Now, you know, comparing, comparing the unripe liquidity, you know, the situation where now there is also unripe liquidity, it should just be mentioned that, you know, there is, you know, you know, you know, there is more I guess, you know, I don't know how to say, you know, there is more liquidity that is vesting than there are outstanding beans. So from that perspective, you know, if every outstanding being sold and all of the unripe liquidity was instantly converted on a price of one, meaning that, you know, there was like some sort of auto convert where the liquidity was automatically deployed to buy every single bean that was sold, you know, Beinstock would still be able to maintain its peg. So it is an interesting perspective of that from, you know, given that so much so, you know, such a large supply of the beans is locked up inside of these, you know, vesting assets, you know, kind of bean stock is in a position where it could deploy all its liquidity against, you know, every single bean could be sold, it could deploy all its liquidity and still be in a position where, you know, it could be restored to the peg with a significant amount of liquidity. So with that in mind, you know, one might tend to take that as a sign towards, you know, converting up, you know, you know, or a stock C parity might be a priority at least, you know, for the unripe assets, but you know, would definitely be way more weary when referring to the, the non unripe assets. Yeah. Agree on the concerns of making the liquid bean and being thicker seeds. The same. And I don't think that's necessarily the the goal of this discussion, but still worth talking about in the context of of what we are discussing. And yeah, the point you make around the benefits to converting on the upside, even if the seeds for BTB are the same, I think are pretty compelling. Yeah, it's hard to say, but given what Pablo's just outlined, I think I just personally are a little more inclined towards seed parity for the unripe assets, which is independent of whether that should be, you know, 1 to 2.5 or or something else. And just for reference, a bean three curve token right now is worth just over 1.04 beans, you know, which means every, you know, everyone holding Bean three curve right now has, you know, kind of received 4% less a decline in the value of their position since the last dip had been bean holders. And, you know, given the way that, you know, curve concentrated liquidity works, the further the price deviates, you know, the greater the marginal benefit to holding bean three curve is, as you know, smaller deviations in the reserves of liquidity lead to larger deviations in the price. I mean, I would, you know, bring up the question of, you know, whether even with stock C parity, is there a significant, you know, enough incentive to convert given that, you know, people can already update their BDB four in rooting their unripe assets? You know, kind of given that given that people can group their unripe assets to update their BDB whereas you know, before, you know, users would have to convert to update their BDB, it kind of gets rid of the, you know, the additional benefit to capturing the, you know, the arbitrage when the price is less than one, you know, it is noted that, you know, converting on the downside, you know, seeing that, you know, for instance converting now will give users like a 5% gain in actual the underlying asset. But in terms of the the beanstalk store BTV value, they won't gain any benefit on the BDB side when you and Root Beanstalk updates all your posits to be the current BDB. So if you were to convert, you know you would get the benefit of now you have more beans, but you know if there's beans are just going to stay deposited, you're going to have the same amount of stock in seeds than you did before. So there's a much more significant incentive to convert for the ripe assets. You know, I don't know what the ripe the normal bean and being three are given that you actually get you know you actually realize realize the the extra assets when you convert as opposed to you know kind of it's locked anyways and you get the same stock in seeds. So from that perspective I even question, you know what the incentive, you know how strong the incentive is if their stocks see parity, given that, you know, most users are probably actively in rooting to update their BDB. So you know, from converting on a downside there's this you know positive social you know, this positive public externality in the sense that, you know, people, you know, the perception, you know, that the being price increases, that the cost of liquidity, which may be positive or negative depending on you know, a lot of, you know, factors in you know, in general, there isn't necessarily that natural arbitrage to capture in the active, you know, I just play by beans with my being three curve at a price of, you know, one over 1.5. So, you know, it's still unclear to me whether even with stock parity, the incentive, the downside is sufficiently aligned. You know, and now that's you know, that's an incentive that, you know, generally, you know, the system should be conservative with as you know, as we've discussed several times on the call, the risk of deploying too much liquidity is probably greater than the risk of deploying not enough liquidity as liquidity can always be deployed later on. So just would add that far, employing liquidity is a pretty funny way to say it. Sure. And and I guess, you know, it'd be interesting, you know, not sure if it warrants some sort of like pull, but it would be interesting to see what you know, whether people would convert Now if the stock seed parity or even for unripe assets. So I guess, you know, like an open question out there to, you know, unripe token holders, you know, kind of assuming their stock see parity and, you know, kind of you can convert your being three curve to being at any point, you know, but, but there is kind of a marginal incentive to do so, you know, but, you know, kind of there is the perception of the price going up, which could be considered, you know, some public externality. But, you know, there's the decrease of liquidity, which is, you know, a negative, you know, kind of public externality, I guess, You know, would people convert if there was a stock's the parity on the unripe asset? And I see I made a straw poll in the barnyard, John. So, you know, for those who feel comfortable sharing what they might do, please feel free to vote in the poll. So it seems like there's an overwhelming vote. It seems like, you know, pretty much I guess the guy had to vote no. But, you know, nobody voted no other than Guy. I mean, I guess the question would be say there was, you know, 2.2.2 seeds per BTB, per unripe, all token and two seeds per BDB, per unripe bean. You know, I guess where is the point at which, you know, kind of the marginal point where, you know, someone becomes no longer willing to convert because the, the utility from the, the extra stock is sufficient such that, you know, the opportunity cost of losing that from convert is greater. Hi, guys. I'm in favor of of retaining liquidity or protecting liquidity. So I think it's best or the better for the whole protocol not to not to have party, but given if it passes existing, then my best option would be to convert. So better for me, but maybe not not good for the whole protocol. That makes sense. I guess it just depends on what you value more. You know, liquidity or the being price. I think that is the trade off to make or the tradeoff to consider whether to make or not. Rather, as a long term holder, I'm like, okay, with the with the volatility, let's see. But definitely more keen on protecting the overall liquidity. By the way, on a on an unrelated note, noticed just noticed, Chris, Chris has been in the voice chat. So Jim search for reference for you know community members were sponsoring some of his transparency work and design think he's taken a close look at Bienstock maybe we can have you speak a little bit about what you're working on at the meeting later this week or next. For reference, these discussions are sort of public design and development calls. We have as a community to arrive at different, different decisions like this. Thank you. Thank you. Excited to be here. So learn more about the project and I appreciate you and start from sponsoring like report. I don't know if I'll just be hanging around and I'm starting from scratch, then my asking the questions now and then. But I'll allow comments like I just did that never seemed appropriate. Totally. We're we're certainly throwing out a lot of bienstock native terminology at the moment, but, you know, you'll get there. So with our help and hopefully the documentation and such. Well, it's interesting to see it's information about most folks that interested in converting. I guess one next question to answer would be kind of related to MoD's point about whether those conversions are not good for Bienstock. You know, given that there is the trade off of decreased liquidity for price stability. So, you know, it seems somewhat clear that people would be interested in converting if Tea Party existed. But what do folks think about, you know, the positive and negative externalities to the beanstalk itself? I guess think about all we can think about it from another perspective. If that actually exists, why would one not always convert? So we are in a situation, let's say that, you know, there is a large volume of of capital that's living or existing. Why would one not always convert even when you see that that's happening and you're giving them a better price? It's still from a game perspective for me, you know, individually, it's always best for me to convert at this time, I think. Yeah, sorry, go ahead. Yeah, I think last time the protocol was minting on a more recurring basis, I think sometime mid fall, as I recall when we were above Peg, a lot of people that were I think it was all over Twitter, people were trying to, you know, people that held on right. Beings were trying to convert to LP Right. To benefit from, from being a peg. And it was just, it was very hard to do that. So I would imagine that we won't see parodies in place. There will be a rush to, to convert, at which point we return to Peg and the, you know, the, the volatility around PEG would probably be much more minimal than what we've seen thus far. But again, to Chris's point, like we should all just assume here that everybody's going to be acting in their own best interests and not in the interests of the protocol as a first assumption, but I would just look back at the data from from that period when we were last above. Peg, I can speak for myself personally. I recall that it was very hard to convert beans to Unripe LP and were about Peg. So a lot of people had, you know, transactions that were being rejected, etc. because there was only so much that you could do. So I would imagine we would have we would run into the same situation here. There would be an initial rush for Unripe LP below Peg to convert to Unripe Bean. We would return to Peg and then, you know, we would we would go from there. So I'm not sure if I follow you because I think the the challenge would be being transformed by abattoirs for something different than the capacity it had to do with one thing to keep the protocol meeting go. I just wanted to comment on the conversions, long term costs for being stock. I think sometimes they're good, sometimes they are. And the question here, do we want to give an incentive for people to actively conversion as an expense or maybe the opposite? So when you do shift parity again by default, you're telling any participant always arbitrage the price of being. It's always your best method of arbitrage. The price of even if it's that's for the overall protocol. Well, I think the problem is as point there are a couple other considerations and maybe perverse. It'd be helpful if you could restate those like related to gas costs and exposure to the underlying assets. I don't quite remember, but there are others happy to. So like on the on the unripe side and you know, like first off, there is a, you know, a fixed gas cost associated with every convert, you know. So already the you know, kind of the incentive must be positive. And there's also a 0.3%, you know, trading fee for all of, you know, for anything that ultimately goes towards swapping, which is probably about, you know, just I think over half of the position. And so, you know, there's this fixed fee that you're paying, which is a fixed gas fee plus, you know, I guess it's a 0.0% fee on just half of the position. Now, the next question is what is the actual delta value? You know, kind of for an unripe LP holder? You know, yes, it is true that if being is significantly below peg and you convert, you get more unripe being, but all unripe assets kind of vest and become whole at the same rate. So as an unripe LP holder, you aren't necessarily capturing or realizing the value of that arbitrage. You know, as effectively as someone else might be. That's converting being three curve to being, as you know, you might in the short term. I mean, I guess it would give you more unripe beans, which in the long term would eventually vest into more beans. And on the unripe piece I'm converting down. So you are kind of increasing your net exposure. But, you know, kind of the only from the perspective of once things are eventually ripen and users are made whole now, you know, kind of the math kind of to convert between the two is a little funky. So recommend people reread the the white paper page on this in the appendix that kind of specifies, you know, the convert rate between the three core or unripe being three curve and unripe being and familiarize themselves with that because kind of the math kind of fixes around ensuring that the capital, the amount that needs to be recapitalized is the same and isn't necessarily like a direct and it isn't necessarily ensuring that you're getting a 1 to 1 mapping with the underlying value. Now, kind of from the stock and seeds perspective, when you convert, you know, on the downside when it's significantly deviated, you get to capture the delta amount, which is, you know, the actual amount of tokens you accrue through arbitrage, the Delta BTV, and based off that Delta BTV, some sort of Delta stock in Delta seeds. Now with in routing you can already update your BTV. So no longer from converting with unripe assets you know are you able to or do you recognize value from converting in terms of the amount of stock in seeds that you, you know, that you get from converting? So if you just routed and now you convert, you know, I would imagine that, you know, the amount of the delta on this stock in seeds is about neutral assuming their seed parity. And so therefore it's like you know with the and right assets there's already like inherently this this lower incentive to convert already because through even rooting you can already maximize your silo position and you know given you know it is you know potentially you know given there is less volatility on the downside with being three curves, that being, you know, a more beneficial position to hold relative to the right being potentially. Again, it's all kind of fuzzy because you have to factor in the effects of, you know, vesting in that kind of, you know, kind of you eventually being paid off at some point to significantly. So, you know, kind of the the incentives are kind of there's a lot to consider from the end right perspective. So just to briefly summarize our been mentioned, they didn't quite understand whether the conversions would be good for stock long term and on this and think that the main trade off is being made between the price and the liquidity. So if you can curb excuse me, if you convert unripe bean three curve to unripe beans, you are, you know, increasing the being price but decreasing liquidity for beans. So to me that that seems like the primary trade off. And so given that it seems like most I mean folks on this call anyway and obviously, you know unclear how much we account for total stock. But the the point is that most folks on this call would be interested in converting their unripe bean three curved unripe beans. If the seed for BTB rewards were at parity. The discussion is kind of around whether that's whether that's not good for being stock or not. So separate from the theoretical discussion, I think it's important to take into context where the system is so currently we just going off the numbers on the money here, there is 2.2 million beans in the silo that are not part of the on the unripe assets and another 300 K in farm and circulating and 200 K in the pool. So there's only 200,000 beans in the pool itself. So even if you consider that all of those beans may be sold in theory, although you could argue that it's unlikely, although I'm sorry, there's a lot of mutual interest to go somewhere else, You could argue that the you know, those beans are unlikely to be sold, but let's say that they are all sold. Let's now consider how much liquidity there is in the unripe assets. There's currently there's 26 million or so ripe being recurve. And then as a as a percentage, I'm not going to the per website to get the exact breakdown where right now there is 14.5 million beans and about 11 million in liquidity. So there's three call it, call it 3 million of sell pressure into $11 million of liquidity. So even if the system incentivized maximum conversions did something even more extreme than parity, there is some floor price, assuming that after the conversions, everything was sold, you could where, you know, that may be some somewhat acceptable to the Dow given the current circumstances and by circumstances means like that. The the gauge system or a preliminary gauge system should hopefully be implemented within the next 6 to 9, and particularly given the lack of financial activity happening on chain, there may be some value in being stuck demonstrating tighter peg stability over the next couple of months instead of just low volatility, but downward volatility. So it's an open question as to let's say it takes six months to get a gauge system, a basic gauge system implemented. How long should a how how much downside volatility is the is reasonable to accept? And the concept is that right now there's there's a fixed amount of downside volatility assuming a complete exit from the system whereas to repackage would potentially lead to a larger increase in in the beans that exist they could leave the system. And so it's a question of should the unripe assets continue to be maximally incentivized to convert, to maintain the peg in all instances through some sort of parity should there be more of an incentive on the downward side, as has been the case, which seems to be it seems to be hurting the peg maintenance, given that so much of the liquidity is currently unripe. But on the other hand, as was pointed out, there's only so much marginal benefit to actually converting the unripe. And so there is some question as to how much will people actually be converting. But it seems like it seems like there's a strong argument to be made given the lack of liquidity that could exit the system. Right now it is in the interest of Beanstalk to have a tighter peg and then at some point in call it six months again system to be implemented. That could then more eloquently manage the ratio based on a variety of factors. I think that's a great point and yeah, hadn't really explicitly been said until now, but and maybe this isn't the best way to put it, but I do think that, you know, Peg stability to some extent is being stuck, want to be in stocks, best forms of marketing, if you will, and particularly in the context of how soon you know, even if it's not next quarter or the one after that, a gauge system would be implemented. That is something to take into account as well. Does anyone want to make a strong argument against parity? Well, you know, to some degree, you know, the situation you laid out Publius, where it's like there is enough convert power to convert against every single being is great. And, you know, however, if you know, being gets in a situation where no longer has enough, you know, liquidity to convert against all liquid assets, then that's a very different situation. So You know, I guess, you know, kind of to turn the table on that question and say, so what? What would it take for being stuck to be in this situation where, you know, it doesn't have enough liquidity to convert against every single being? And, you know, there are really two instances, you know, kind of where that could happen. Number one is like, you know, there's too much external minting for things like budgets, you know, big six, you know, budgets, audits, etc., such that, you know, that some eventually submits, you know, is greater than the number of liquidity, you know, given how, you know, the pace at which beans are being minted for that purpose. It seems like it would take several years for that to happen. The second case is where, you know, a lot of minting occurs such that the amount of beans minted, you know, makes it so that the total liquid beans is greater than the total liquidity. Now, this would only happen from from my perspective, if the incentive to convert downward was still was too low such that, you know, bean stock was above peg minting beans and it wasn't acquiring liquidity at a fast enough rate to cover the, you know, to to cover to have enough liquidity to, you know, pretty much cover all of the new mints. So from this perspective, it's like, you know, so long as, you know, people feel like there is still a proper enough incentive to convert when that bean price is above one, you know, bison, you know, substantive amount, you know, in order to convert down from unripe beans back into being three curve, you know, and again, it's like there's a marginal benefit in the amount of stock you might get in seeds, but it really is quite marginal, you know, especially because above peg deviations don't seem to be near as large, at least not yet as deviations below, given the current convert incentives. So maybe it'd be helpful to do, you know, a poll on on that and see, you know, whether you know, whether people would still be willing to convert from unripe bean to unripe being three curve given that kind of there would be seed parity? Well, to some extent this is like the question of liquidity to supply ratio. And given the beans are not collateralized by anything, there is no point at which there will ever be enough liquidity to cover all the beans. Even if there was 100% liquidity supply ratio, because the liquidity itself is owned by someone. So 100% liquidity supply ratio is just the maximum. You know, liquidity you can basically get where you have $1 of value trading against each bean that exists now through, you know, but we are talking from the perspective of well, only the unripe assets, as far as I'm aware right now, we're not talking about a world that includes, you know, that is limited to non unripe assets. Yeah, but the thing that we're considering is if if the unripe assets are a parody and the system repack eggs and then there is some sort of excess growth in the bean supply such that the unripe assets and the unripe liquidity is no longer significantly larger than the other bean supply. What does that imply? Right? And what where does that leave the system? And the point is, at that point, there is still at least currently a difference between the seeds for regular LP tokens and regular beans. And perhaps this, you know, seeps into the commerce ation around the beanie as well. LP token. But at least from my perspective, they're somewhat into I mean, you can't really say they're independent, but there are systems that operate somewhat independently, meaning that the way that the unripe LP tokens are incentivized is separate from the way that the normal and normal deposits are incentivized and the normal assets are still heavily incentivized to convert to LP tokens, at least as of now. Don't understand that to be, you know, something that people are discussing. Change it for the moment, right? So if there is a large inflow of new assets into the system because Bienstock has re pegged, the expectation would be that those new assets would still be significantly incentivized to hold LP tokens rather than just be. So would be very interested to hear if other folks have, you know, arguments they want to make in favor of not having seed parity for the unripe assets, but feel like we're sort of converged to some extent converging on an answer there. So I don't have any objection to moving on to discussing since earlier point about, you know, what the value should actually be. You know, is it the two? Is it one at 1.5? Right. So if folks feel like it's appropriate to talk about that now, perhaps. Well, I mean, before we can really do a straw poll, feel like it's worth talking about, what even the potential options are, which is unclear. Brian made a point earlier that I that I had we hadn't talked about verbally for the recording yet, but Brian dropped in the chat that one of the upgrades that is being made to the silo is one that allows the seeds for beta BTV rewards to not no longer be just hold numbers but can also have up to six decimals. So that's something to consider as well now that you know that sync so talked about some potential options like reducing the both unripe asset rewards to one seed per BTV curious if folks have any thoughts there and then we can do a straw poll as well. So feel like there's still two separate questions here. One is whether or not the unripe assets should now be at least equivalent with bin deposits. And, you know, hard to think of a good reason for that to be the case, given that the unripe asset holders are pretty much, you know, they're their incentives are such that it would be ridiculous not to hold your unripe assets in the silo. Really, Because the returns from having the unripe assets in the silo because of the stock that they have, because the recapitalization percent is so high that it it would be crazy not to to hold your assets in the silo from an incentive perspective. And so given that that's the case, then the question becomes, well, why have any seeds at all? And the at least, you know, at the moment grown stock rose literally from seeds and there is some maximum rate of in stock as of now that the system is powered at four seeds or stock or port per BDB and a minimum of two. Seems like there's no reason, at least from a theoretical perspective, you can you can lower that to zero. But if there's no growing stock incentive, that fundamentally changes the incentives around the silo because the grown stock creates the opportunity cost associated with leaving and coming back. And so particularly given that, again, for the unripe assets, leaving and coming back doesn't really affect the stock. It doesn't necessarily make such a difference to give any sort of real grown stocks. You can you could make an argument that unripe assets don't deserve any seeds, although given the amount of stock that the unripe asset holders hold, unsure if that would be acceptable to the Dow based on its current construction. But on the other hand, a lot of this reconstruction of the seed incentive seems to be based on the goodwill of the Dow trying to get the incentives right. And that's, you know, that's something worth considering. But even if it doesn't go to zero seeds for BTB, which would be a little extreme, there's an argument to be made to lower it to one or even potentially lower than that. Now, then you know what that what that number actually looks like is unclear in terms of how this factors into the beans conversation and the beans and beans Reaper, it seems almost entirely unrelated. So I want to want to bifurcate those two questions. I agree that they're different. You know, maybe one other thing to add is that, you know, with regards to honoring the terms of the barn raise as the PDB of unripe assets or Unripe assets increases, you know, theoretically, you know, without accounting for crops or converts, you know, ones revitalize stock and see what approach they're pre export values or amounts, rather. So we are just talking about, you know, moving forward, post replant post today, what the grown stock that you would earn and how that would change. The point being don't really feel like it's any any corruption or compromise on the terms set out in the barn raise personally I'm typing up a straw poll, but folks should feel free to speak up and, you know, raise any arguments. Just drop to the straw poll in the chat. Let me know if you feel like that is not structured appropriately. Also, I realize I'd probably be better to make a choice one less than or equal to one rather than less than one. So just anyway, I guess that changes your your votes. Just made that update to the poll, but could you clarify what you said in the chat? Yeah. So what I'm thinking is what if we so we keep the seeds as that is to give an incentive for those sold in the sale to provide liquidity over holdings. But have a cap on how much each PDB, how much stock each PDB can have. So that is a max. And then you'd expect that those who have reached that maximum to them, you know, their incentive would be to convert and not to just hold LP. So you kind of have like a balance maybe I don't know about that, but long term holders will be the ones converting, while others would expect them to hoard liquidity. If this makes sense. Yeah. The concept of maximum stock is an interesting one where currently stock rose linearly and the beauty of linear growth in stock purchases is that the if someone joined X period of time ago and now I join with the same PDB that after extension of time, their benefit in borrowing stock over me will be cut in half. Well I guess it was had it not but it was zero. But the concept is whatever their benefit is, they now have to x, I have x and after another period of x now or after another time period, now they have three X and I have two X. And so the marginal benefit for coming in early decreases over time. Now there are some argument to be made to impose some curve instead of a line such that the marginal seed for BDB decreases over time and maybe approaches some limit. And then there's a separate question as to whether or not it should be totally flat or whether it's from an incentive perspective, it's helpful to have have there always be some marginal benefit for being earlier? Now you do get some sort of fungibility at the max t for BDB start for BDB levels. So that's actually something indirectly to consider, but feel like at least for now, that we should keep that to be a separate discussion. I haven't thought this through entirely, but also feel like it could be argued that the desired maximum stock per beta has been reached given the interest in discussing this concept at all. But just my $0.02 might. When you say max stock or higher incentive to convert, you mean the higher your seed per BTV ratio? Or like what is Max? There's no current max Or do you mean when BTV equals stuff? It's this idea of having some sort of cap in the stock. Are you suggesting a cap, Max? Yes, that's my friend. That's the suggestion. Yeah. That's, that's what he was just talking about. Or if we had some sort of cap in the stock for BTB that that would then create, that would, that would I mean I don't know if you could say that creates a higher incentive to convert. What it would do is in practice create parity, seed parity and, remove the ability for being stock to incentivize the liquidity to move one way or another so that that's not that's probably from a like allowing the stock to maintain the most control over the market perspective. That's probably not optimal, but it's definitely worth considering in the grand scheme of things, but probably not for this aspect. Yeah, I mean, I think there are some, you know, you know, this would make some economic changes to the model that, you know, it would require some substantive thinking and discussion. And you know, currently as it sits, you know, either of these changes making can be a function of, you know, stock per DV and or increasing a mac stocks loss. Changing it a curve would be quite substantial changes to the current siloed structure. And you know I think are out of the scope of the current discussion with you know in the out of the scope of the update in which discussion is know in the context of it seems like there's a little bit of consensus around the board being less than or equal to one. Do folks think it's worth another straw poll to the to sort of narrow in on what what that value even in that range should be? Not sure that we need to decide now and feel like this is more of the general consensus that then we could do like a larger straw poll, some capacity over the next week or two, given that this this isn't going to go out today or tomorrow, great. So in that case, I feel like we should or feel like it would be appropriate to move on to the reward for being eighth. But we'll pause for a sec to see if anyone has anything they want to raise first. So with regards to the beneath, well, I think that, you know, one of the impetus for something like a gauge system would be one where stakeholders can decide in real time what they believe the optimal ratio of non being value that beings should be trading against at any given time. So, for example, you can imagine a scenario where, you know, maybe there's only two liquidity pools being three for having been if and the Dow elects or just even an individual stockholder elects and says that, you know, being should be 75% of liquidity should be trading against if for potentially decentralization reasons and 25% three curve props the rationale would be for a lower volatility or something like that. So and this is also related to the discussion that some folks have had around, you know, exposure to tether, which I think there is potentially a thread about in the ideas channel. So yeah, open question as to what the being eat well seeds forbid the reward should be you know should it be higher than the being three curve LP should it be made for and should be being three could be lowered should it should they be the same? Curious to get some preliminary thoughts from from the room for reference pre exploit both the being three curve LP token on curve and the beneath LP token on uniswap v2 where both are rewarded for seeds per BTV and even despite the UX friction around having to visit the curve site to deposit liquidity and then you know, run a separate transaction to deposit that LP token in the silo, I think that the ratio of the liquidity in the being three curve pool per exploit was increasing dramatically. And I think try to pull up the old dune chart to see if I can find some interesting data there. So it looks like at the time of the exploit, the been three curve liquidity was about just over 50%, despite not being whitelisted until a couple of months prior. 50% of a lot of overall liquidity for beans and the and and three curve pools were at seed parity at four. That's right. And the being closed pool was rewarded. Three received, although to be honest, not sure how accurate this data is given that it says the. So I think this chart may be actually it's actually just the number of beans in the pools. And so I think liquidity at the time of the exploit was around 140 million. And this line I was hovering over may have been like a few hours in advance of that. I think several. So anyway, so that's why the total in this chart says 64 million, because that was the number of beans in the in the whitelisted liquidity pools a few hours before exploit. Let me know if that doesn't make sense. So the point is the liquidity will flow based on the seed of something. Yes. Which to some extent we already know. But it is good to see the data verify that. So that would imply that being shocked should impose probably some sort of parity in this case as well, because is there any reason at this point why being would prefer even exposure versus three exposure? Maybe it would prefer if exposure for the time being at the margin because all the unripe exposure is greater, but then you're going to create some sort of arbitrage between the two pools, which will bleed value from the system. But I guess that will exist in any case. But the point is, if all the new value is going into the need for charging now, but it's hard to think that being soft should really be taking a strong position at this point on it versus the risk of exposure, although, you know, maybe the Dow's position on being weaker versus it has changed over the past year. So that's but but, you know, it's hard to imagine that there's a strong argument to change what was working before, although, again, the gain system will will improve on this dramatically. I just want to mention, you know, one of the key differences in addition to, you know, the fact that it is to centralize in E versus three curve is the capital efficiency and the concentration of liquidity within the pool, because three curve is exposure to a relatively stable asset. It's you know, with the pricing function, it's very easy to create concentration about a peg, you know, whereas, you know, kind of the current plan is to launch the, the initial beanie pool as a constant product pool, which is just naturally going to have a lot less concentration around the pegging, you know. So therefore, you know, it would be interesting also to compare the graph of volume in volume in the being three curve pool versus volume in the beneath pool. And you know, if that comparison was made, I think it would be the case that there'd be a lot more volume in the b e curve pool just showcasing that, you know, liquidity in the B and three curve pool is much more, you know, provides more utility than liquidity in the beneath pool as it provides for much more for much less slippage, you know, you know, or price movement for trades, given that it is concentrated. Now that being said, the current three curve pool has an eight parameter of one compared to an eight parameter of ten, which the initial being three or four had, you know, so so the the effects will definitely be dampened than they were pre exploit but is still quite significant. But as has been much discussed, there is value for being stock in limiting its exposure to three curve, which is like a common denominator of the three tokens that it's made up. And so there are some question of peg maintenance and liquidity and in the system and decentralization of of liquidity, the assets that constitute the liquidity. So a fascinating trade off and go ahead. Yeah, just one more thing to tack on to kind of the pros and cons is, you know that, you know, it should definitely take into context the oracle that each, you know, pool would be using. It's likely the case that you know the being it pool will be using the Uniswap V3 or maybe you know multiple Uniswap pools in order to determine the ETH USD price as that seems to be the best on chain indicator of the off chain price of a dollar. And you know, that being said, it still introduces to potential centralization risk of usdc, but not that of know tether dai you know, currently, you know, the three curve price is determined by an average of tether dai on usdc but you know kind of the usdc ether price exclusively relies on usdc see as the source of, you know, truth for the price, you know. Now that being said, you know, in Oracle that aggregates ether, tether or ether usdc could be used, you know, but but then that doesn't fix any concerns about tether potentially, you know, tether peg or usdc peg as it's like now we're taking the least common denominator. So even on the ether pool, it's just you know, it is important to note that from an Oracle perspective, there is still exposure to the price of usdc, you know, and or tether kind of whatever is decided. Can we not derive the price of ether in these and then drive the price of beans in dollars from the three or four? No, there needs to be a you need to be able to get you know, I mean it's I mean, I think that you can't use the pool that's being evaluated in the Oracle itself. You need an external link between USD and ether and the where is the internal link. I mean, in the situation you just mentioned, we would be using, you know, the being ether pool to determine the price of ether and bean and then using that same pool to determine the delta B between the oracle. That was just so the delta B would always be zero. In that case. Right. So I guess one read of this chart is that the exposure to each asset were equal by the time the exploit. But personally I would have expected it being three curve to continue increasing given the, you know, exposure to or lack the lack of exposure to more volatility and you know, with regards to the discussion around the being exposed to the most centralized asset in the three curve pool, personally feel like it makes sense to have some slight incentive in favor of being ETH, but it's also hard to say. I mean, because if you look at the being USD pool, it didn't attract very much liquidity at all, despite having more seats than being deposits. And maybe that's because the USD supply is lower. Could be a bunch of different reasons. So it's kind of hard to say pipe up a straw poll just dropped another poll in the biannual chart. For everyone's reference, Cosima asks Do wells introduce new system for defining the seeds incentives? I'm not very familiar with this, but I thought there's discussion around dynamic seeds. They are different discussions. This is a to discussion is if the Dow is to whitelist a well LP token particularly in particular we're talking about it being equal. What would be an appropriate seeds to reward that which is separate from the design and implementation of a gauge system where stockholders can decide on that optimal exposure of liquidity in real time, which hopefully we'll be able to talk about on Thursday and Thursday. Staff call Backus and Quasi Matt would be interested to hear your arguments in favor of keeping the seeds the same for both the Being eight and three curve. If you're willing to share. Hey. Yeah, I accidentally hung up instead of meeting myself. So like, my basic thought is just this might not be relevant because I was thinking specifically about like my impression of how Wells is going to be implemented. Like what? I saw that. But I was just thinking like, if one of the purposes of Wells is to try to allow people to implement like an investment strategy, then we should allow them to do that without kind of like co-opting the incentives of like where they want their liquidity to be. But it sounds like this isn't relevant because is like a wholly separate thing from Wells. Will you be able to convert ab3 curve LP token deposits to B, I'll be token deposits theoretically, but the exact nature of that is still undetermined. You know, I think there is a dev call maybe tomorrow to kind of walk through the design of the well convert b b and minting formulas. I thought that was supposed to be the back half of this call. I think my understanding, my understanding was the back half of this call was strictly to discuss the Oracle related to convert, not specifically, you know, what types of convert will be implemented. You know, at the very minimum a B in being if you know, convert will be implemented in that from from that perspective, you know, it'll always be possible to convert across the two of them. You know, when one's above pagan, one's below peg, you know, however like some sort of convert, you know, assuming both are at peg or you know, such that you know the peg, you know, to just do like some fall convert to peg and continue to convert between the two is going to be, you know a mathematically difficult problem to solve. You know I imagine, you know, they'll need to be a couple of weeks or days spent solving that math at a minimum, if that's kind of a desired result to continue with. So yeah, I mean, at the very minimum there'll be a being if being convert and vice versa, you know, whether it makes sense to enable, you know, a B being three curve to being eve convert and vice versa is a topic for discussion. But don't think the scope of that is quite understood. Yeah. For instance, it would require, you know, deriving some sort of mathematical formula that can guarantee you that the price will never, you know, that will guarantee that conversion, you know, someone converting between the two, you know, the price of them will kind of be average to, you know, the actual execution price will be the average of the prices in the two pools such that, you know, the net effect on Delta B is at most, you know, kind of or the net effect on Delta B away from the peg is zero. Or couldn't you just remove liquidity from one for like if you have been three to sell it? So the three for you are unlikely to sell and then yeah, but there's no guarantee on the price that you're going to get. So it's like when you remove that being three curve and being, you know, let's say you remove it at an equal ratio and then you sell that three curve into it, say in the tri crypto pool. There's no guarantee that when you then go ahead and add that liquidity, especially after the fee from transferring the three curves, if you know that the execution price is going to be the same, maybe the pool you choose to swap the three curve into, if maybe like when removing the three curve, you choose to remove it into usdc and. You know, for some reason the pool is unbalanced towards usdc the three curve pool. So you choose to remove it as usdc and swap that usdc in the uniswap usdc for which is going to be the oracle for the, the you know, the the beneath core. Now it's like, you know, you could really slippage or some sort of fee on that trade. And given that that slippage and or fee is undetermined when you go ahead and you know you take the beans you remove from the bean three curve pool and you take the eth that you just bought, you then go ahead and re add that into the existing being ether. Now there needs to be some mathematical guarantee that the, you know, the ratio that you're adding at is actually within some significant, you know, some some reasonable margin of error compared to the ratio you remove that I guess like one potential attack vector here would be, you know, someone could perform, you know, some sort of flash loan into the trie crypto pool if that's being or into the usdc if for basically making it. So the slippage received on that conversion was quite significant. So when you know, a user then goes to add the if in the being as liquidity into the next pool, the amount of it they get is actually very different than what was expected. And it actually the delta B in the wrong direction. So, you know, you kind of need to kind of hash out what the actual requirements and whether it makes sense. I mean, you know, very simply, sort of maybe this is a topic for maybe another call or maybe just later in the packet. I said we would discuss that. It seems like it made sense to discuss on another call that really we can bookmark this. Yeah. All right. So back to go ahead. I was just going to say I do feel like the conditions under which or whether it can happen at all the converts under which, you know, being LP token can be converted to a being three corp LP token and vice versa do affect the decision making around what the seeds are, what should be. I would think. Why is that? I mean, I haven't fully thought it through, but I imagine there would be situations where, you know, the price of beans in the two pools are on the same side of the peg and perhaps that extra incentive or extra disincentive by having the you know, the disincentive being converting from the pool with more seeds to fewer seeds would affect the decision making. But I haven't thought about all the different scenarios. What if folks think, should we figure out some of the convert stuff first or does everyone think that's not not super relevant, is only relevant from a like market efficiency perspective, But I think it's pretty much otherwise irrelevant. And one is what is being sort of want to incentivize. The other is how easy this feedstock a lot of those incentives to take hold and how much friction is that between there are different question in this from my perspective that makes sense to me. And one of do any of the folks that had concerns about tether exposure want to want to speak up about, you know, their thoughts on the optimal seeds reward for is in the context of being stocks pre curve exposure. I mean one argument in favor of keeping it simple and keeping it the same would be that, you know in an ideal the gauge system is 6 to 9 months out and at that point stockholders would, you know, not be voting on direct numbers via bip instead be voting in real time on the optimal exposure ratio. So also something to consider for, Hey guy, I'll just chime in here for the sake of the discussion. I guess price point we don't have you know, we don't have data to work with as far as like ETHE holders and their risk, their appetite for risk now that the merge has passed in September and within the next month or two when withdrawals are activated and that goes smoothly, that removes a lot of risk as far as staking is concerned. Right. So if we look at ether staking ether as kind of quote unquote the risk free rate on Ethereum, every protocol not just being stop every defi protocols competing with that quote unquote risk free rate. Right. So we have to be mindful. And I think that is one thing I'm just kind of reflecting on is, you know, see parity between three curve and ETH work before the exploit because the merge was like an overhang still, you know, that risk was removed in September. We still had the withdrawals that, you know, potential risk with that if that doesn't go smoothly. But assuming it does, all that risk is off the table and we're competing with that right in every other defi protocols as well. So that's something for, you know, stockholders to consider. But I also see Berkus Point like, you know, I do I do also see his point that, you know, if you just keep it at equal for both and then, you know, just for the time being, let LPs decide which one they prefer. I guess the free market will kind of push LPs in the direction of the more favored asset. Right. Because if there's more, you know, to Mr. Moti's point about some of the ongoing discussions about Stablecoins centralized stablecoins, if you start if we start seeing more news about that, you know, regulatory hammer coming down on, you know, Turkel or Tether or whoever, you know, I think naturally you're going to see a migration out of three curve and you know, being slack would hopefully benefit from that. So I don't know if there's a right answer here, but that's an interesting point. Unclear how much the risk of ether has changed, But but it has given how all it would take going forward as a simple bip to adjust this feel like to some extent you know it's better be risk averse with this selection and not try anything new until the system is ready. But perhaps there is a need to incentivize ether exposure, but perhaps not well. So those were that I was going to ask other people is if they have any like initial high level thoughts on what the conditions for being able to convert between the LP tokens would be. Would it be like if the but again, why is that relevant to this discussion? I just want to make sure that we're we're talking about the same thing. Yeah. I mean, at a very minimum it will be that the absolute value of Delta B decreases. Okay, that's what I was looking for. Appreciate it. Obviously something you said earlier, I was just going to comment that particularly with the morning auction almost done, it's becoming apparent that the sale incentives are like the the frontier of stock economics and efficiency. And so really, this is probably the first of a couple discussions that should be had on these incentive structures. And there have been a couple of topics that have been discussed today, like a mac stock per BDB, some sort of curve and the change in stock for BDB, what the gains system might look like. So this is this is very much hopefully the first of many such conversations around this stuff and understanding the trade offs between you know what what Bill stock is optimizing around the trade offs between them. That's going to be essential to figuring out how this works in the long run, but in the short term, feel like it's also important not to not to take any unnecessary and it's not to say that changing the seed, not having Tea Party would be a risk, but it would do it. It be an it would be interesting to watch play out, certainly, although all this stuff would be regardless of how the parameters are set. So it's not really a substantive. Ultimately, this type of thing should probably also be put to some sort of straw poll where stock is factored in. So with that said, do we want to move on to the convert Oracle topic of discussion. I'll take the the silence to mean no objections. So in that case, Kouvalis, do you want to set the scene a bit as to what open questions there are to be answered and figure out with regards to what Oracle conversions should be using early on? So you know, kind of currently, you know, when someone converts in the silo, Bienstock stock takes the instantaneous, you know, kind of price of being in relation to three curve. It uses the virtual price of three curve, which you know, is inherently manipulation resistant. But as far as the being three curve ratio goes, it takes the instantaneous value. Now what this means is converts could be sandwiched, they can be front run, etc. in regards to the total of distance that the being is able to move as a result of convert in relation to the peg. So let's walk through a few examples of what that would look like, why it wasn't necessarily a concern when this was first implemented and why it might be some sort of concern now. So, you know, kind of let's take the instance. So, you know, let's say you're converting down to pack. Yeah, there's kind of two ways that someone could manipulate this with a flash flood. They could flash loan, they're being priced higher, which gives you a better execution price on the sell, which is the convert down. In this case, the user would be better off because the out they would receive would actually be higher than expected because the convert is going in their favor. They're now selling into a higher price. And, you know, the person who performs the flash loan realizes the exposure, you know, is the person who realizes the exposure to you getting that higher execution price. Now, let's take the case where someone flash loan decreases the price again on a convert from a you know, a convert from being to being LP where it's acting as a sell. If someone flash loans the price lower, it's going to force the user to get a lower execution price. However, the convert operation has a slippage parameter to allow the user to set their maximum possible slippage. So just as someone could, you know, flash loan or sandwich your swap to allow you to get the minimum amount out, someone could do the same with convert. So from this perspective of as far as I'm concerned, from a user perspective, there's no way that someone could flash loan me to allow me to get a worse execute on price than expected. Now, so far we've only discussed from my perspective as the converter. But now let's talk from the perspective of being stuck, From the perspective of being stock. Someone could potentially perform a flash loan to allow themselves someone else to convert more than should be expected. Let's say the price of being is currently below one. Someone through some sort of fan which could allow themselves to convert more than they might otherwise be allowed to. So the price of being, let's say, is let's say it's exactly that, peg. The price of being is that peg. Now, when the price of being is that peg tell to be equal zero, there's no way to convert. However, someone could buy that being priced higher then convert from being to be three curve and then immediately sell following allowing them to have, you know, successfully execute the convert and increase the absolute value of Delta B, The goal with convert is to decrease the absolute value of delta B and bring me being closer to the pack. And now with this kind of atomic operation, a user been able to change Delta B increase its absolute value by changing it from zero to a negative number through conversion and a sort of, you know, kind of sandwich attack. Now the user is, you know, in a zero fee environment, the user is assuming no risk here from the perspective of, you know, they buy the price higher, they get to be the ones to sell into their own buy and then they get to sell after. So it allows the user to pretty much exchange, you know, outside liquid asset. Maybe that's UCC in exchange for liquidity in the silo in a sense that, you know, they now have traded some of that UCC to receive liquidity deposit in the silo aside from being Now as far as I'm concerned, you know, as far as I'm aware, this has never happened. And, you know, it's unclear whether the incentives are sufficiently aligned such that someone might actually perform some sort of this manipulation. But it is an open question. And ultimately, what leads us to debate the topic of should this Oracle be changed now to quickly discuss what it would look like for this Oracle to be changed instead of using the instantaneous reserves of being or being three curve or, you know, in the case of being, if, as we're discussing in the beneath pool, we can use some instantaneous manipulation resistant value such as the EMR and convert against that. What this means is that no longer you're converting against the instantaneous delta B, which is the delta B right now. You know, you know, when this execution is occurring within a block, not the delta B at the start of the block, not some, you know, historical block trailing average delta B that would be right now. And instead we're going to use some historical trailing average delta B and convert based off that. Now what this has a practice in effect, it's, you know, arguably less efficient than doing instantaneous conversions because now you're converting on some historical average delta B, which means that if you're converting based on some historical average delta B, you may actually end up in a situation where the absolute value of the instantaneous delta B increases. Let's take the instance where, you know, the being price is less than one for, you know, a such a substantial period of time. Right? So the, you know, manipulation resistant price of being is also less than one now. So in buys the price of being above one. We have the price of being above one. But the historical average, you know, the EMI or, you know, the manipulation resistant delta B kind of just call it the EMR delta B for now going forward. But that should be assumed to be a manipulation resistant, you know, short term, you know, historical average of Delta B, So now you end up in a situation where if you're converting around the EMI of Delta B, you may end up in a situation where the instantaneous delta B actually increases in absolute value. And so in relation to the reserves in the pool right now, it being price is actually moving away. Peg. But in relation to this historical manipulation resistance average, you're out, you're actually moving towards the peg. So to some degree it is kind of arbitrary to compare the two, but it should be noted that, you know, the price right now is the actual execution price of B If 5 minutes ago someone bought the price of being above Peg and now users are still able to convert up to peg when the price is above Peg, given that the historical average is not, it introduces some sort of introduce, you know, some interesting scenario for which you know, now the converts you know, aren't directly aligned with the actual delta B in the pool. So I guess the question, the first question and really the only question is, you know, is is the risk vector mentioned earlier significant enough that it warrants actually changing the instantaneous oracle to be, you know, this EMV value. And, you know, I guess the the other problem with it is it actually would be quite tricky, tricky to implement from the perspective of, you know, say you're taking some 15 minute historical average there without some sort of additional tracking mechanism in place. It becomes quite difficult to allow users, you know, to let's say the historical average is plus 1000 delta B, someone converts the peg and, you know, decreasing delta B by a thousand that won't immediately be represented in this historical average delta B So somehow the convert operation would need to take into account the historical average delta B And kind of also factor in, you know, how much has been converted against it. So it really becomes quite a tricky situation. And this is why, you know, the instantaneous reserves are used currently. But you know, it is an open item whether, you know, people think that the ability to kind of buy the price up when the price is below one, convert down and then sell in an atomic operation is a significant enough risk factor. When this operation is done in a non zero fee pool, the operator recognizes some sort of cost, some variable cost in addition to the fixed cost of transaction current transacting. But if the beneath pool is a zero fee pool, then this atomic operation would essentially be free from users. And thus, you know, even though the instantaneous value is being used, there's still a way to increase the absolute value of Delta B through an atomic convert operation, you know, without necessarily realizing any effect. Now, it should be noted that this person could already, you know, like sell, you know, beans into B in three. And I doubt it's liquidity. They can buy some beans with three curve and then you know, one sided bean three curve LP they can add a one sided bean LP. So it's like, you know, they can already decrease the price through adding LP, but this would specifically be through the case and the convert or they're able to maintain exposure to the grown stock they already have instead of taking on new exposure to kind of new accruing grown stock from, from zero. Well, I guess in this situation that you you mentioned, the user still needs to convert into their own. I guess the example you used was usdc that sits outside of the silo, but they would be converting into their their own balance outside of the silo in all cases. Is that, is that correct. Yeah. So it would cost the user usdc to perform this operation, but the user is the one who would be able to receive that Usdc. See now you know, let's, let's maybe to start, you know, getting an idea of what that might actually look like. Let's take the case where first off, you buy into a pool, you take the zero fee beneath pool. If you buy a thousand beans and you sell, you're immediately going to receive a thousand beans. So in the case where someone buys, doesn't convert and then sells, they have, you know, a net zero. It's a net zero operation. Now, in the case where someone buys converts and then sells, they're not necessarily going to sell themselves usdc, see, but instead they're just allowing themselves to sell beans into the pool. And the effect will be, you know, they will lose some usdc as a result of the slippage that occurs within the pool due to that convert. You know, but if you take a world in which liquidity is heavily concentrated about the peg such that, you know, minor deviations in, you know, the balances of liquidity lead to very insignificant deviations in price, you know, the actual cost to the user to execute such an atomic convert operation decreases. So, you know, let's say we're using a fixed price pool, you know, some plus Y equals K pool where it's a being usdc pool and you know, the price is fixed to one in any time you can exchange one ether for one usdc or vice versa. Now, you know, kind of being, you know, being stuck considers the peg in pool to be, you know, with the amount of usdc in the amount of being in the pool are equal. And kind of the difference from that is delta B so the beans, the pool, you know, minus you know the beans plus USDC over two is how it felt to be as calculated. So in this constant price pool, if you buy a thousand beans and then sell a thousand beans, you get a net zero execution price. So in this pool, which is, you know, a highly it's a infinitely concentrated liquidity for in a sense that the price is constant. If you if a user is, you know, converting in and out of this pool, then they're not you know, if a user performs this atomic inverse operation, then they're realizing zero cost because the price slippage is zero. And the reason why I bring this up is to illustrate the point that the cost to the user is not because they're converting into into their buy, it's that the the price that they get on execution for the buy in the sell deviate. So all they're realizing is the slippage which isn't isn't you know, which is in cases where, you know, liquidity is highly concentrated around the peg, you know, very little. And based on some of the assumptions that you were describing and the situation you just outlined, why why don't you think is happening now, this form of manipulation that is. Yeah. So, you know, kind of on that on that point, the reason why hasn't I mean, I guess why I was the happened so far is you know that there doesn't appear to be enough of an incentive to do it, you know, kind of what kind of the the incentive to do it is a combination of, you know, any sort of do a delta risk exposure to having your deposit denominated in a different asset. And again, this is something that could be done to convert from being to be in three curve or convert from three curve to being. So, you know, exposure could be changed in either way. So, you know, I guess the first there are two benefits to doing so. The first is that you're changing the risk portfolio of the asset you're holding. The second is that you're able to, you know, is that, you know, the amount of seeds, you know, per BTV of asset you're holding is different. So according to current convert situation, you know, you'd be able to perform this sort of manipulation to receive more seeds. And if you were to do it from being to be in three curve now, you know, kind of I guess from a cost perspective, you recognize the fixed cost of executing the transaction and you recognize a point 3% fee on all three of the trades, both the buy the convert and the sell. So, you know, looking if we assume they're all about the same amount, meaning being in that peg, you know, you're looking at a point 9% fee or a point, I guess it's a 0.04% swap fee. I don't know. I keep forgetting that. So you're looking at like a point 12% fee to some degree. I guess you would need to, you know, exponentially it it. But the point is that, you know, you are recognizing some variable variable fee on swap. Now, you know, that fee is also quite quite small both fixed fee and the variable fee. So, you know, I would imagine that, you know, for large market participants, it is still a beneficial operation to be performed from a utility perspective. Now, why it's not happening, I guess, is because there's maybe there's no short term exploitable extractable value in a sense that, you know, kind of the only benefit to doing so is really the seeds and potentially to nominating your asset in a different type. There isn't necessarily value that can be extracted as a as a result of this. And therefore, maybe the expectation is that if someone were to perform an attack of this degree that the Dow would, you know, maybe update bienstock or pause bienstock to this issue. But it is important to realize that, you know, within its current state, you know, it is possible and there is kind of to some degree some incentive to do it, you know, Now, given that Bienstock has D pegged significantly in the sense that Delta B is, you know, -1 million, you know, there would need to be a sense, you know, a user would need, you know, a larger, more substantial amount of liquidity and, you know, kind of therefore the cost of the fee would be higher as a result of doing so. So are you saying that you sort of expect the friction associated with performing this sort of convert manipulation to go up in a zero fee environment like wells, You know, think, think marginally? Yes. However, it's very hard to compare and contrast because, you know, kind of the the other side of the cost is, I guess like the the delta, the slippage, the delta price, the change in effect of the price as a result of the convert. You know, given that in a constant product pool, as you know, similar to the plan to deploy the need for, you know, liquidity is not very concentrated, you know, in a constant product pool, the cost to perform the buy converts operation as far as an execution price perspective is going to be higher. So, you know, I guess like I honestly the costs seems like it would be higher in the beneath core, assuming that the user is transacting in sufficiently large size. But you know, kind of you know, the user could always transact in smaller size if they're willing to increase the fixed cost of, you know, the gas or the ether price they have to pay to execute the transaction as instead of doing this, you know, atomic manipulation, once they could do it five or ten times where the price that they pushed the price up to is not as high. But, you know, the amount of operation lines and logic that has to occur on chain is five or ten times higher, you know, based on the cost and gas, I guess also does calculating the the EMEA for the convert rather than using the instantaneous price also increase the gas associated with every convert operation or transaction. I think marginally, you know, kind of the the gas cost, you know, you know, as far from a from a implementation perspective, you know, it's just a matter of it's just a matter of swapping out the function call to fetch the imbalances versus the cost of the gas called the fetch the instantaneous balances fetching the EMR balances require, updating the IMA from the last time it was updated, which you know, probably has a gas cost of at least a couple of thousand. It needs to move it out of log form. So, you know, the EMR Oracle is going to be reading the EMR. Oracle is going to be more expensive. But you know, the you know, the costs, the gas cost to users, to me at least, isn't necessarily priority number one. Priority Number one is security and manipulation resistance. And, you know, kind of the gas cost of manipulation resistance is almost negligible or should be, you know, shouldn't, you know, is only so valuable in relation to the the cost of the ability to manipulate depending on what the manipulation is. You know, for instance, like, you know, the exploit to be in stock last April, it's like if there is a gas cost of $10 more transaction to guarantee that such an exploit can ever occur, probably, you know, well know, would that have been worth it? You know, so to some degree it's like it's almost always worth increasing the gas cost to the end users if it comes at the, you know, to the to the creation of, you know, more manipulation, resistance, you know, I guess like just to mention another alternative, you know, it would be possible to do something like take the minimum off the table and, you know, to some degree it's like if if the instantaneous is greater than the IMA from an absolute value perspective, use the IMA if they're on opposite sides, you don't allow convert and if they're both below, you know, you get the point. You know, that's also an option, you know, if there's not. So I guess, you know, we'll also open that up for questions. It seems like there's still an open discussion to be had and maybe this is also good for the design call in terms of the Bienstock integration of wells on you know, in terms of what that EMR Oracle actually looks like. As you know, if the EMR Oracle as stated before, is like positive A thousand delta B, there needs to be something in place to prevent someone from just, you know, converting 20 times against that plus 1000 delta B within the same block, which is where this Oracle problem becomes quite difficult from the perspective of, you know, it's like if the EMR is some kind of trailing average, but, you know, kind of when you convert, it only affects the instantaneous balances right away. You know, there needs to be something that somehow takes both into effect in order to have proper manipulation, resistance. However, then it's like any time you're evaluating the instantaneous is value, you know, it just should be noted that, you know, someone could, you know, through a sandwich attack basically block the convert from ever happening. You know, however, that already seems to be the case. You know, as you know, kind of you know, someone mentioned earlier on the call pre exploit, it was, you know, kind of there were it was the case that there was like some bots that were, you know, potentially like front running converts in order to make them fail. And, you know, that's already the case where, you know, so getting rid of the it's hard because there's this fine balance where you know, using the DMA now makes it difficult to prevent someone from converting multiple times. But it's like, you know, using the instantaneous price makes it difficult to prevent someone from completely dosing the convert mechanism altogether. If you're using the EMA, could there be a situation in which if there was a lot of demand to convert at the same time, you could over, over convert, or would there be some way to, to stop that from happening? Yeah. So that goes back to the you know, you might be to convert, you know, you could convert theoretically infinite times against an iMac. Right. So assuming no other changes made than swapping out the Oracle, you know, if the EMR is reporting A positive Delta B of 1000, you know, if I convert down to zero and zero and we're still existing within that same block, the EMR doesn't change at all. So if no changes are made to the Oracle, then I could convert infinite times within the same block because, you know, a convert operation doesn't actually take the IMA into account or when if you convert the EMA is an updated you know, the EMR is updated as a function of time passing. So if no time has passed the EMR, Oracle is not going to change and therefore, you know, you can just infinitely convert against it within the same block as no time is passing. And then in the next block you'd be able to infinitely convert against a slightly lower value. So it's very clear the EMR alone is not sufficient to prevent, you know, some sort of manipulation or and there kind of is this fine line where it's like there does not seem to be some optimal ideal scenario yet unless, you know, kind of, you know, either there's some, you know, minimal minimum of the two where both are taken into account, you know, or there's some additional parameter that gets implemented within the EMA to kind of set some sort of rate limit, you know, of how much can be converted as a function of the EMR. You know, ultimately such a mechanism would require, you know, significant or at least non-trivial changes to the code and, you know, an increased gas cost of converting accurately, You know, accordingly. However, you know, gas cost is not the utmost concern. Could you do something like having the EMA or the time period that the EMA looks back be reset upon each convert like if it was going to die? Yeah, I think, you know, I mean, from from the EMA Oracle perspective, the EMA Oracle is part of the well so it cannot be changed. But there could be some additional oracle that is stored within Bienstock. You know, that somehow, you know, maybe says this much was converted this long ago and using some aggregation of that could basically say, you know, kind of that like you know, slowly over time, it allows you to convert against the EMA again, unless it changes substantively. But right. You know, so so like some you know, it seems like if the decision to switch to the EMA is needed, yeah. Then there needs to be like some throttling mechanism on top of it that somehow store how much has been converted or you know, somehow you know, performs some sort of reset as you mentioned that like resets the oracle. So yeah a lot to consider on this front. You could also cap how much could be converted on an hour to hour basis. You know, it could use, you know, another alternative just to use like the sunrise Oracle and you know however you know, kind of the beauty of the instantaneous value is that, you know, users are able to trade directly against Delta B, maybe it like uses the instantaneous delta B, but it uses the it needs to make sure that the EMA is on the same side of the peg as Delta. So you convert against the instantaneous delta. B But if the EMA is not also above peg or below peg, then you can't convert at all. You know, there are really a lot of ways to get creative with this. And, you know, maybe it makes sense to kind of, you know, pause the conversation for now and think on it unless people have more thoughts kind of along this vein. Can you can you shed any light on if you feel like there this would need to be so you know, if we assume that the decision was made, was sorry, let me rewind. If the decision if we assume that the decision was made to implement some sort of EMA for this, do you have any thoughts on like from a technical perspective, are there certain other projects that like where does this fit in the stack of like changes to silo you think, or is it totally separate? Like does it need to happen in any particular order? It does not need to happen in any particular order, I guess, you know, kind of as a part of, you know, whitelisting being if into the silo, there is going to need to be a new custom convert implementation. And now this custom convert implementation could be sufficiently generalized to support any well such that you know, any whitelisted well you know, this convert type would exist for any whitelisted. Well you know so and then you know kind of it could be implemented now would be instantaneous oracle in you know on a subset you know a subsequent update implement the EMR oracle. Um you know however from that perspective it's like the work is being done twice. So there really is a decision to be made here where you know, implementing what is known and what currently exists versus, you know, which is going to be the quickest versus, you know, taking the time to really get it right on the first attempt and, you know, spending some more time to actually iron out what the convert constraint is and then implementing, you know, a more complicated version of convert that is properly, you know, resistant, you know, you know, you know, now from the start, you know, it's obviously going to take slightly more time and developer resources. You know, the cost of such a manipulation right now is incredibly low from t