I think we can get started. Thank you all for joining us today. And as a reminder, this meeting is for the Dow. Although we go through of this from being six clients, we can discuss any any topic that's being circulated. Guy, how's everything with you? Am I doing well? I'm happy to talk a little bit about what's going on in my world.

I'm working on a handful of miscellaneous things, such as wrapping up the white paper changes for the couple of open gifts at the moment. Also trying to figure out, you know, some processes for, you know, a lot of bean stock forums. Engineering is having a lot of calls with with Halliburton each other. Folks are giving various technical walkthroughs of, you know, whether it's sub graph wells, etc., and check out some processes to document and record all of those and distribute them both for onboarding purposes and just as public documentation.

Oh, Sarah has also been working on setting up a job board page, which you know, for then I have JDS for things like, you know, Fullstack engineering positions, things like that that we're going to probably link to from the site and distribute in a handful of ways once we finalize that. And then otherwise just would remind everyone of the couple of open active proposals at the moment, which is 3132 and the BFC renewal proposal and all of those and Saturday evening.

So if you had it and I had a chance to check them out, the links are in the announcements channel. Thank you. And I see that we are around 50% of the needed looks. I think that's right. So, you know, we'll see. You never know what happens. But yes, the set up to two more days. So hopefully we'll well we'll reach court on that.

Okay, Chad, how are things at your rent? Great mod. Lots going on. So. First and foremost, we've brought on a new engineer starting this week. His name's Marshall, and he'll be helping us out across the board with front end and another full stack work. So really excited to have have him on board and just continue growing the team.

There's this really great energy on the engineering front right now, lots going on. So just excited for the next couple of months. We actually right before this call completed an important merge into the Bienstock repo which is now which is now live, which does a couple of things. But first kicks off a process in which we will be reorganizing how Bienstock Farms pushes code to the surrounding the repository surrounding the Bienstock protocol as well as how other folks can can contribute to that process.

Notably, everything's going to be contained within the Bienstock repository itself, which will will make the process of coordinating upgrades across a couple of different pieces of tech, much more, much more straightforward, and also allow us to do some more sophisticated full stack testing of all the components of Bienstock. So that has actually been already been executed. It's live on the Bienstock repo currently and this is actually the first time we're mentioning this, but as a part of that, we're also open sourcing the beanstalk UI.

So the Beanstalk UI is now available to go take a look at see all the hard work that the engineers have been putting in over the last seven or eight months on that particular piece of code. And yeah, we'll be making an announcement in the coming days, sort of explaining, explaining that and talking a little bit more about it.

But, but that's now that's now live. So in terms of of other development, so as mentioned in an announcement yesterday, we've rolled out the latest version of the Beanstalk UI, which includes some pretty significant upgrades to the pod marketplace. Currently what we've done is basically relayed out the pod marketplace into its full screen format, which is sweet red Beans has been working on over the, you know, the past couple of months.

There's a lot more stuff that will continue to get updated from a UI perspective on the market. That's that's still yet to come. But we wanted to get things closer to their final form and in the process have spent a lot of time over the last couple of weeks really trying to nail some of the the data problems that have been hitting the pod market and so have got have gotten those cleaned up and also updated a lot of the, you know, the tables to view different orders and listings and market activity on the pod market now.

So a lot more a lot more fleshed out. You'll see some new features related to being able to view your active orders and listings. And so just encourage folks to go check it out, play around with it and throw us any feedback in the UI feedback channel. I think beyond that. So the focus there's there's a lot going on, but on my end, at least in particular is continuing to document the the beanstalk core protocol code as we are pushing more updates to Holborn.

So there's a number of updates in the pipeline on the audit front, notably removing the withdrawal timer as well as some of the improvements to the sunrise that we've already been audited. So we'll be working on documentation at the protocol layer for both of those upgrades as they're sort of preparing to to go out. And we'll continue extrapolating that across the rest of the code base in the coming becoming weeks to months.

And then, you know, just gearing up to to build the remainder of the infrastructure for wells. So maybe pubs can speak a little bit more to the development process in the contract side there later on in this meeting. But we're sort of gearing up to go, you know, build out the some graphs and in fact we already have the, the UI portion of things largely completed, so that'll help speed up the process.

