Recordings

Meeting Notes

• Bean Sprout updates
• BSP-8 has passed and has sent the 20,000 Beans to Halborn.
• Root token is in audit.
• More developments for the Bean card.
• Operations Updates
• It is important to enable permissionless contributions
• Contract level, frontend, Gitbook, BeaNFT, and the whitepaper
• Going to share a Notion page with what the operations team has been working on.
• Bug bounty program is live. https://immunefi.com/bounty/beanstalk/
• Marketing Updates
• Pitching to journalists about the AMM
• The audio team has started recording educational videos about Beanstalk
• CanadiaBennett has been working on the clips, few samples have been made
• Beanstalk article should be live on https://stablecoins.wtf/ very soon
• Two new entries have been made for the community grant
• UI Updates
• Pod Marketplace V2 is being audited on the contract side, working hard on the frontend side
• The engineering team has been hard at work with the Beanstalk SDK
• Design Updates
• Finished preset Farm functions for the UI
• Making adjustments to the Pod Marketplace V2
• Thinking about making a design kit for permissionless design work
• Publius Updates
• Submitted the function call architecture code for audit on Monday https://github.com/BeanstalkFarms/Beanstalk/pull/103
• Can perform any action within any protocol through this function
• Technical spec for the Wells is done, just working on the code
• Want to write the code so the DAO does not have to upgrade it in the short term
• Sunrise improvements are currently being worked on
• The motivation behind the focus on the function call architecture
• Before there is the Farm function
• Allows Farmers to call a list of functions in order in a single transaction
• Upon launch of Beanstalk V2, the Farm function was used to call functions in the Curve protocol
• There were some issues with the slippage of the trades
• EBIP-1 was a bug within this
• Dynamic call functions will open a lot of doors with what we can do with Beanstalk
• The current way to implement a Pipeline does not scale well (requires governance)
• Farmers who want to use their Beanstalk balances without leaving Beanstalk can now do this with the function call architecture
• From a security function, Pipeline is a separate contract from Beanstalk so it secures your Beanstalk balances
• We can support any other protocol that Farmers want to use through the UI with the Pipeline improvement
• Root has been working on a Beanstalk Seaport fork, and the Pipeline will enable this
• Moving towards pushing code in a way Beanstalk does not need to be upgraded very often
• The goal is that one-day Beanstalk could get rid of governance altogether. Unsure if this is possible, but we should be working towards this
• The end goal is that everything that can happen Beanstalk can be done permissionlessly, and there is no need for whitelists
• Publius’ thoughts on the recent exploits
• Even if Beanstalk is secure, if there is a protocol built on top of Beanstalk and attracts a lot of Bean assets then that protocol is hacked it could directly affect Beanstalk
• Everyone who is still involved in Beanstalk is brave, because of the unknowns and there are new attack vectors being found
• From a high level, these hacks are a reminder that it is not possible to spend too much on security from the DAO’s standpoint
• It is very unfortunate that people are losing their money due to lack of security
• Deploying the Wells is not the issue, but the issue is how to securely implement the oracle
• The less code changes the more secure Beanstalk, to do this we need Beanstalk to be more generalized
• Security is the challenge that we are all addressing right now
• Trail of Bits has been prepared from another audit
• Sunrise efficiency improvements
• Reduce the number of Beans awarded to the sunrise caller based on current Ethereum Gas prices
• An overview of the improvement can be found here https://beanstalk-farms.notion.site/RFC-Sunrise-Payout-Change-31a0ca8dd2cb4c3f9fe71ae5599e9102
• The target profit has yet to be determined, but it should always be profitable assuming that the call is not successful
• The sunrise() call should never be delayed because it will always be profitable

Transcript

