• Recordings
• Meeting Notes
• Engineering update
• Proposals update
• Design Updates
• Publius Updates
• Bean Sprout
• BOP-2
• BIP-31 Discussion
• Transcript

Recordings

Meeting Notes

Engineering update

• There is a lot of stuff in flight, a lot of time spent with Halborn to structure the code base. Starting to think about how to structure the repos that Beanstalk Farms pushes in the future. More improvements in the SDK with the deposit router, and the team is working on the UI for the Pod Market v2

Proposals update

• BIP-31 is the Beanstalk Farms Q1 2023 budget BIP this includes 750,000 Beans, and a 250,000 Beans to cover audit work
• BIP-32 Implementation of Serph in Beanstalk
• Serph is going to be a notary of sorts that will be supervised by Halborn. This will include certain function calls including but not limited to WhitelistToken(), DiamondCut(), and others

Design Updates

• Interaction pattern with an axes overlay for pricing curves - zoom- using a modal overlay to fine-tune the area displayed
• Interaction pattern to toggle Order-book columns to show data in different ways (I.E displaying price as an Average or Min/Max)

Publius Updates

• Publius is very excited with the work around the Tractor, and that should be ready for audit next week
• The Tractor will work with Pipeline and Depot to use assets and perform functions between multiple accounts in one transaction. This can create a generalized abstracted peer-to-peer marketplace. This can create orders with any asset only limited by the UI. This is roughly structured around SeaPort. An NFT marketplace, an order book for Unripe Assets, and a Pod Market that can use deposits are all examples that can be done with Tractor.
• This will be a standalone contract similar to the relationship Beanstalk has with Depot. This could be considered an extension of Depot. Tractor will also allow for automated Farming. For example, you could set it up to pay someone to Convert when the price of Beans is below a certain price on your behalf
• The thinking around deploying a separate contract than implementing that into Beanstalk is because there are a lot of trade-offs with using the Diamond contract standard. The main trade-off is security, every time we pass a BIP there could be a bug, and this puts Beanstalk’s assets at risk. If the new feature is not necessary for the core Beanstalks functionality, it is more secure to deploy the new feature on its own contract. One advantage of one single Beanstalk contract is gas efficiency
• Wells might be able to be upgradable in the future so if there is a Wells v2 in the future, we do not have to fragment liquidity. The other solution for this is when the Stalk gauge system is implemented into Beanstalk you could just let the market decide where it wants the money to be in v1 or v2
• Another Publius is working on the end-of-year piece, they are hoping this will start a lot of meaningful conversations

Bean Sprout

• Working through another version of the root token (which chicken bonds, root markets, etc are potentially downstream of). more updates are to come here once the code is ready
• Working through potential fiat <> crypto ramp options for the beanstalk ecosystem. the space has been in flux for the past 6 months given market turmoil but confident we have found solid partners with integrations ready sometime in Q1
• This is Manifold's last quarter at Bean Sprout. They appreciate the DAO and hope for continued success. decentralized building has many challenges but they truly believe the group we've got here is competent and capable to continue pushing through!

BOP-2

• The Hats finance team is updating the contract as per the passed BOP-2
• The Hats team was on the Bean Pod, which should release soon

BIP-31 Discussion

• Some people think Beanstalk Farms should change the pay structure to pay once a BIP passes. Guy does not think this will attract really good talent, but you may be able to attract some people. They also add that not all the work for a BIP is done when the BIP passes, for example, the Pod Market is being worked on to be implemented into the UI still.
• Publius thinks that it is important to make sure the Beanstalk money printer does not have to pay for a bunch of “shit”. They also question if the DAO should approve any centralized ie should everything be done on an individual contributor level/ individual project. In the future, it might make more sense to do projects on a grant basis. Publius thinks there should be more competition between organizations working on Beanstalk for the best outcome for Beanstalk. Publius adds there is a lot of work to be done to get to a point where there is no longer a need for a development organization. In two years of Beanstalk development, there should be enough tech for real economic activity. Guys agrees with the notion that there should be more organizations working on Beanstalk and this should help with community members asking Beanstalk Farms contributors to work on X when they are working on Y. Guy also adds that there are many ways to get compensated for working on Beanstalk.

Transcript