I think a job with regards to the marketplace, are we now able to place an order based on a present course? Is this now possible? Great question. So currently we don't support the pricing curve, just yet in the UI. The reason for this is it just yeah, it there's a lot that goes into both placing the pricing curve and reading the pricing curve across all of the the different orders and listings that are active.

So this is something that's, you know, even still in design work right now. But we're you know, we'll get back to everybody about a plan in terms of rolling that out. There's a number of other things that I think we'll have to turn our attention to in the coming weeks, like getting wells wells out and, you know, safely deployed.

So happy to speak more to that. And kind of the the engineering reasoning behind not releasing it just yet. But that's the current status. Thank you, child. And I must say that the new UI in general is very refreshing and easy intuitive to use. Maybe such a means when will share some updates as well from there. How are you, sweetheart?

Hey good Lord, how are you doing? Doing all right, sir. As far as updates from my IT, I think chats are a on a bunch of these points. But the first is is basically trying to finish and wire together the full prototype for the pricing curves. So we've been sort of approaching this in a manner of generalizing the UI as much as possible.

So that's reusable for this generalized markets UI that's sort of been been mentioned a few times, but at least in the next week or so, the idea is to sort of get the pod marketplace piece of it complete so that we can start working on the being able to draw those curves directly within the UI. So that's exciting and sort of nearing completion on my end and then sort of a fast follow after that will be sort of thinking about how to kind of appropriate general up those UI components and document it in such a way that it's easy to use for or I guess extensible and in other use cases as well.

The other thing, well there are two other kind of major things that are being worked on. The first is the ability to add claim to any transaction so that UI work is completed, will be completed by the end of day today. And then at that point we'll we'll be heading that off and working with Chad and the other engineers to get it implemented.

Sort of a fast follow on to that. We'll be using the same sort of design pattern to implement the ability to add it and root to any of your transactions as well. So it's also exciting. And so keep an eye out for that. And then lastly, the component library that we've kind of been building over the last few weeks, which should serve as kind of a source of truth for all future Beanstalk UX designers is nearing completion as well.

So those are kind of the three major things happening and hoping to get, you know, most of this, at least the the claim and do X in the marketplace work over the line. This week. Thank you guys. So I see that you have posted some documentation with regards to the BSA and verification. Do you want to maybe in a minute or two tell us what's that about?

Sure. Yeah, I forgot to mention this a minute ago, but added this new page to the Beanstalk notion, which has it's just been dark money slash notion and there's a couple handful of different resources there that don't really fit in to posting on GitHub or get books. So we decided to log them here. But the link I just dropped in the Barnyard chat is has a bunch of documentation about the processes that the BCM follows for every bit.

So as per governance, you know, there's a handful of different things that BCM signers have to verify and check and given bit transactions before submitting a, a verified signed message that they've verified the given transaction. And so these walk through, you know, how to interpret diamond cut data, how to verify that, you know, bips that mint means to a particular address actually meant the correct number of beans to the correct address.

Things like that, as well as verifying that the bytecode deployed on chain is actually the same as the source code on GitHub, things like that. So, you know, feel free to check those out and if anything's unclear, feel free to shoot me questions and if there's interest, you know, for future bips, I can also post a session helping folks walk through how to verify and guide once we move Russia to permissionless governance.

This is the idea then that the same process will be used by any member to verify or that would be redundant. Unclear. I mean, I would imagine that in the early stages of re adding on chain governance that the BCM would still serve as the owner of the contract. You know, so such that there's still a group that can move quickly to upgrade bienstock in the event of a bug or a security vulnerability.

But of course the eventual, you know, the expectation would be to eventually remove that privilege from the BCM. But to answer your question, so, you know, just to imagine the scenario where we have on chain governance again, but the BCM still custody is ownership of the contract. That would just mean that, you know, execution of the bit is now permissionless, which it is not currently.

That's the one step that that isn't so currently a BCM signer has to submit a transaction to the MULTISIG and that's the only way that being stopped can be upgraded. So unclear if you know, BCM Signer should necessarily verify all the transactions that they can't prevent from being executed, if you will. Not sure on that front. Okay. Thank you.

