• Recordings
• Notes
• Soil Issuance Proposal
• Combined Token Support
• Root
• Sunrise Function
• Marketing
• UI
• Operations
• Publius Comments
• Transcript

Recordings

Notes

Soil Issuance Proposal

• Changes the weather in the first five minutes of a given season.
• Currently, the weather is constant throughout the entire season, and changes up or down up to 3% every season. This has proven to be inefficient in terms of how quickly it’s capable of repricing the weather.
• The proposal is to do a dutch auction, where the temperature ramps up over the first 25 blocks, which is around 5 minutes.
• Will use a logarithmic function rather than just a linear function to provide a bigger window for people to sew at their target temperature.

Combined Token Support

• Combined token support is being worked on by Root. It allows for the creation of a fungible deposited Bean, which is important for Root. One of their core theses is that by not having to forfeit the positive carry of the Silo, participants in liquidity will still be attracted to Beanstalk denominated order books.
• Allows you to leverage the Silo’s positive carry outside of the Beanstalk protocol. Currently Beans are not composable within DeFi because you can’t retain the yield bearing function of Beans.

Root

• Added several incredibly talented individuals to the team.
• Very optimistic about the betting markets. Will be very capital efficient and offer competitive prices. Has real advantages over existing solutions, and can drive real organic demand to Beanstalk.

Sunrise Function

• We have noticed some inefficiencies in paying too many Beans when the gas fees are low, so revamping the incentive on the Sunrise function iis something that is likely to come sometime in the future.

Marketing

• We have had five entrants in the community grant program in the month since it went live. Rewards will come out in the next few days. There have also been talks with other contributors who want to make use of the community grants.
• Beanthoven and belabeantok want to do a new podcast for Beanstalk. This will be a limited series. Something like one season. We’ve approved a pilot for that, so we look forward to it.
• Encourage everyone to make use of the community grant, so bring forward any ideas you have and we can discuss them.
• Looking into having another poker tournament.

UI

• Been shipping updates and bug fixes.
• Expect to see the APYs on the site within the next couple days. They will be calculated similar to how they were before, just using a different form of averaging.
• Had another engineer join the front end team.
• Really focused on the DEX and Pod Marketplace V2, both of which are pretty unique design and engineering problems.
• There will be updates to the Silo page to reflect that some assets are going to be Beanstalk Wells.
• We will be updating the market to take into account that there will be an ERC-20 market (Beanstalk Wells) in addition to the Pod Market.
• Thinking about the Beanstalk SDK, which we plan to start in the coming weeks. Focusing a lot on building good tooling around Beanstalk.
• You will use the same interface to deposit to the Beanstalk DEX that you currently use to deposit to the BEAN-3CRV pool.

Operations

• Spending time pushing the bug bounty forward and going back and forth with the Immunefi team.
• Some intricacies to figure out due to the fact that we can only pay out bug bounties in Bean, regardless of the price of Bean. The thinking is to have a future BIP that allows the BCM to mint beans on a case-by-case basis to pay out bug bounties rather than doing some sort of up front mint. This would have to be amended with a future transition back to on-chain governance, but it would work in the near term.
• Streamlining and documenting internal processes such that they can mostly be on autopilot. Things like paying contributors, paying for services, monthly operations reports, etc.

Publius Comments

• EBIP-1 is under audit by Halborn. We are in no rush to get the chop function back online. We want to make sure it is secure and correctly implemented.
• Sync brought to our attention an issue with how the Merge changes Ethereum at the protocol layer in such a way that on-chain oracles might become vulnerable to manipulation through multi-block MEV.
• We will likely add a supply mint cap to minimize the potential impact of such TWAP manipulation. We are confident we can do this and have it audited by the time the Merge happens.
• Once the Liquidity Wells are released, we should collectively try to move the BEAN-3CRV LP over to a Liquidity Well with oracles resistant to this type of attack as soon as possible.

Transcript