we uh go ahead and get started I suppose so I'll be host today mod the said he's on the road so perhaps we can first start off with uh spending a couple minutes uh giving some updates on the the Beanstalk Farms front so Silo chat are you cool with the talking about what's going on in your world for a minute or two yeah for sure uh thanks guy and happy holidays uh so everyone um another sort of you know big week of engineering stuff on the farm lots of stuff in in flight so we've spent a lot of time over the last couple weeks as mentioned working with uh halborn to really nail down how we want to structure some of the code base and and document some of the code base moving forward and have gotten some really good uh had a couple really good sessions with them and gotten some good feedback so we're now beginning to take that excuse me take that learning and apply it across the rest of the the code base so documenting the field is next up in particular on that front so I don't know if if those here have seen some of the PRS on that front that are that are currently open but those are those are visible on GitHub so go check them out if you're interested in addition uh as a part of our uh sort of gearing up to launch a bunch of new things in the new year uh Wells uh you know amongst others were starting to think a little bit about some of the uh structure for the different repositories that that Beanstalk Farms pushes code wise and how those all interact um from a development standpoint it's been a really interesting challenge to manage a number of different pieces of infrastructure that are getting deployed at different times and and need to be resilient for example keeping the sub graph and the UI in sync um and in sync with the protocol has been has been a challenge so uh Alex uh who I don't think is here now but um he's uh one of our sort of more recent engineering ads on the Beanstalk Farms team he's going to be taken care of some uh some upgrades on that front which will hopefully help us move uh move a lot faster in terms of rolling those different uh you know sort of pieces of tech out as well as keeping them uh more safe and secure as we do that so a lot of sort of infrastructure things this month as mentioned previously but generally I'm just continuing to move forward there I think materially there's there's been some work in the SDK over the last couple of a couple of days related to uh basically making a deposit router so you can start with any number of tokens and and end up depositing in the silos so that work's been done and then uh some stuff going on in the UI related to the Pod Market currently which will probably be the next the next material update for the for the Beanstalk UI so um yeah all uh I'll pause there thanks Chad um perhaps to spend a minute or two talking about some of the uh proposals that were shared yesterday um that are in the draft and discussion period so bip31 is the Beanstalk Farms budget proposal for q1 of next year and bip32 is the implemented implementation of Seraph into Beanstalk so perhaps to get a little uh give a little bit of an overview on both of those um the intention of Seraph is you know at the moment uh Beanstalk governance is is entirely off chain and you can imagine that you know there are situations where or let me rewind a little bit so the intention behind Seraph is to have a notary of sorts from halborn essentially uh check various things for different protected functions that are called in Beanstalk and so in particular the ones the intention is to have serif protect uh most of the owner functions in Beanstalk so you know just to name a couple things like whitelist token D white list token in particular diamond cut which is the one that can add remove and change functions within Beanstalk and so the idea is to have uh you know a third party like Seraph do a bunch of verification upon the execution of that call and so you can imagine you know one thing in particular that's not getting checked on chain in advance of a proposal is that the proposer wallet has enough stock in order to pose a bit so you can imagine that that would be the sort of things that that serif would check along with some more you know security focused checks like checking that you know the stock supply in a bit wasn't manipulated by a flash loan things like that so would love to see some discussion in that channel particularly as it pertains to you know how the Dow can think about mitigating any censorship risks as it pertains to implementing Seraph so that's a quick uh overview on that front and then on the bip 31 front um the budget uh this time around proposes DeMent uh 750 000 beans for Beanstalk Farms operating budget in q1 uh previous the the previous quarter proposed to meant uh a million beans and I think at this point we'll probably have around uh 400 000 left over so a slight decrease on that front but uh if you check out the proposal it also uh proposes to Mint 250 000 beans to cover various uh audit work in the future whether that's uh on the halborn retainer front or setting up uh audit competitions through programs like code Arena uh think that you know adding processes like those uh to the halborn retainer agreement as well would be good to get as many you know white hat eyes on Beanstalk code before it's before it's deployed um you know mixolydian dropped some some thoughts in the in the barnyard chat yesterday that perhaps we can discuss on this call but uh I'll I'll pause there and maybe we can make the rounds first before we before we discuss that although I just realized uh it looks like sweet red beans mentioned they had a doctor's appointment so perhaps I can briefly read their their update they dropped in the chat so they mentioned uh always feel free to bring them questions still working on the ux for the Pod Market V2 the scope of this ux work has expanded into designing a generalized charting UI which will be able to support arbitrary assets whether it's pods 1155s Etc they mentioned that the work will likely extend into late q1 but expecting to have a full prototype ready by the beginning of January among other things like the ability to add claiming withdrawn assets to arbitrary transactions in the UI Etc so I'll let uh I'll leave it to them to expand on that perhaps and in the next down meeting uh did you have any updates in particular that you wanted to give today um on this end you know uh super excited about you know the work that's been coming along specifically with tractor um you know hoping to have that ready for audit probably within a week um or as soon as the next audit stream opens up um and you know have a draft of an RFC that you know really excited to looking for you know to share with the community soon so uh you know look forward you know look look for watch out for that coming soon um you know on the on the could you talk a little bit about what what tractor is sure happy to um so you know one of the the most recent pieces of Technology pushed into the Beanstalk ecosystem was Pipeline and Depot Pipeline and Depot allow for um you know kind of arbitrary transactions to be executed from an account and these arbitrary transactions can perform any number of on-chain actions you know or function calls to generic smart contracts tractor and you know takes this a step further by allowing pipeline to use assets and perform actions on behalf of multiple accounts within the same transaction what this provides is kind of a extremely generalized abstracted peer-to-peer transaction marketplace where one market participant can create what's called a blueprint which is a sort of order that can perform any number of specified on-chain actions blueprints also can use call data provided by a second party that actually executes the order or blueprint now what this you know what this uh allows for is the ability to create orders that can be the exchange of any on-chain assets or actions um you know limited only by the imagination of uh you know kind of the UI and the client so um to some degree you know it's Loosely based off Seaport but generalized you know uh but generalized to the point where you know uh C Port only supports transferring of erc20 erc's 21 and ERC 1125 assets between parties this is extremely limited uh when it comes to engaging in contracts like opening a future um performing some peer-to-peer bet uh or you know kind of some on-chain rate swap or any contract that multiple parties will want to engage with in a peer-to-peer fashion tractor takes all uh you know supports everything C support supports and more in the fact that it's able to leverage pipeline to perform you know these generalized on-chain function calls so ultimately what tractor provides is the ability for off-chain order books to be created that create you know that support um you know pretty much any kind of peer-to-peer exchange or peer-to-peer agreement uh on chain um so you know very simple use cases of this are uh you know uh an nft Marketplace uh you know uh an order book for unripe bean deposits um you know a uh you know a pod Marketplace kind of V3 that allows multiple orders to be created on the same pool of assets a pod Marketplace V3 that allows orders to be created using deposits instead of circulating beans um you know kind of the ability to create some kind of order book to borrow or lend beans from uh you know certain parties uh Etc um so you know overall you know there's a lot of middleware technology that needs to be built on top of this uh you know to create that off-chain order book and indexer solution um as well as you know creating uis for each of these individual markets that track those supports but think in general this is a very fundamental piece of code that you know it's great to have in a state where you know it's ready for you know kind of final Security checks before being deployed on chain and um you know it's something that has kind of been in the works for a while so super excited about kind of the project overall awesome thanks for all the context and it sounds like this would be a standalone contract similar to the relationship being stock has with pipeline um more similar to the relationship Beanstalk has with Depot um to some degree it could be considered an extension of Depot um but ultimately what will likely happen is you know initially some stand-alone tractor or you know Depot 1.1 contract will be deployed that supports tractor and you know with the with the idea that at some point maybe tractor facet will be proposed to be added to Beanstalk at its core layer um to provide for you know gas efficient actions um I guess another thing that's important to note with tractor is it you know through kind of you know it's it's immense generalization it also supports automated farming what this means is farmers will be able to create functions or be able to create orders that basically pay someone to plants on their behalf every time they have a certain amount of own beans or you know pay someone to mow on their behalf every time they have a certain amount of grown stock or pay someone to convert on their behalf every time the being price is below a certain price or pay someone to show on their behalf every time there's soil or the weather is above some number um so you know you know tractor was honestly initially created with the intention for automated farming and you know that's where the name tractor came from but during the process it became quite clear that tractor was capable of far more than just that um you know which is extremely exciting awesome well thank you for uh for running through all that not sure if you had anything else you wanted to give an update on but but that was great do you want to briefly talk about how that process that you described on uh potentially the best way to deploy tractor first as a standalone immutable contract and then eventually as an upgrade to being stock as a facet and how that may make sense at the precedent for how to how to deploy some of this new tech going forward happy too um you know it in general you know one thing that's kind of you know Beanstalk was ultimately or originally deployed using eip2535 which is this multi-facet proxy implementation which allows a single contract to have infinite functionality um you know eip2535 is extremely exciting uh Innovative and thought-provoking proposal um but you know kind of as as Beanstalk has experimented with the diamond uh you know over the past uh you know a bit more than a year it's become quite clear that you know there are obvious trade-offs to this you know uh you know this unlimited functionality single contract and the most important of which is security um you know as as uh you know you know Beanstalk has had numerous emergency bips over the past couple months obviously there was the exploit uh earlier this year and it's you know becoming um clear that perhaps the best path forward is not a single monolithic contract that holds all functionality and more importantly all of the assets of all of the different modules that's a part of Beanstalk every time a bip is executed on chain and functionality is added or removed to Beanstalk this functionality might just might not you know might might you know not just might introduce new bugs at the protocol later layer but uh you know even more uh notably puts all of the assets that are in beanstock at risk now this means that you know modules like The Silo which have been you know deployed on mainnet for you know at least a few months now has been interacted with by probably you know several at least several hundred different accounts depositing money withdrawing you know uh money and you know it's you know one could consider The Silo relatively battle tested at this point now something we saw like in the case of bit 28 or the Pod Marketplace was updated to V2 and backwards compatibility was not properly accounted for for V1 orders resulting in the ability for existing V1 orders to withdraw more funds from Beanstalk than were initially deposited into the order um in kind of what this allowed for was for funds not just to be stolen from other orders but from any any tokens within beanstock including the silo so The Silo you know a a module of Beanstalk that's been deployed for several months and is Battle tested you know as as stated um now is at risk due to an upgrade in another module being the marketplace um monolithic smart contracts such as Beanstalk you know are extremely vulnerable to this type of uh you know vulner you know as I guess uh you know exploit and you know thus you know kind of it's you know uh upon discussions with you know other developers in the Beanstalk community and you know just general uh discussions and you know when architecting new products it's become clear that you know perhaps uh you know different modulized smart contracts that can be deployed as permissionless unupgradable pieces of software might be a better path forward than continuing to you know upgrading the monolithic Beanstalk Diamond especially when it comes to pieces of functionality that aren't necessarily um you know related to the core functionality of being stocked as a protocol you know for instance something like Wells Wells is you know a decentralized on-chain uh you know liquidity order book and you know being stuck as a decentralized uh you know credit based stablecoin protocol does not you know it has nothing to do with you know uh a decentralized Exchange in its core functionality other than it needs to use that as an oracle um and thus you know it begs the question you know should should you know the wells be implemented as a part of the monolithic Beanstalk you know which implies that all of the assets that are stored in Wells would now be stored in Beanstalk and upgrading the Beanstalk protocol to include this new module um puts all again all of the existing assets in Beanstalk at risk versus deploying Wells as separate independent contracts that are permissionless and unupgradable each storing the tokens in their own individual contract such that the most damage an exploit could do would be to steal all of the tokens that have been you know deposited into that specific well rather than every token that has been deposited into beanstock in general um you know it should be noted that there are advantages to the monolithic contract most notably um gas efficiency and uh you know easier middleware and UI implementations um you know so you know it still kind of you know collectively think uh you know the Beanstalk Community has a lot of work to do and kind of you know experimenting with developing and you know uh you know brainstorming around the best way to deploy code in the safest manner on chain um you know however think the rollout with pipeline was incredibly successful and a great proof of concept to this you know uh you know deploy the functionality on chain as permissionless uh code and you know if applicable you know potentially at a facet later down the road that you know ex you know resembles that permissionless piece of code uh you know for instance Depot facet is uh you know for instance the depot Standalone contract uh inherits both the token support facet and the depot facet that were added in bip 30. um so you know the functionality that it was admined at 30 had already been deployed on chain for several weeks and um you know therefore by the time bit 30 got around to being proposed you know there were several weeks of real on-chain battle testing that had already occurred it you know making you know adding more you know assurances that uh you know the the facet being the fastest being added were properly secure um so you know in general you know this you know as discussed plenty of times in you know these Dow meetings you know security is uh of utmost important to Beanstalk and you know probably in one of the if not the largest risks to the protocol in general and you know you know happy to discuss and you know enjoy engaging in discussions around Security in general so uh you know that that's kind of the thoughts you know kind of some of the thinking that has gone into development over the past month or two and uh you know look forward to you know engaging in more stimulating conversation with the community as it relates to on-chain development thanks for running through all that Publius and uh you know anyone should feel free to to unmute and speak up and ask questions uh one question on my end is I was curious if uh is it fair to say that one of the trade-offs would be for example if Wells V1 is deployed as a standalone immutable contract that once a future Wells two or something like that is deployed that liquidity is more likely to be fragmented whereas if Wells if you want is implemented as you know facets and Beanstalk the bip that implements Wells V2 could migrate liquidity this is true guy um you know that being said uh you know one option you know and this you know this is uh a feature that is currently in discussion for being included in Wells is you know the ability to deploy Wells as upgradable smart contracts such that you know if there was a well that the Beanstalk Community was interested in deploying as an upgradable well such that it could be upgraded to a V2 later down the road that would be possible um however you know uh you know an alternative to that would be you know the you know uh you know fast forward a couple months down the road you know this stock gauge system is in full force um you know and you know there's a V1 beneath well you know has some amount of liquidity it has some stock age stockholders are you know earning you know uh grown stock on top of that uh you know on top of their LP deposits and then Wells V2 gets released a new V2 beneath well is deployed you know implying that the initial one was deployed as unupgradable um stock you know one would imagine that the the stock you know that stockholders would start to shift their gauge vote towards this beanie V2 well as it becomes clear that it is you know secure on-chain battle tested code and alongside the migration of stock vote to the beneath well liquidity would slowly kind of migrate over as efficient you know as is efficient um so you know think think uh you know yes that you know Auto migration is a luxury that comes with upgradable smart contracts um however you know uh you know you know it's important to take it you know to take it all in the context of um you know good on-chain security and you know uh the question should be asked whether you know being if you know V1 well lpiers uh you know even want to migrate to V2 you know say the you know there's some some voting governance structure such that all LP token holders get you know one vote and you know 52 percent of them vote to upgrade the wealth of E1 now that other 49 is forced to have their liquidity migrated to a v2l where in a system where uh you know the V2 well is you know you know the V1 well is not upgradable and a separate V2 well is deployed it becomes an option for when and if uh you know V1 beam if lpers migrate their liquidity to V2 uh you know which could be which is so is you know kind of by you know deploying you know by performing upgrades through new contract deployments rather than exist you know upgrading existing contracts one could argue that that allows even more customizability and optionality for farmers got it makes a ton of sense um yeah definitely interesting to consider how it would play with the the stock gauge system where you know you could just let the market decide and and have individual participants decide uh on their own to migrate their own liquidity or not and then you layer something like tractor on top of it you can imagine it actually working pretty efficiently definitely I'll pause for a moment or two to see if uh other folks want to chime in great um I guess I'll I'll check Publius was there was there anything else you wanted to talk about today not on this end uh the further the other public eye over here nothing in particular uh other than continuing to work on the the end of year uh piece which the the more we spend time on it the more the scope continues to increase so I feel like now the the end of the year may be a little bit of a tight deadline but continue to spend most of our brain power on that uh document and hoping that that really provides a lot of uh substantive uh or substance uh to talk about uh in the new year so uh hoping to start a uh start a variety of different meaningful conversations that probably need to be had and uh yeah it's uh hard to hard to articulate separately so trying to trying to spend the time to do that awesome thanks for the update um Mr manifold mentioned in the chat that they weren't able to make it so I'll quickly uh try to paraphrase that paraphrase paraphrase their update so they mentioned working through another version of the root token which chicken bonds the root markets uh et cetera are potentially Downstream of more updates to come here once the code is ready they said uh working through potential Fiat crypto on-ramp options for the Beanstalk ecosystem space has been in flux for the past six months given Market turmoil but confident we've found solid partners with Integrations ready sometime in q1 they also mentioned that this is uh their last quarter at bean sprout they appreciate the Dow and hope for continued for Success uh decentralized building has many challenges but truly believe the group we've got here is competent and capable to keep pushing through thanks for the update Mr manifold uh obviously uh unfortunate that they won't be spending time on on bean sprout moving forward but uh the amount of value they added to the bean stock ecosystem over the last six months has been immense and I'm sure uh you know dedicating their their full attention to root will bear fruits if you will all right I'll go ahead and uh pause for uh 30 seconds or so see if uh other Beanstalk Farms contributors want to discuss what they're working on uh any community community members want to chime in uh ask questions uh talk about what they're working on Etc hey guy do you hear me all right yep I can hear you sing hey uh good afternoon everyone I figured I would chime in since I didn't hear anybody else um just a quick update um again thank you everybody um that considered and voted for Bop 2 that passed last weekend um really appreciate the feedback and uh we'll just Echo again that decentralized governance is something that we're all learning about and um I'll I'll actually share a really interesting blog post that was um posted by one of the early contributors to coinbase on the topic of decentralized governance um just to kind of let you all kind of take a look at that so as far as blp2 is concerned I've seen some community members have questions about that just to kind of um you know give a pre-holiday update on that um the hats Finance team as they're going to be adding some they're tweaking the contract for the approved Bop so they're going to be merging the updates to the main contract by early next week aside from that shout out to the bean pod for interviewing has finance and just want to extend my appreciation to them and to to be in stock farms for enabling that um so we'll be you know once that podcast gets posted we'll be sharing that on Twitter and um yeah once hopefully the new year comes around and everybody's schedules are opened up we'll have more updates so just wanted to kind of give that update so the Community kind of knows where we stand on things thanks zinc so I know mixolydian left a message in the chat which I you know want to make sure it doesn't go unaddressed um you know my preference would be to to not paraphrase and read the whole thing but it is quite long and uh I I dropped a few paragraphs in the the budget bip channel in response where they they shared the same message but perhaps we can briefly talk about it I think uh so they they suffered some concerns about the budget bip and you know mixolydian if you're if you're listening this later and you don't think this is a an accurate paraphrase feel free to call me out on it but I think uh there's two main things uh that I take away as the argument one of which is that the Dow shouldn't necessarily be paying for work uh in advance and that you know all compensation for any work done should be you know upon the commitment of a bip so I presume you know as the proposer award if you will so you know I guess just to briefly share a couple thoughts on that front I think uh you know I think in theory that sounds uh it sounds nice and you know perhaps uh I guess there are a couple different things uh I'd comment on one with regards to I guess the uh quote unquote stability of folks uh working on the bips whether that's at the contract level or folks working on the UI the documentation Etc I think that there's probably uh you know a handful of folks you could convince to you know work under a compensation structure like that where there is nothing guaranteed until the code is committed uh you know probably the folks that were working on being stuck for free over the summer but think that as it pertains to you know attracting a meaningful volume of quality talent to working on Beanstalk I think that's a a tougher tougher cell or value proposition if you will and then on the other front you know from my perspective uh don't think that all of the work surrounding a bip is necessarily done by the time that a bip is committed I mean just to give a specific example bip 29 was committed uh perhaps like a month or a month and a half ago you know red beans have been been grinding on either designs for a new pod Market UI which as far as engineering goes is likely to take uh you know a month after the fact and that's if you know hopefully that can be improved if we're if you know we have a budget that passes and we can hire more more front-end devs but uh those are my two cents on on the matter curious if uh anyone else has any thoughts or wants to chime in have some pretty strong thoughts here uh which on the one hand it's hard not to on the day of what was it a 1.65 trillion dollar budget approved uh by Congress it's hard not to think that this is a really important conversation to be had because God forbid the Beanstalk money printer somehow gets corrupted into paying for all sorts of that uh let's call it uh to put it nicely and uh to some extent the only way to prevent that from happening assuming that Beanstalk is successful is to figure out an alignment between uh funding of projects in the Beanstalk ecosystem by the Beanstalk Dow and how to how to align that so this is a very important very important thing to ultimately a solution or the Dow solution to these you know this continuous problem May and likely should continue to change over time now historically it's it and I think this this conversation needs to be looked at in the context of the data that we have so far in beanstalk's history uh it it's it's almost impossible at least from our perspective it's impossible to argue that Beanstalk would be anywhere close to where it is today in terms of uh on auction capabilities uh off chain capabilities level of decentralization without the creation and funding of both Beanstalk farms and bean sprouted by and on the one hand both of those orders didn't have had uh instructors within them allow for Theory lots of different projects to be funded by those organizations but then also there are uh the ability to distribute funds as sort of those organizations see fit and the the real question that needs to get answered is is it okay that's being posed in this case is is it okay for there to be any centralization in terms of funding or should everything happen on an individual contributor level or an individual project basis and whereas things have certainly been set up such that if a group of contributors or an individual contributor wants to get paid on a project by project basis that's that's within the realm of possibility at the same time it's really important to to acknowledge that producing really high highly sophisticated uh composable pieces of technology that involve multiple layers of the stack are ultimately almost never implemented by a single person and if the goal is really to have decentralized development really unlikely to be developed by a single party and in the case of Beanstalk if you look at something like the root Paradox launch there was a lot of uh coordination between uh Paradox a company that has nothing to do with Beanstalk root a separate company that was incubated by bean sprout but now has is a separate organization and Beanstalk Farms to ultimately get a variety of different pieces of Technology live in time and uh in a safe fashion and the the real goal and again at some point in the future things may be much more stable where only doing grants of certain things may make sense but if the goal is to have more decentralized development I feel like if anything there should be more funding of different organizations that are complementary too and somewhat orthogonal to Beanstalk farms and being Sprout and the goal is not to limit the capabilities of any one particular organization but introduce competition between the organizations right so instead of handcuffing uh contributors or groups of contributors in any way which seems uh like a like a sub-optimal solution the goal should be to introduce competition and incentives and options such that in the long run the best outcomes are achieved by ibean stock as a whole and in short that will require more funding not less funding and more willingness from the Dow to fund projects and organizations not less and in particular if the threshold to raise uh excuse me if the threshold to fund any particular project is raised so much so beyond just a quarterly bip for each organization that then those organizations can uh pay for things on with much lower thresholds than uh 50 corn per stock feel like realistically it's very hard to imagine that Beanstalk will will actually be able to fund in a continuous fashion any sort of intricate sophisticated multifaceted decentralized development and so to to that point and I think one of the the points that uh I don't want to get the name wrong uh mixolydian said was that minting these beans uh D pegs Beanstalk and to some extent there's I mean there's that's absolutely true uh in fact it is true uh right now beans are a large amount of the cell pressure uh in beans is coming from contributors uh who are getting paid in beans and there aren't that many other beans so this is a very fair criticism of the current situation but at the same time it is really important to again zoom out and look at the history of Beanstalk and recognize that Beanstalk has minted millions and millions of beans in its history to fund Beanstalk farms and bean sprout and has done so when the prices when Delta B has been positive and when it's been negative and to some extent to affect the larger macro I hate to even call it strategy because in in the context of a dow there isn't necessarily a strategy but the context of really uh sacrificing any sort of ability to coordinate at the macro level in in the spirit of saving money uh doesn't really seem to be in line with the economics of Beanstalk where fundamentally it can mint an infinite amount of beans and so again at the risk of making an argument for where we started this conversation or this answer which is uh that that the goal is not to allow for the money printer to get corrupted in such a way where Beanstalk is just minting beans to pay for all sorts of crap buy the same token particularly in its early stages it is really important to acknowledge that as long as every being that is being minted by Beanstalk to fund anything ultimately creates more demand for beans than it does uh supply of beans at the margin so net demand let's call it uh for beans as long as it creates net demand for beings it's probably money well spent by the Dow and so to some extent there is an open question as to how to prevent that from over time scaling to massive amounts that ultimately uh degrade the quality of beans as a currency but particularly in the short term where there's clearly clearly a lot of work to be done to get to a point where all of this Tech exists and runs itself and doesn't need any any development even if that's a very far away it's that that's something worth working towards and realistic to work towards at the same time it's really important to acknowledge we're not really anywhere close to that collectively and the tech that needs to get built isn't currently currently being built and the value to Beanstalk of Expediting the building of that Tech is probably way more significant by orders of magnitude than the permanent cost of that development let's say over the next two years Beanstalk spends 10 million beans on development prior to the next bull market the idea is that that I'm throwing out a number but if we run the current budget for two years it's like well it's pretty close to that the idea is Beanstalk good if that money is well spent and that's one of the reasons why the two-year you know there's no two-year budgets being proposed these are quarterly budgets so there's constant check-ins at least from our perspective in two years there should be enough Tech built such that defy can can actually happen to some extent and real economic activity can be facilitated on trustless Primitives such that the next full Market is not based on exclusively leveraging speculation but instead some real economic activity and if if we zoom out even further this really is like the Make It or Break It question for Beanstalk which is Beanstalk has demonstrated very clearly an ability to grow and an ability to grow quickly uh the the real question is is there a point at which the development the demand for beans stiffs from being speculative to utility based and that is very clearly something that is within the interest of the Dao to expedite as much as possible and prioritize the amount of demand for beans that is utility-based as opposed to speculation based and to say it again the tech is not there to actually use beans and therefore almost by definition all of the demand for beans currently is speculative and so there is some aspect of well of course Beanstalk to be willing to uh have downside volatility in the bean price in the interest of long-term sustainability that's how the system is designed in the first place so this is probably another instance of that and therefore from our perspective the question becomes assuming that there is money that can be well spent and there are things to spend it on uh then the question becomes how to create processes and procedures and permissionless ones per permissionless processes and procedures say that 10 times fast such that anyone or any group of people who have the ability and the will to make meaningful contributions to Beanstalk are able to do so and get funded by the Dow and on the one hand it's it's true that there are lots of other ways to get projects funded but it's probably particularly given market conditions uh it's probably not unreasonable to expect Beanstalk to be in the driver's seat or it or have its own destiny in a chance to so to say uh although a lot of uh metaphor they're given that Beanstalk is a piece of software that exists in a meta metaverse but nonetheless it's it's really important to acknowledge Beanstalk has the the opportunity and if you look at the the situation that it's in more likely uh the obligation to to fund uh a lot of this Tech that needs to be built so uh yeah hopefully this is helpful color on why a lot of the the the structure is the way it is currently and this is something that while we currently don't have uh much involvement in in terms of the the the microstructure between Beanstalk farms and bean sprout today it's certainly something that we did uh involve ourselves heavily in when they were initially uh created because of how important it is that anyone that wants to contribute to Beanstalk can and feel like the current setup is good but not great and again the way it could probably be greater is if there were more groups doing separate things but again that would require more funding from the down not less agreed and particularly on the front of having more groups uh working on Beanstalk you know with regards to or speaking to some of the you know friction there's been over the last couple months of community members asking Beanstalk Farms contributors you know why is it that you're spending time working on X or why is it that you're not spending time working on why uh you know I I think there's a there's a section in the budget bip under responsibilities that I think adequately addresses how we'll probably you know uh address those sorts of issues moving forward but you know I think as Publius outline there are already a number of ways to get paid to work on Beanstalk and whether that means proposing to be on the Beanstalk Farms committee uh as they mentioned proposing to Mint beans to fund and form your own organization uh there are a lot of options and we need more people working on Beanstalk that can add value uh and not the other direction all right I'll give it a I'll give it another 30 seconds or so see if uh folks wanna talk about that discussion or if they have other other topics they want to address and and bring up otherwise we can uh let's see the Cthulhu unmuted hello everyone hopefully my microphone is working well sounds great so I can't speak for long at the moment because I'm driving but I just wanted to say I'm really glad with what I've just heard in terms of this discussion on prioritizing long-term growth and the importance of paying to build and and that for being stuck to truly succeed in growth the infrastructure needs to be built out and that those those of us over at irrigation we do look forward in maybe a month or a little bit more to um bringing uh to completion a sort of a pod pricing Oracle that we would like to offer to the Beanstalk community and of course we'll we'll see if we can get a small community grant for that work but even if that's not possible we're really happy to be building on top of Beanstalk and that's all I wanted to mention thanks for the input Cthulhu all right uh well if nothing else feel free to interrupt me in our last moments if uh you have something to say but perhaps we can wrap it up there then thanks everyone for coming