All right, Publius, did you want to give us an update or shared some of what you're onto right now? As Chad mentioned a little bit about once? Yeah, happy to. So, you know, first off, I'm going to be publishing two blog posts within the next hopefully 24 hours. Just really final graphics, you know, one on kind of thoughts on Defi in general, kind of about, you know, summation of everything that, you know, has been learned since, you know, we initially set out on the beanstalk journey and the second one being kind of an update on kind of, you know, the public's thoughts on where beanstalk development is at and, you know, where it should head,

you know, in 2023. And on the development side, you know, been been wrapping up wells. You know, basically, you know, last night came up with a way to save a couple thousand more gaps, and it was around 6000 on pretty much every function call and clean up the interface. So, you know, Wells was about ready for audit before just wrapping up some documentation, but now going to need a couple more days to wrap up that development work, I guess kind of for context and, you know, kind of, you know, the way Wells being constructed is, you know, well, factory called the well builder plots that anyone can permissioned loosely build the well and you know

each well consist of a number of tokens a pricing function and a pump and you know all logic you know within a well needs to be able to access all three of these variables. You know, what pumps does this will have what is the president curve for the well and what are the supported tokens now given these are going to be read only variables, you know meaning that they're immutable and kind of parameters of the well that are set on contract deployment.

You know, there are, you know, several different ways to kind of store and track these on chain. You know, the first off the first way, which is the simplest and kind of the least efficient way would be to just store that in storage. When you initialize a well, you create stored storage variables where you store the tokens, the pricing function in the pump, you know, the pretty standard implementation or way to do it.

However, the problem is that, you know, now every time everyone calls the well, they have to perform, you know, load operations on these storage variables, which is 2100 gas for each 32 page slot, you know, a list of tokens and plus one slots. You know, a pump is, you know, at least two slots and well, function is at least two slots.

So say we have say there's a well with two tokens, you know, some pricing function and a single pump, you know, looking at something along the lines of seven, you know storage state in a storage and you know load operations, you know, which can be up to, you know, like gas or like 15,000 gallons an alternative way to do it, which is the way that wells are.

You know, how it's been implemented thus far is that the the well info which you know, consists of these tokens pumps and pricing function is passed into each function call as call data, and then the well has a hash of the, you know, all the parameters stored in storage and the well basically hashes the well infrastructure input by the user and compares it to the hash that's stored in the well.

So this gets this, you know, reduces the amount of gas load operations that need to be executed to one adds, you know, pretty much the only load that needs to happen is to read the well hash from storage to verify it matches the well hash input by the client. You know, hashing itself hashing the well info isn't a trivial cost operation.

I think it's, you know, also somewhere between 1 to 2000 gas. You know I think in testing using call data input from the user was around 12,000 gas you know efficiency overreading directory from storage you know have a recently happened kind of experimenting with immutable data and immutable immutability that is data that you can set in a constructor that never changes and gets compiled into the bytecode.

So reading immutable data doesn't actually cost an s load operation, but it can only be set at the time of contract deployment. You know, kind of where we're using I mean, difficult is, you know, immutable data currently only supports, you know, single slot types, for instance, of bytes 32 or a unit. And it becomes a problem when you want more site memory, for instance, a list of tokens or a list of bytes, you know, both the well function and the pump.

You know, use an arbitrary length of bytes, you know, variable. And, you know, the tokens obviously are a list of addresses. And so, you know, there are, you know, having for meetings and work around some ways to work around this and that are ultimately going to be very ugly. And it's going to, you know, going to impose an upper bound limitation on kind of the size of things which can be set to kind of be arbitrarily large.

But, you know, overall, you know, early testing shows that, you know, implementing, you know, storing the parameters that only as immutable storage variables as opposed to kind of having the client input, the the the call data or that, you know, it's a 6000 about a 6000 gas efficiency improvement and, you know, an 18,000 gas efficiency improvement over directly, you know, using normal storage also, you know, it it makes it so that the client doesn't actually have to provide.

Well, info, you know, in each function call, which, you know, kind of what's going to be a problem or get a little messy when it came to, you know, being stuck actually reading information from the wells as it would have. They know the information about, you know what what in a well in order to make you know, in order to read from it.