maybe we can start this um this meeting with the with the issues page that's on the on GitHub and I wanted to go through a few a few of these suggestions on there in specific maybe two of them and Publius maybe you can help answering some of some of these starting off with the with the soil issuance Improvement can you maybe quickly take us through what is what is this proposal and what will it do so this proposal changes the weather in a given season during the first five minutes um So currently the way it's whether structured in Beanstalk is that the weather is constant throughout the entire season and that weather moves up and down three percent up you know up to three percent every season you know kind of this has proven to be uh you know kind of inefficient in terms of how quickly it's capable of repricing the weather um you know specifically you know uh actually maybe it's better we have green come up and speak about it because he's the one who proposed it um can we get Breen on stage here yes let's do that hello GM sir how are you doing greatly ploty issues right now yeah I'm going to to drop it as well in the tunnel chat all right sir a lot of talk there take us through the the logic behind it yeah so like poop says you know given a season we can only increase and decrease the weather or temperature Sorry by two percent and you know we do this because we want to do you know short-term changes I mean that's a long-term changes for the temperature so that you know we don't rapidly change right but you know there are times when so Supply exceeds the demand or sorry the opposite the demand exceeds the supply right I could real accurately you know hit take that to account so basically what this does is we do a Dutch option where the temperature of the soil that we sown it ramps up over time during the first 25 blocks or so which is around five minutes so if you sew in you know the same block as the Sunrise then you'll get a very minimal amount of soil and then over time it ramps up to up to the right now it's the temperature but we'll change it to the max temperature after 25 blocks all right and now this gives us the ability to more better accurately measure the demand all right so people uh so earlier in the season you know that means people are willing to take less of a return for DC for uh sewing right so we just use a logarithm Library function going from zero to the maximum temperature all right I I dropped um maybe a summary of that and let me know if I'm reading this correctly so at Time Zero the temperature starts at one and then from 0 to 25 blocks which is approximately five minutes it will ramp up to the temperature in a logarithmic function and then it continues at the temperature after after 25 blocks is that correct brain yeah can you maybe tell us why a logarithmic function are not just like a linear function why is the ramp up logarithmic okay so initially we're discussing you know whether we could do a linear function you know or any other you know function would be you know zero for this and the reason why we chose a logarithmic is because uh we like to quickly ramp up or is it Max temperature and then we have a longer period of time in which you know you have you know greater a period of time in which you can sew between like toward the upper bound right so for example if you wanted to sew let's say 75 of the Max uh weather or temperature sorry uh in a linear implementation you only have you know one block or so to do that right and because blocks are in 50 seconds or chops like increments you know there's a big jump between you know each block with a logarithm function you know you have a bigger time window in which you can sew and still get you know within the range of what you really want so does that kind of make sense makes sense to me and then lastly the last thing to note here is that right now the way that the model measures if demand is increasing or not is that it looks at the first five minutes and it sees of the if soil uh sold out or not this is going to change now just given that the the auction is going to happen in the first five minutes so it's going to look at the um the 10 minutes or from 5 to 10 minutes yes all right thank you for being for summarizing this and anyone if you have questions about that feel free to drop them awesome all right probably the second one I wanted to discuss is which I think got posted a few hours ago that's the combined token support can you maybe also summarize to us what is the the thinking behind this and and why do we need something like that so the combined token support is being implemented uh you know is being worked on by root um don't know if uh manifold wants to talk at all about it uh manifold do you want to talk about kind of bit24 sure yeah happy to speak at a high level and modest you know when I go into any more technical details I'm also happy to have a root Dev on on this call for next week um but you know the combined token support you know effectively you know allows uh us to you know begin you know thinking about the creation of a fungible deposited Dean um which uh for root is is pretty important um and the reason being you know one of our core thesis here is that um by not having to Forfeit the positive carry of The Silo uh participants in liquidity uh will still be attracted uh to being stock denominated uh order books um and specific for you know the root batting exchange um and so you know by having a fungible deposited uh Bean which which you know combined token support effectively allows you know rolling uh deposits into the current season this effectively allows us to Leverage The silos positive carry outside of the beadstock protocol which currently you know we you you can't export beans or beans aren't composable uh within defy when um you know you also want to have the yield bearing function of beans and privilege I'm not sure if uh models are going any more of the technical details or if you want to see that for next week um probably best to let our lead Dev discuss that I think I think this was clear um and just to make sure uh uh when they said this correctly so motor that's what's happening here is that you're allowing someone else to be able to transfer the deposits instead of uh the owner or just the owner correct yeah exactly that's my understanding you know the the the it can be formed by by anyone all right thank you manifold what we have here can you maybe also just give us a Topline update on Route and what's what's happening with root totally um so you know uh first things first uh root has uh been in the fortunate position to add several incredibly talented individuals to our team uh you know I see I see Icarus here uh in the audience um who's one of those individuals and we're incredibly excited to to have him on board um you know it it shows you know and I think Publius refers to it as the Beanstalk Brain Trust but it continues to grow and um you know I think that that's really a a you know uh a leading indicator of a lot of exciting uh you know developments that are going to be happening in the ecosystem um and specific to root you know we uh are at a place where the D1 design has been iterated multiple times um and and we're excited um as we believe there's there's numerous advantages on just the V1 on the betting exchange versus you know traditional you know web 2 apps where you know people can play stats or Vegas um you know there's the design clearly has you know uh increased Capital efficiency um you know we believe it's going to have much cheaper spreads in Vegas um and you know cheaper prices in my opinion is a big deal um you know there's increased liquidity on positions versus you know current current options for for people to make bets on um and you know all these things again I think are bowed really well and we're we're quite excited um you know as we start to build this B1 uh I from from my vantage point personally you know obviously all of us you know believe in the thesis of Beanstalk um and and again having a positive carry order book which which enables you know liquidity to stay parked and make markets on top of the order book but also I think it's really important to you know as a standalone product to be able to to have real edges versus current Solutions being denominated value or not and and I think Roots betting exchange is and its order book is getting to you know a place where you know I personally feel that you know it's going to be really really competitive um and and drive organic uh demand to bean stock so uh yeah that's pretty that's kind of like the high level overview right now thank you manifold and we have a question from from Chad uh and I believe that's regarding uh the soil issuance Improvement and he asks how would that impact uh demand for calling the sunrise publish any comments there um you know think they're completely unrelated in the fact that you know the sunrise reward as of now is going to stay the same you know there's still going to be a base 100 beans that increases slowly to about 2 000 over five minutes however you know we have you know we have noticed some kind of inefficiencies in potentially paying you know too many beans when gas fees are low um so you know kind of revamping the uh incentive on the sunrise function is something that you know is likely to come sometime in the future great all right let's look around um across the contributors and maybe I can start with some marketing updates so we've had the community grant program now for close to a month and there are five entrants uh so far uh which which the rewards they say or the awards will come out in the next few days there have been also some talks with other contributors who wanted to make use uh of the of the community ground uh one of them is ASP so asphy is looking to make some sort of a course uh uh for being stock that'll be called the green Scholars uh program and the idea is for it to run for like 12 weeks uh it'll be like an independent one so being so Farms won't be like producing this uh so it would be like a separate let's say independent being stock uh course and we look forward to that and there will be more information coming out uh hopefully philanthropy soon otherwise uh the audio team and that's the belladin token Beethoven they want to give a try to a new uh podcast uh for being stock and the idea of that podcast is going to be some sort of a limited series so it's going to be like one season uh We've approved a pilot program for that so we'll also look forward to that otherwise anyone else who encourage you as well to make use of the community ground so any ideas that you have anything of that sort come over then and let's let's discuss it besides that we've had small things to mention and that the climate Infinity thing that that they they announced and then defilemma as well fixed uh um the bean stock let's say uh numbers on uh and I've also had a chat with Chad Kitty who was the the winner of the poker tournament or the last poker tournament that we have we had uh I'm hopefully we're looking to maybe have another one sometime next month okay um sign the chat maybe we can move to you and give us some UI updates certainly yeah uh thanks mod so a lot of stuff going on this week um we've shipped a couple small updates uh fixing some bugs and and shipping some other styling updates that you'll see in the the updates Channel most notably right now the thing that we're working on uh in the short term is shipping the apis uh more or less everything is ready to go here and so expect to see that on the site uh if not later today than in the the next couple of days and if you're if you're curious about how those apis are going to get calculated it's similar to how we calculated them previously but this time using a different form of averaging so I'm going to drop a link to the documentation about this which will go uh go public along with that that launch in the next couple of days so stay tuned on that front um beyond that so a couple other important things we've actually had another engineer join the the front end team uh Bean Sama will have been Sama come join us up here next week to talk a bit about what they're working as well but uh they're gonna hop in and help help us tackle basically all the the front end stuff that's coming up over the next couple months of which there there's a lot right now on the front end side so besides some of these smaller tweaks that we've described really focused on the decks and pod Marketplace V2 uh both of which are pretty pretty unique uh design and Engineering problems in their own right so on the Dex front there's a couple things going on in parallel uh red beans is working on a lot of new designs and sort of tweaks to that which you can speak more to on the engineering front so we'll be making some updates to The Silo page for each asset to reflect that some assets are now going to also be uh some white listed assets will be basically Beanstalk Wells so we'll we'll keep uh keep you posted on that and then also working on uh updating the market to take into account the fact that now we're going to have more than just the Pod Market it will also be you know uh erc20 token Market if you will which is uh Beanstalk Wells as well as other markets so a lot of work going on on that front and yeah beyond that just continuing to grow the team Forward Thinking uh on my mind in particular are things like the SDK which uh we plan to to get started on in the the coming weeks to to months about it basically focused on building good tooling around Beanstalk uh um we've been you know obviously with with root and a lot of other projects are starting to start building on Beanstalk we want to try to open up some of the tooling that we've used on the UI to other developers to to help them you know use beans and their applications so a lot of work to be done there but something to kind of look forward to thank you champ um with regards to the to the market and the amm do you have an idea on how will that be on the UI will everything fall under the same tab would it have like a separate front end what are the thoughts there yeah great question so for right now the plan is to have everything accessible through the Beanstalk UI um there's kind of a couple fronts in which you'll be interacting with with the Beanstalk decks so the first is that when a well is created in in the Beanstalk uh in the Beanstalk decks and the corresponding token is whitelisted which is what we'll expect for you know being Ethan other pools that we'll be launching on the decks early on uh you would deposit to that pool using more or less the exact same interface that you use right now to deposit to the beam uh three curve pool so that part will stay more or less the same the the new piece of UI that you'll find is under the market there will now be a section that focuses exclusively on uh Beanstalk Wells and so you'll be able to view all of the available Wells see metrics about those Wells um at various you know similar in some ways to maybe what you'd see on like the the unit swap or curve analytics websites but that'll be built straight into the UI so yeah one basically One Stop Shop understood um and pizza man had a question on the API calculations and he found the answer in the API document so if anyone has you know questions on on how is is the variable API calculated you can find find the find the detailed in the in the link that chart shared all right sweet red beans yeah uh I'll be quick because Chad kind of touched on on some of my points but my time this week has mostly been going into the decks uh you know kind of getting close to being done with the first run through but uh kind of collecting feedback from from some other core team now and we'll we'll kind of be uh iterating on that feedback to kind of improve it and get it ready so uh yeah not a super long update for me this week but has been a bunch of time on the decks thank you sweetheart Austin uh on your end and I guess one of the things that now we'll want to do is have you write some you know good good documentation on changing the word dex1 amm yeah definitely um let's see uh on the operations front I've been spending some time nudging the bug Bounty program for it been going back uh with the immunify team uh quite a bit uh there's some intricacies to figure out uh particularly given that in practice we can only pay out bug Bounties in beans whether the price of being is a dollar ten or 50 cents so working out some of the details there the the current thinking is to have uh a future bip that essentially allows the BCM to mint beans on a case-by-case basis to pay out these bug bounties rather than doing uh some sort of upfront uh you know being meant obviously that would have to be amended with a future transition back to on-chain governance when the time comes but uh I think that might make sense that structure makes sense uh you know in in the near term and uh otherwise just been spending some time uh streamlining and documenting a bunch of internal Beanstalk Farms processes such that they can mostly be on autopilot whether that's you know processing reimbursements from contributors paying for software publishing those monthly operations reports and uh you know along a long tail of other things thank you Austin uh and just summarize that the idea is for the bip to give authority to the BCM to be able to Mint uh basically the the Bounty for any bugs that's correct correct yeah up to some total where after that total you know perhaps another dip would be required at some point in the future um maybe to just give like kind of a tldr on the on the structure there's there's a handful of different tiers for all of the uh I guess severity of each bug report uh call it like medium high and critical and the thinking is that for for critical bugs you know that result in uh loss of user funds things like that the max Bounty would be something like 1.1 million beans uh of course you know the idea is that uh even if that Bounty Hunter uh does end up selling you know Beanstalk is is much better off having that uh reported and fixed than than found by by a black hat hacker of sorts so you know if the max Bounty is 1.1 million perhaps it makes sense to uh propose for the you know BCM to be able to Mint uh mint beans up to you know I don't know a couple million we'll have to do some more more thinking on that front and happy to answer any any questions and and open to feedback on that front understood Chad is giving an update on tbacker you're in the audience if you want to come up and share it feel free to do so otherwise I can read the update and that TBC is working on a new data playground which will replace the old Dune dashboard and we do not have a date for that all right Publius any closing comments um yeah I have a couple things to mention here um you know first off uh you know kind of on ebib one uh you know that is under audit by have one right now you know we are not rushing to get the job function back online the goal is to make sure that it's you know as as secure and you know correctly implemented as possible before adding it back um you know secondly uh you know sync brought to our attention something very specific about you know kind of how the merge changes um you know kind of ethereum at the protocol layer um you know which which can have a large effect on on-chain oracles um in you know kind of in summary the changes you know with the merge um you know kind of upcoming you know block proposals proposers are now predetermined in some sense um whereas before you know kind of whatever minor happened to you know mind the correct um you know hash first is the one that got to propose the block um you know kind of post merge we now have a Cycling group of validators such that you can kind of see which validators are going to be able to propose future blocks now this creates the potential potential problem where if a single node operator running multiple validators ends up having two validators proposing a block back to back then they essentially have control over what transactions go or you know end up going and don't end up going in that block and what this can lead to is multi-block Mev and um you know uh this ha you know this can have great consequences on on-chain oracles namely t-wop oracles and this EMA Oracle we have been working on um and you know kind of there's you know instant implication implications in regards to you know how minting happens within Beanstalk um you know and you know so essentially it you know what this uh you know kind of uh the merge does is allow someone to effectively uh manipulate the t-wop Oracle on the beam three curve pool uh to Mint however many beans they want um now we you know have had our heads down kind of thinking about potential solutions that we can Implement that require minimal changes to the code to prevent you know such an attack and I guess to talk about the magnitude of such an attack you know someone executing this attack would you know not get the beans that are minted the beans would still be distributed uh you know 33 33 33 um but someone could still manipulate the t-wop Oracle to Mint uh you know a large amount of beans by essentially you know buying the price up you know incredibly high and you know letting that sit for one block um and you know even though there are either about 300 blocks in an hour if you push the price up to you know a thousand dollars for one block in you know that's still quite significant uh when you even averaged over 300 blocks um so you know kind of the solution that we are you know kind of come to uh that we you know will will likely look to and see if it makes sense to implement in an ebip is adding some sort of Supply uh mint cap um now this mint cap would likely be something like 0.1 to one percent of total Supply um you know pending some calculations on the potential cost and fees to uh you know uh you know conduct this t-wop Oracle manipulation um but kind of why we feel like a you know mint cap is a good way to uh you know prevent this problem is that you know number one it you know minimizes drastically the potential impact of such a t-wop manipulation and two it's incredibly easy to implement from a code perspective we feel confident that you know we'd be able to basically implement the solution and get it audited and implement it through an emergency bib if the community feels like that is the correct path to go down by the time the merge occurs um which you know even though this this attack is not one such that an actor can financially benefit from and it requires uh you know and it relies on kind of Randomness to allow someone to have multiple validators positioned uh you know sequentially in the proposition order um you know we still feel like it makes sense to kind of combat this problem now um what this means for you know future oracles you know we've been putting our heads together and come up with a few ways that we can actually kind of present you know prevent this sort of attack on T WAP oracles and EMA or any kind of on-chain Oracle by kind of you know putting some limit on the amount that a balance is able to change uh each block um and you know we don't quite have the detail is written down and what you know are happy to share once we do um but you know feel confident that we are still going to be able to move forward with using on-chain oracles and liquidity Wells um but it's likely just going to require a bit more development work and uh you know thought to really make sure that we combat against this attack um you know going forward in regards to the bean freaker of pool um we should look to move off the pool as quickly as possible as the you know potential attack on the t-wop is you know gonna be present for you know as long as we use the pool given that we cannot upgrade the bean 3 curve pool at the uh you know at the pool layer um to change the t-wop mechanism to make it resistant to such attacks and thus you know once the liquidity Wells are released um you know we should collectively try to move the bean 3 curve LP over to a liquidity well with uh you know oracles resistance this type of attack as soon as possible um you know curious if anyone has any thoughts questions concerns on this uh you know but that's it on our end uh Publius I don't know if you have anything you want to add to this well first off shout out to sync for as always having his head in the sand uh in in the in the sense of uh Beanstalk is dirt oriented so always uh in the weeds and knowing exactly uh where to where his his attention should be this is quite defined uh and another reminder that this is remains Uncharted Territory and there's lots of uh sharks in the water that we constantly collectively need to be looking out for uh in terms of short-term risk it's it's beamstock isn't of the size where it would likely make sense for this to be an attack in the early days post merge but nonetheless the attack the potential for the attack exists and therefore it probably does make sense to do this as an emergency bip via the BCM as opposed to a a formal normal bip uh but that's something that we'll probably ask halborn about for their opinion as to the the associated risk here as well before a final decision on that front and uh it the goal is always to have the Dow be the the body that is implementing changes to any rules within the Beanstalk contract but in this case there does seem to be some potential risk to the Integrity of the model and therefore uh perhaps it does make sense to implement it as an emergency bip uh otherwise uh as Publius was saying the implementation of the wells uh from our perspective it was bound to happen anyways given the nature of uh constructing a beanstalk specific uh Oracle that that's something that we've been talking about for a while uh in order to get the Delta B calculations right but this is just uh as Publius was saying another layer of complexity so uh probably pushes the timeline back for the being eat well which will hopefully be the first well uh a little bit further back but uh generally the goal is to get things right and not to to rush them so from our perspective this is progress in the right direction and feel pretty good about the the future of on-chain oracles which many people are just switching to chain link uh we are gonna we're gonna fight the good fight to to avoid that as as much as humanly possible thank you there was another question um uh on the governance Channel where someone suggested if there are any thoughts on or if there are any considerations uh for doing a lot for the BCM to pause being stuck ahead of the merge just to you know be careful let's say that that would seem to be an abuse of power uh as there doesn't see assuming that the Oracle is fixed there don't seem to be any known risks but perhaps it's better to be prudent uh generally don't think that's the right that's in line with the ethos of Beanstalk which is not necessarily uh you know the most risk-averse when it comes to things like this it's very much a a risky risky Endeavor as we were talking about earlier with regards to the discovery of this Oracle issue so not sure the benefits of a of pausing the protocol other than there there will be a delay in the discovery of how being stock functions post merge so the hope is that the protocol will is and will be secure post merge and that's therefore there's probably no reason to pause it and I guess we'll just add in here that you know if for some reason the community feels differently about this um you know uh you know a community-led discussion you know we welcome that and ultimately if someone did want to go forward with proposing some sort of snapshot vote uh as like a uh you know a measure of you know kind of how the community feels about potentially pausing you know I know numerous other protocols such as Ave are pausing around the merge um and you know recommend everyone individually does you know kind of do their own research to see what the potential uh you know issues could be and how those would affect Beanstalk but generally share the same opinion with Publius um that you know it's it's something that is you know kind of an extra you know an extra safety precaution and it's hard to see how necessarily Beanstalk uh you know would would have some sort of issue in the process okay um one part just see your hand is raised so I can bring it up to Stage if you have a question I've invited you okay I'll give you a few more seconds otherwise you can always drop your question and Town Hall chat as well James asks will there be a fail safe to the on-chan Oracle as things are getting developed on the initial stages so maybe use chain link as a backup validator so you know kind of the the thing here is you know kind of what Beanstalk seeks to you know kind of determine over season is the average beans above Peg um you know kind of from from the research we've conducted into chain link it seems that you know chain link really is only able to in their base default Oracle provide a bean USD price now you know that gets us part of the way but Delta B is not just a function of price it is a function of liquidity so it's really hard to see how without some kind of you know long custom you know kind of uh you know solution to creating uh you know some new custom chain link Oracle which again it doesn't seem like they're in the business of building it seems very hard to see you know to kind of come up with a way for how we can you know move this Delta B Oracle off chain without kind of uh you know kind of totally changing the formula altogether um for that reason you know we feel confident sticking with on-chain oracles um you know but again like if if this is something the community is interested in and someone wants to start working with some off-chain Oracle provider it is something we can look into um you know you know other fail-safes you know that that can be used can be ones that kind of you know compare the the relative change in values um you know was looking into liquid use Oracle and saw that basically you know of bigquery chain link and you know if the chain link Oracle changes by a significant percentage um you know based on the last value it read then they look to teller and they compare that the two values are about the same if they're not about the same you know they fall back and compare the teller Oracle to kind of the last price um so you know overall think you know a lot of thought can go into determining what oracles we should use and how we should Implement on-chain fail-safes um but don't think we necessarily need to rely on off-chain oracles to kind of have these fail safes instead we can build these fail safes into the liquidity Wells that we're already building and thus you know still have you know a a resilient on-chain you know ethereum native Oracle um that has built-in fail safes um and think you know everyone in the community should you know spend some time really thinking about uh you know what they feel like could potentially go wrong with an or Oracle and how they would build in you know kind of on-chain fill safes thank you for that answer uh Publius okay I think we are at the end of the meeting and there are no more questions so thank you everyone for joining and if you have any other questions feel free to drop them you know anytime reach out to anyone drop them on the questions Channel otherwise we'll see you next week