all right thank you all for joining us on today's Dell meeting as a reminder this down meeting is for everyone uh you the Dao members so as I said earlier at any time if you would like to say anything or you know comment at anything just unmute yourself and and this is an open conversation um okay we typically start uh usually with an update from Bean spot Mr manifold how are you doing and and can you give us some updates or take us through what's what's up with beansfield uh I thought I saw Mr manifold here well it looks like maybe I was mistaken or maybe he joined and left all right we can we can start with Beanstalk farms and if he comes back we can go back to to be to be in sprout how's it going Austin hey mod thanks um yeah happy to give a quick update um I see I see manifold as a back maybe we can go with with bean sprout okay sorry my services can you hear me mod we can hear you okay awesome um so bean sprout updates vs bsp-8 looks like it passed um so we we sent halborn the 20 000 Feats for North Stream So that looks like it's uh gonna be kicked off today which is great um you know we've made significant progress with um you know a partner that you know we'll probably be announcing in you know the next few weeks months um regarding uh and a new type of that were and we're pretty excited about and that you know we'll be denominated in Roots speaking of root the root token is also an audit which is great and it looks like you know a lot of these things will be ready um for you know uh hopefully by by mid next month um so we're pushing product here uh making a lot of progress which is great um there's been a handful of Builders developers uh entrepreneurs that I've spoken with in the last week and a half um specifically uh shout out to Mr Mochi who introduced me to uh three individuals in uh that are that are also working on a crypto card solution and they seem pretty Keen about doing um something in specific for beans which is great so you know that's a third or fourth uh debit card and on-ramp partner that we've spoken to in the last month or so that's looking to do something relating to being stock um which is which is fantastic um aside from that you know several several developers uh that I've been in touch with just trying to figure out where they can contribute to the ecosystem uh you know there's this Beanstalk for business uh not sometimes currently being incubated that I've discussing previous calls that could be a nice spot to land um you know they might want to contribute Grant space like Farm since any bandwidth so just try to allocate resources and interest efficiently and effectively um but aside from as always you know if there's any specific questions uh or comments please feel free to DM me or message me I'm sorry you're just going to keep this brief because I'm in a rather noise thank you manifold uh and if I was to summarize I guess the main two key points is that there is a third party the truth is working with and and this is what DSP 8 was about and currently being audited by halborn and then the other bit is as well uh the root token which is also being audited there and then you've mentioned a few opportunities about the debit card uh or off-ramp basically uh for beans and then other other developers or anyone who wants to build anything uh on top of Beanstalk reach out to Mr manifold thanks for the summary thank you manifold all right um and again to those who just joined us this is an open conversation um feel free to unmute yourself give a comment ask a question anything of that sort so there is there is no like you know a certain way for you to do it you don't have to chat just unmute yourself and and go ahead with it all right we go back to be in stock Farms Austin thanks Matt so I think the one of the main things I want to give a an update on today is we had this great conversation between uh Publius and the rest of the BFC yesterday talking about various priorities and was doing some reflecting and I think it's I think we all think it's pretty important for across the stack to enable you know permissionless contributions excuse me permissionless contributions and that's a little bit more obvious today at the contract level but you know in terms of the front end uh contributing to the get book and documentation the white paper things like that uh it's all fairly siled within Beanstalk farms at the moment which is certainly not not the end desirable state so and again that's all the way from the get book to to things like you know even being FTS like if you think about if someone comes up to the Dow and is really excited to start a new bnft collection how do they even go about doing that you know there's no bnfc Dao to propose to there's no process for asking now for approval things like that so gonna be spending some more of my time over the next few weeks figuring out processes for a lot of that work and sort of as a as a meta comment um you know the ratio of things to be done and people that there are to do them is uh is increasing so one of the things I want to do over the next week or so is uh publicize the internal like project board that the operation teams has been working on and you know properly spec out various projects and share them with the with the community because there's a there's a lot to be done so that's uh that's it for my end and you know in other news the bug Bounty program went live a couple days ago which is great so you know if you know any white hat hackers these uh please forward that they're away thank you Austin and this is a quote again uh to anyone uh who's in touch with any developers uh or anyone basically can contribute to being stuck uh or being so congenital or been so far as well reach out reach out to us or reach out to anyone in the team okay I can give a bit of a marketing update um so where we at right now is we're continuing to pitch to different journalists about being so congenital or about uh the the zero fee a m um the audio team started recording the first educational uh video so we hope to get that out sometime um Kennedy Bennett has been working on uh on the clips so we have a few things someone is talking let me just mute them right Canada has started working on the clips so we have a few samples but we're still editing that and hope to have that out uh sometime soon as well um stablecoin WTF uh Silo chat had introduced us to them uh they've worked on it uh we we will probably be out there or live on their website soon we're editing a few of their of that article uh from their end and then and then hope to have that as well out there lastly we'll have two new entries uh through the community ground which were you know blog posts and Then followed up with with Twitter threads that's it from marketing start a chat you want to give us some UI updates certainly thanks mod so Focus currently is on two things the first is POD Market V2 which is in very late stages of auditing on the contract side we're working on the UI side to get this ready as quickly as we can and the second thing is the Beanstalk SDK which is something that Alex uh has been working on the last couple of weeks and our goal with that right now is to ship a very early version that moves some of the capacities of the the current UI out so that other teams can use them uh to build on Beanstalk in the very near term notably some of the teams that manifold was was describing earlier so trying to get the the right pieces in place uh for for people to really start uh really start adding stuff on top of Beanstalk so we've got got a lot of progress already already completed there and hoping to have sort of like a version version one of that push sometime next week okay and my understanding is the uh veto the Pod Marketplace is currently being audited uh by halborn yeah that's correct so we should expect to go live sometime soon you think uh perhaps Publius and Maltese you can speak to the the timing of of the bip there but um that's the idea yeah it's in in late stages on the audit side quite exciting just got back to us today with the rough draft of the report um you know doesn't seem like there's too many major issues or issues at all um you know so gonna take a few days to make the edits here and then you know whenever the Dow collectively feels like it's appropriate we'll be ready to proceed with proposing on chain okay that's pretty exciting and maltesia see you in the audience so if you'd like or if you want to comment about anything please feel free to do so sweet red beans hey thanks mod um so yeah over the last week finished the claim and deposit rinse and deposit Harvest and deposit UI uh so hopefully we'll expect that to to come out soon uh I would say you know over the next few days making some adjustments to the Pod Marketplace uh you know making some adjustments to the layout and the components as well to kind of match this new functionality so excited for that um and then kind of you know as like like Austin mentioned thinking about uh sort of setting up an extensible design system you know branding kit uh just sort of preparing for this like permissionless approach to contributing with design so uh you know kind of on that front you know if you're if you're on this call or you know somebody who is interested in kind of helping out with design it be in stock uh you know please let me know feel free to DM me uh you know that includes kind of product design and and graphic design so uh looking for help but yeah that's that's it for me thank you sweetheart and an emphasis on on the design as well um if anyone again developer uh someone can make videos uh design work uh introduce us uh to those uh to those stands do you wanna do you wanna give us some updates from your end or what's what's going you know through your mind totally you know on this end you know we you know submitted the the function call architecture V2 code um you know for audit on Monday uh if you want to read through kind of you know kind of the description and documentation revolving around this update we posted it in Barnyard chat um it's gone through several you know minor iterations over you know over the course of the week so um you know hopefully you know we've been trying to clean it up and make it clear um you know so if anyone has any comments questions or suggestions just for uh you know this documentation or you know uh would also appreciate any sort of code reviews if anyone listening on the call is particularly Keen in that um you know shout out Moon here's some code going out in this uh you know in this bib um but you know overall super excited about kind of the release of this function called architecture V2 um you know this was a dream that kind of started you know with the original form that was implemented we've been stock too and you know really uh excited to take it to the next level and uh be able to expand the capacities that we have in terms of just what we can do in one D5 transaction um you know really think that you know with this upgrade we'll get to the point where we can you know theoretically within one transaction through Beanstalk perform any action that's a part of any protocol um you know which we're extremely excited about um you know as far as our attention goes now that you know kind of this this uh you know kind of uh bip you know took away some attention from Wells um but you know now kind of the plan as of now is to shift back over to Wells and you know start putting a lot of attention there um as far as kind of the technical spec goes of Wells it's pretty much done it's just a matter of implementing it um you know just to reiterate like where what we're trying to go for is you know kind of we want code that we release going forward could be code that is built without you know without the intention to upgrade it um anytime in the near term um when we release Wells we want to release it such that in a way you know that you know people can permission permissionlessly you know create their own oracles create their own pricing curves um and use any tokens of you know any amount of tokens and really try to make these things as modular as possible such that you know until we move on to Wells V2 um you know which is planned in the pipeline uh we shouldn't have to upgrade the base Wells uh you know functionality at all at the protocol level which should be quite exciting um and should definitely give us a lot of room to experiment with um you know so super excited about that you know been uh you know chai Kitty's been doing some great work um working on you know the decrease to the the sunrise function reward um you know hopefully we'll have something that we we can share soon on that front um you know other than that things are chugging on the back end side you know Moon's been working on some uh you know uh generalized approval system for function called the Beanstalk which will you know start to help kick-start uh automation um you know so across the board super excited about everything um you know that's it on this end thank you for listen and that's a lot to digest okay um let's give it let's give it a few minutes and see if any anyone here um with us would like to discuss something that hasn't been discussed um what and and this doesn't have to do with Beanstalk Farms again or being Sprout it could be you know anything that's Community related or for the protocol in general we've got one thing to kick us off here um I think pubs it would be great if you could you could talk a little bit about the motivation for spending some time on on this uh function called architecture design Now versus in you know say sometime after Wells I know we've talked a little bit about this but I thought it might be good for others to hear yeah sure happy to talk a little bit about that um so I guess kind of to talk about what we could do within Beanstalk and what we couldn't do within Beanstalk or I guess what we can do in Beanstalk now with the you know generic function call architecture we have and what we can do with this new function called architecture so kind of before you know we introduced this Farm function which basically allowed users to call a list of functions within beanstock in order and you know kind of with the release of you know being stock 2 we introduced The Curve pipeline and the idea was to have these pipelines that wrap functionality and other protocols that users can now call through the farm function um so given that the farm function can call a list of functions within Beanstalk and now Beanstalk has its own wrapper functions around curve Beanstalk users can use curve in the farm function um but within the farm function specifically there were two real problems one problem was how we were handling the case in which slippage uh you know on some sort of swap on you know a prior transaction or prior function call within the farm function you know was essentially handled um and that was through the use of this internal balance mode uh you know called internal tolerance that basically allowed you know allowed the transaction to continue if there was slippage on a trade um and you know there are some potential security risks you know as we mentioned here um ultimately ebip one uh which was the the issue with the chop function was you know directly uh you know caused by the existence of this internal tolerant balance mode so you know one thing we want to be able to do is have Dynamic call data Within These function calls um in Dynamic fun call data will allow us to do things like retake a return value on a function call and use that as an input into the subsequent function call in a farm function um so we can or we can say you know to transfer all my balance you know you just perform two function calls one what's my balance of this token and then you can transfer all of your balance by taking the return value and plugging it in um so you know kind of upon ebip1 we felt it was a priority to try to find a way to remove this internal tolerant balance mode which you know we don't want to cause any more issues going forward which you know it it has in the past um and then secondly it became clear that there was a high demand for other protocols to be able to integrate uh you know you you know to to be able to be used through the farm function within Beanstalk with internal balances you know on top of the root token which is in audit um so you know any protocol whether it be uh so you know kind of currently with the existence of pipelines as we've discussed with the Curve pipeline in order to build a new pipeline we have to have a developer spend a considerable amount of time building a pipeline which is a you know security wrapper around a protocol we then have to get that pipeline audited and then we have to propose it to the Dow to be implemented through an upgrade So currently as everyone knows on our swap page we only support curves if we wanted to use uniswap we would have to create a uniswot pipeline get that audited and propose it through bip um and this doesn't scale well and it became quite clear you know when all the people all over the place were like hey can we use this protocol can we use this protocol can we use this protocol that we really you know needed to get out ahead of the pipeline game and basically find a way you know for all of these different protocols you might want to be using things like the root token or beans or deposits to be able to just instantly have access uh you know or or you know for our farmers who want to use their internal balances and use Beanstalk without having to have their balances leave the Beanstalk ecosystem can now through one generalized uh you know pipeline be able to interact with any contract um so the way this works is you know basically we've extracted a new contract um you know that's outside of Beanstalk called Pipeline and kind of from a security risk perspective where we get into problems is when we form generic function calls to generic addresses from a protocol that has some sort of you know value that it can't have be extracted in the current transaction um so by having pipeline be a separate protocol we can allow generic function calls to happen in a closed isolated environment without putting any of the assets that are in Beanstalk at risk because pipeline is performing performing the function call and not beanstock itself so what's really cool about this is once pipeline is released any protocol that wants to use the root token at the base layer through for some sort of liquidity for something or you know any protocol that wants you know to have uh you know or that wants its decks to be supported or if we want to support Ave through our UI through Farm balances uniswap you know pseudo swap any of these protocols that farmers may want to use are now capable of being supported through the UI so we when we look at kind of how we can expand the breadth and just the use case for being we believe that pipeline is a very serious crucial part of the architecture just for from a composability perspective to allow Farmers to have access to truly anything within D5 that we're able to or that we you know have that there was enough of a demand to build some sort of UI on top of it to interact with through Beanstalk um so that's just a a bit of kind of why why we why we took some time off to work on Pipeline from well specifically as we just believe getting out ahead of potential other protocols being able to use Pipeline on top of beanstock um you know is important on top of that being said the you know the pipeline code overall is much simpler than Wells um you know it's only you know a few a few functions and these functions are quite quite generic so from the a like a scope perspective you know it only took a couple weeks to get done well you know Wells is you know still a significant amount of work left and then um you know a third piece to this is that this generic pipeline functionality is something we can leverage throughout other um you know features that are being built out on top of being stock um to to use this generic function call uh you know solution so for instance um you know Roots been working on you know kind of a beanstalk native Seaport uh you know Improvement protocol where you know we you know they take the base layer of Seaport add support for Beanstalk assets and then are basically adding support to be able to you know enter kind of generic type of contracts between multiple parties through the use of Pipeline and you know kind of by creating pipeline as this kind of public goods closed system you know contract we're able to kind of take you know all of the different parts of Beanstalk that need access to generic function calls in some way and just have them route through pipeline um so it really is a core piece of infrastructure that is going to be used throughout kind of the Beanstalk ecosystem in different protocols as they continue to be built out and think it's just important that you know we as farmers and you know the Beanstalk developer ecosystem start to understand kind of how we can build you know truly build the best user experience in D5 which we all know is you know when I come to my computer I know what I have and I know what I want to have and I want to be able to do that in one transaction and that's kind of the goal here you know we're creating an interface from you to basically just you know you're starting where you are and you can basically move these assets anywhere and it can all be done in one transaction and you know think there's a lot of fun uh to be had so you know that was a bit of a rant but hopefully that was um kind of informative and really just want to make sure that we all collectively understand the power about this tool has so we can try to collectively find the best ways throughout defy to take advantage of the existence of the pipeline and help get the bean token and you know the eventual release of the root token used throughout numerous different protocols pipeline now can we say that you know anything can be done and it's up to you know whoever wants to build on top of it you use it or there is some limitation to what the pipeline can do and then it will require some upgrades let's say the goal here again is you know we want to be moving towards a place wherein several years Beanstalk is at a place where the there's a minimum amount of upgrades needed and you know the goal of course is such that Beanstalk never needs to be upgraded again and we can get rid of governance altogether whether that goal is even feasible you know is yet to be seen um but we need to start moving and working in that direction now we compare kind of the pipelines model to the pipeline V2 model right the pipeline V2 model allows for us to add support for new protocols permissionlessly where the python pipeline V1 model you know requires the governance update so this is a very clear example of how kind of we're able to take a feature that previously was kind of functionality gated behind governance and allow any protocol to have exposure to it so you know kind of in doing so um you know when building pipeline V2 we really tried to think about every you know every possible use case someone could want for you know a generalized you know function call solution and you know really took time to like hammer in how we can copy return data and move call data around between functions so that hopefully will never have a need to upgrade this piece of software again you know that being said you know defy and just you know kind of the state of on-chain smart contracts is constantly evolving and innovating and it's impossible to say kind of where things are going to be you know three to six months from now um when we first built Beanstalk you know it was the least generalized protocol of all time um you know there was this concept of beans and LP and The Silo can only accept beans and LP um you know with Silo V2 we restructured The Silo to generalize it to a token address so now we can kind of take any erc20 token to get dressed you know in the future with the silo once we have you know Wells V2 you will probably want to generalize it to accept nfts or 1155 tokens and kind of the point is here um you know it's really it's you know where we want to go is you know peer generalization to where we have everything is possible within Beanstalk permissionlessly and doesn't require protocol upgrades and you know it's it's it's not quite clear you know what that final vision is but you know think piece by piece as we put this thing together um we're starting to see a path for how we can remove the need for all these sorts of whitelists and incremental upgrades which ultimately you know just become a a problem when it comes to you know kind of making a sustainable long-term focused system so small steps to towards generalization and permissionlessness asks is the generalized pipeline something that's comparable to photo combo I'm not sure if I'm pronouncing that correctly but I'll put in the link to that personally have never heard of it but you know we'll take a look all right James then asks um and he also shared you know what what is what is the theme's thought on the recent string of exploits um so he says you know we've done a good job in Boston security through Halburn and the bug Bounty for example what is curious to hear you know what are the attacks that are happening what's his impact on on beanstalk's utilizational capabilities and he's referencing the recent mango exploit well so I'll hop in here for a second it's just I think it's really important that we as a collective really recognize that even if being stuck at the base layer is secure if a protocol that is built on top of Beanstalk that attracts a substantive or significant amount of bean liquidity or Beanstalk assets into it and then that protocol is act exploited uh that that could very well uh directly affect Beanstalk in a significant way even if Beanstalk at the base layer is secure and so what's happened to uxd as a result of the issue with mango markets while uxt is built on top of mango markets the the exposure to protocols that are above and below you in the stack but above and below us the Beanstalk whatever you want to think about it uh that is it's something that is is really important that the Dow keeps in mind as we continue to develop lots of different things and it's to be frank it's everyone that's still involved in Beanstalk is brave because to some extent there's there are all of these unknowns and there are these new constantly newly discovered attack factors and issues and some of them are known some of them are unknown but the point is that there's almost there's so there's so many different ways that users of Beanstalk are can be exposed to risk that you know we we the slower development period that's been the slower development Pace that I think that's been happening across the board and it's not to say that there's less output there's probably a lot more more output happening simultaneously because the group of developers on and around teamstock is growing but the the pace and the desire to to to to all collectively uh work on things that are audited first and howborn being such a meaningful part of that uh wanted to to give them a shout out as well just because of they've been so flexible and uh Now with psp-8 uh passing uh a fourth stream is going to be funded so they can increase the amount of different things that they're auditing simultaneously uh such that they can keep keep up with all of the different code that's being implemented on and around Beanstalk uh would just kind of say that I think from a high level the these that these exploits or hacks or attacks are a reminder that there probably is no such thing as spending too much on security from the Dallas perspective and we should continue to uh judiciously fund halborn we should try to find other Auditors that audit being stopped on a continuous basis in the same or similar factor to halborn uh the the unified bug Bounty is pretty exciting uh to get underway from our perspective but this is a a scary Journey that I think we're all continuing to embark on and every hack and every exploit is a reminder of that and we should all we should all a remain Vigilant individually uh and collectively but B we should just all try to do our best to build secure pieces of Technology even though it's all open source and that makes it more likely to be attacked this is this is the the wild west to a large extent from that perspective and uh the attacks the attacks yesterday or two days ago are certainly a reminder of that so uh it's very unfortunate to some extent that people are losing money because of it but this is this is the nature of this is the nature of development in this environment so we're all I think we're trying to continue to all do our best and that's all we can do and I guess this is a reminder towards the wells you know everyone I guess is excited about Wells and and when Wells and deploying the wells isn't the challenge the challenge uh correct me if I uh if I'm mistaken Publius is in the Oracle and that impacts how Beanstalk basically reacts with men think and this is why something like that as you said you know there is no such thing as waiting and you know ensuring that it's being deployed uh correctly or in a secure manner well and to that point it's like the the wells are being implemented in a way where other protocols can in theory use them and if the wells are used improperly or not even improperly but simply in a fashion that leads to uh mispricing based on whatever that other protocol thinks it's going to read and then it reads something different even if there's no problem with the Oracle implement the well implementation the Oracle implementation there's there's an endless different bring of ways that through an oracle there can be problems but it's not just about getting the base implementation right which is obviously key then it's just it's also a question of having others use that basic momentation the right way and uh that that's kind of maybe the bigger point to me which is the security is a a perpetual a Perpetual battle and Tebow is this earlier point one of the ways that you can really start to get a sense of security is if the code doesn't change and therefore the the more generalized that that the the more generalized the code the the less likely it is that the code needs to be changed and therefore the longer the more likeliness that the code can remain in its current state for longer periods of time and therefore create the create security over time by simply existing and having value on it or exposed to it and not uh being exploited so there's there's a lot to be said for for as from a process perspective how this is this is a I think that the Dow is probably going to win this win this war if it does through a process right through a flow and steady process where the tech that people are using someone may deploy something uh that's not audited that integrates being stocked uh you know how can we make sure that Beanstalk users know the difference between audited and unaudited code right like these are fundamental questions where if the Dow isn't careful and Beanstalk ends up inadvertently picking up significant significant exposure to unauded or even if they aren't audited there's still the potential for major risk uh how does the the Dow minimize risk uh in in all of these vectors so it's this is I mean yesterday or I guess it was two days ago now is uh just a really good reminder of that and from our perspective this is you know this is the challenge the challenge that we're all collectively trying to to address at the moment okay and chance follows up and asks if you know our Auditors uh maybe hell Vernon who had Turtle bits before them if they assess let's say economical exploits and not just like code exploits well this is a perhaps the best way to answer this question is that it's really a semantics issue here what is a half versus an exploit uh in the case of in the case of uh and a good audit you'd expect the the audit to to cover both potential flaws in the code where the implementation of the code is not performing as intended as well as consider the intent the implications of the intended version of the code in the case of both Trail events and Melbourne certainly a trail of beds they did include certain comments about the economics that that were not remediated ultimately but they commented about the the risk to the protocol from an economics perspective so uh it does seem to be within the scope of audits in general yes and as as you said probably as they did and that was trailer bets they did have some comments on you know one of them for example was that there is a risk that pods may never be paid for example um I would say that those who understand the protocol and that that is us before anyone else are are you know it is us for us to see if there are any anything from the economics perspective that doesn't make sense or it could be exploited it could be made use of before relying on on Auditors uh on that front to mention as well Mr manifold says that trail of bed has been prepaid for another for another audit that will start sometime in February and that has been covered or appeared by by root okay we will give it another minute see if any any other anyone else has something to add and once again you don't have to add it in the chat just unmute yourself and you know start talking hey guys just wanted to introduce myself I'm chai Kitty I've been working on the incentivized portion of the sunrise call um basically the idea is that we'll reduce the number of beans Minted as a reward just based on whatever like the current ethereum price is current gas rates current Bean price um yeah but it's going pretty well it's just about completed from my uh from my side I think we're going to be discussing some of the parameters um just like some small tweaks but other than that basically finished so definitely excited to get this rolled out and see that Improvement Kitty can you take us through the thinking how are you looking to optimize the sunrise function fees or reward um yeah here let me share in the chat this was something that uh Publius had written actually but basically the idea is um we can check exactly or like we can estimate very closely how much gas the the call to do Sunrise is going to cost and using that we can also get the uh like the base gas fee for the current ethereum block and we can check you know just basically multiplying them together so the the fee that they're going to have to pay times how much gas they're going to have to pay and we can use the current ethereum price and the current Bean price to kind of estimate about you know what is what is the cost of calling the sunrise in beans then we can compensate with you know a similar number of beans whereas right now it's just a hundred and then times you know the the exponent for how many seconds it's late um but currently it's it's overpaying a lot because gas has been smaller and ethereum price has been lower uh relative to when when bean stock was first deployed and pizza man asks what's the target profit for calling the sunrise yes that's a good question actually that's that's something that I think we're gonna have to discuss a little bit like I mentioned for some of the target parameters but um kind of what I was thinking is it needs to always be profitable assuming that the the call won't always succeed because there's always I mean at least you know based on observation uh throughout you know beanstalk's history there's usually at least two uh competitors you could call it who are trying to call the sunrise at the same time and so the idea is there's no guarantee that whoever's doing it will actually succeed 100 of the time so kind of what came to mind to me is it it needs to at least be guaranteed to be profitable assuming that they would only succeed half of the time so like there would be a reward of maybe at least what I'm thinking it would be maybe like two or three beans and then plus um basically the cost of them having one successful sunrise and then the cost of them having one failed sunrise so that way if if they succeeded half of the time the idea is each time they would they would profit like a few beans and then you know some some Bots maybe they did it through Mev whatever and then they actually succeeded 100 of the time then they would end up making a little bit extra is it accurate to say then you're optimizing at for time as cheap as possible so again you don't want to make it so cheap that becomes delayed to call the sunrise right yeah so the the ideas it would it would still never be delayed um in theory because it will always remain profitable to call it immediately what do you think about having vintage of assumed failure calls aliens uh depending on whether the sunrise is ever late meaning if the sun rises late then like decrease the difficulty almost such that you assume there are a higher rate of failures that's interesting because if the sunrise is late I would assume then there would be a lower rate of failure because that would mean that there weren't there wasn't like such an immediate rush to to call it on the first block but under this system wouldn't it really be that it's because on average maybe like last season the the Bots collectively all there were so many Bots that this season the Bots assume that it's not profitable on an expected value basis or or or is the system over optimizing here yeah I mean I I guess I guess that's possible um I'm not sure what you would do to just yeah yeah I mean because that that's you know one of the the benefits of the of the current design I guess which is that it's it's so large that you know it's almost always worth it to at least try even if the success rate would be far lower than 50 as long as there's some success rate uh most of the Bots would would at least try to get it but yeah it's like some minimum some some bot is gonna have some success rate that is pretty good right like it's not like what's gonna be the only thing that really matters the best two or three bucks it's not about the tenth bot the tenth bot at the margin so I think there is some range that can probably be explicitly defined here but maybe it does make sense to still have some sort of toggle but maybe not maybe we don't need to talk because you make an interesting point that if it's delayed then that means that no one called it and then someone should call it the next block but most is going to be a one block delay probably but still yeah I think I adding any sort of on-chain State like a toggle or you know varying value create you know increases the gas costs of calling the sunrise function and thus in turn we'll just probably cost more money overall you know think we can still get this to be pretty optimized and efficient without having it you know require any sort of like on-chain state I think it's already pretty good and on the on the reversion side you know imagine most Bots you know are using flashbots um or some sort of private RPC that will you know not submit the transactions if they fail yeah yeah I mean the majority of them will but at least there there's no 100 um you know not not 100 of the the validators would would have uh have that capability so I think they're they're still it still does need to consider the that the case where people will be submitting transactions and there will be the risk of it failing so just want to make sure the reward is enough to still incentivize people to try who know that they're not going to succeed 100 of the time look forward to saving us some money check it yeah also just shout out to try Kitty for just raising raising their hand and stepping up to do this so very cool yep happy to help all right I think um unless anyone else has anything else to add this would be a good time maybe to end this meeting thank you all for joining us and this week's uh doll meeting and and we'll see you we'll see you next week