So you know, I think, you know, a lot of good progress there and, you know, really happy about the state of things. I think, you know, a swath is somewhere like 40 to 50000 gas right now before, you know, without a pump, which is pretty efficient, you know, kind of beyond that, You know, I had a great discussion with some, you know, developers in the Bienstock community the other day about how to move forward in, you know, sightline dynamic, you know, stock per BTV system.

Currently, as everyone knows, the amount of seats for PDB is fixed and you know, the stock proceed as the crude stock proceed per season is also fixed. So trying to come up with a way to kind of, you know, transition over to a system in which a dynamic, you know, growing stock per PDB, per season variable could be implemented while minimizing demand and things like backwards compatibility and, you know, migration in overall code changes.

So a lot of great work there. So thank you for everyone who participated in that. And that, you know, I look forward to more discussions going forward. You know, I think that's about it. Thank you for this. And one one is there like a timeline that you think, well, is this targeting, let's say? I mean, the goal was to put it into orbit.

You know, it was pretty much ready for audit pending some final documentation. And, you know, now that will probably be pushed back a few days. But, you know, ultimately, it's really hard to speak timelines even when code is done because, you know, things have to go through an audit process, probably need to leave things open and some sort of bug bounty program for a few weeks as well, You know, So it's really hard to speak timelines, but, you know, hopefully we'll look to having it some time next week, but seeing things when it's kick off as scheduled.

Yeah, it seems like everything else that we were seeing or sprinting towards the finish line. Yeah, I mean, there's still quite a lot of work to be done, you know, kind of the piece of code that's completed right now is only the core, well, functionality that's going to need to be a significant amount of research and development around, you know, kind of what the dust pump is.

You know, as has been discussed many times, you know, I'm being stock kind of community calls, you know, kind of there is a lot of difficulty with on chain oracles and that's a problem that you know like Google has is very passionate about and very interested in trying to create the best on chain or call calling the go with well was to create a system such that you know that would set you know, kind of the the protocol up for the most success in terms of implementing these oracles.

You know, I think there's a pretty good design and structure of what, you know, a good a good, you know, first attempt at manipulation. For instance, this Oracle is but, you know, there's probably going to need to be some kind of simulations or, you know, more technical data driven analysis of, you know, how different, you know, types of, you know, manipulation attacks would affect said Oracle.

So, you know, there's still some work that needs to be done there, you know, other than not just plugging Bienstock into the wells, which shouldn't be too hard. A lot of that work has already been done, but, you know, it needs to be wrapped up as well. So, you know, overall, it's it's a quite significant overhaul. But, you know, a majority of the work is done right.

Thank you for work on this. And just want to give a very quick update. Sorry if there's a lot of noise on this end. First off, want to just apologize for not having class. The past few weeks I've been trying really hard to finish the two posts that are hopefully going out in the next 24 hours or less.

It may unfortunately be that next class. I also cannot attend, but after that it be back to normal. But very sorry about that. I just wanted to briefly try to answer Ty Katie's question from a couple weeks ago. Now that has just been left unanswered, which is suboptimal to say the least. And so maybe just the status of.

All right, let me see if I can find the question real quick or if anyone else finds it first and wants to read it. I believe the question maybe to summarize was how will Beanstalk and the Silo specifically treat LP LP deposits? If the the LP token is pricing the assets along some arbitrary curve and in store. The the current thinking is that the the entire silo system has been and likely should continue to run on being denominated value.

And so in the instance where there is USD put into a well to buy beans at certain prices, the BD function for that LP token would take into account the bid prices priced in beans of the well, such that if the the well is only willing to buy beans at $0.10, let's call it, then it should only consider the the US DFC at $0.10 on the dollar effectively.

So in doing that the system would allow people to place arbitrary orders to buy and sell beans and ultimately still be able to price it. In terms of BTV. And based on the practical BTB that would be realized if the order was filled. So not sure if that was the most coherent way to explain it, but hopefully that offers some color on the issue On how at least we've been thinking about this.

And I linked the message to the question and the bar in your chair. Okay.

The floor is now open to anyone who wants to maybe chime in or ask ask a question or discuss any any other topics. So we'll give it or leave it for a few minutes and see if anyone, you know need to speak up or typist on the bar in our chat. If you prefer not to prefer that over it, over speaking.

Okay. With that, I think we can conclude this meeting. Thank you all for joining us today and we'll see you next week.