• Recordings
• Meeting Notes
• Conclusions
• Pod Marketplace Context
• Benefits of Seaport/Tractor
• Pod Orders for Tokens
• Which pairs make sense?
• Other Markets
• Does it make sense to have a marketplace that trades deposits before Stalk is liquid?
• Further Questions
• Priorities
• Transcript

Recordings

Meeting Notes

Conclusions

• Next steps are to implement Silo Deposits and Plots as ERC-1155s.
• The first market to be built should allow the exchange of Silo Deposits and Plots, with the ability to trade against ERC-20s added later.
• Stalk per BDV will not be included at first, due to the complexities involved.
• Stalk and Seeds are not required to be liquid at first, but can be added later.

Pod Marketplace Context

• There is some inefficiency in the secondary market for Beanstalk debt.
• V1 of the Pod Marketplace facilitated the sale of Plots for Beans, which was not previously possible because Pods do not implement any ERC standard and thus there was no way to exchange Pods in a permissionless setting.
• You could list a Plot for a given amount of Beans or place an order with Beans for some Pods.
• Because Pods are ordered, an order includes a parameter for place in line.
• Statically priced orders result in some inefficiency.
• V2 supported polynomial functions, implementing a pricing curve - price is a function of place in line. Currently there is no UI supporting it.
• V3 could offer Silo Deposits or Fertilizer for Pods
• Placing orders with Deposits has the advantage that the user wouldn't have to forfeit all the Stalk and potential Bean seignorage accrued while the Beans are in an order.
• Something like Tractor or Seaport would provide the ability to place orders for arbitrary assets against arbitrary assets, such as if Deposits or Pods were to be implemented as ERC-1155s.
• The orders could still be a function of place in line as with V2, preserving those efficiency gains.

Benefits of Seaport/Tractor

• Tractor and Seaport facilitate off-chain orders which can be significantly more complex with less on-chain development, but which are particularly complicated to support at the UI level. There are a lot of open questions around creating a user interface that can support whatever pairs are made available. The difficulty is underscored by the fact that there is still no V2 UI.
• Part of this conversation is an attempt to prioritize markets that could be built on Tractor/Seaport. Which exchanges are in Beanstalk's interest to facilitate?
• There may be some value in offering many different pairs, but that will fragment liquidity and require a very sophisticated aggregator.
• An advantage of Tractor/Seaport is that you can have asynchronous orders created and stored off-chain, and you can have the execution of an order affect the status of other orders. This makes liquidity much more efficient, but also introduces significant complexity at the indexer and UI level.

Pod Orders for Tokens

• Already possible on the back end.
• You can create one massive order that will accept a variety of tokens and references an oracle that is included in the order, and allow a user to buy with any combination of tokens.
• Encoding one large order is harder for the indexer to process, because it would have to assess each asset and calculate the price of each using some oracle.
• An alternative would be to create multiple different orders, one each for all the acceptable currencies. The downside to that is the from the user experience perspective, where the user would have to sign to authorize multiple transactions. With Tractor, it may be possible to sign a list of orders at once, which would improve the user experience.
• In either case, it's mostly already possible to do either on the back end, the more significant challenges are the indexer and UI. The less custom functionality the better in that respect. The indexer will need to be able to code every single function selector that's used, so minimizing the set of possibilities makes the indexing task simpler.
• Users might desire to denominate their desired price in stable currency, so you'd have to specify some oracle price. This is ultimately one of the biggest issues as you support multiple tokens.
• The UI should be able to make a determination which order offers the best price in practice given the starting currency. As much as possible should be abstracted away from the user. Especially if used in combination with Pipeline, the possibilities can be infinite, so narrowing the scope to just a few currencies would probably make it easier overall.
• It's much more straightforward for a seller to create a listing that specifies which currency he is accepting and have the buyer perform the conversion as part of the sale, versus encoding the conversion as part of the sell order. It's a matter of how complex to make things from an SDK/UI perspective. The goal is obviously to enable any user to fill any open order in one transaction.

Which pairs make sense?

• Which pairs would be economically beneficial to Beanstalk?
• Deposited Beans for Pods makes a lot of sense intuitively. Harder to see how a seller accepting only USDC benefits Beanstalk directly.
• The more assets that are accepted, the more liquid Pods become.
• For simplicity, it might make sense to start with just Beans and then expand to whitelisted assets (assets that have implicit value to Beanstalk).
• From a UI perspective, the cost of adding tradeable assets depends largely on how complicated the UI will be to begin with. A simple UI can accommodate more assets easily than a more involved UI.
• Different asset types (ERC-20/721/1155) will greatly increase the complexity of the UI, so constraining those would make a lot of sense.
• Implementing Bean deposits and Pods as ERC-1155 may make marketplaces easier to support rather than having to develop two new interfaces for one that talks to deposits and one that talks to Pods.
• Supporting 1155s against 1155s from a UI perspective will be difficult. Even 1155s to arbitrary 20s is a lot easier than 1155s to 1155s.
• A simple interface for exchanging Deposits and Pods as ERC-1155s can be done. But one that enables efficient pricing will be much more difficult. Pods change in value depending on place in line, and Deposits differ based on season. It's not clear how to display that in a digestible way to let somebody discover the right pricing.
• When both assets are semi-fungible, it may inherently fragment liquidity. Ideally, Deposits themselves could be abstracted and flattened such that orders can start being only two dimensional on the Deposit side. The way to get around this fragmentation might be through Stalk liquidity.
• It's important for the BDV of Silo Deposits and the Bean ERC-20 token to be highly interchangeable. There are numerous ways to do this from an interface perspective. It's desirable to be able abstract away as much as possible. The improvements to the Pod Marketplace are going to open up a lot of liquidity in the form of Bean and Bean-3CRV Deposits, and users with Beans should be able to access all of that liquidity.
• Seems like being able to trade Deposits for Pods is complicated but obviously economically beneficial to Beanstalk.
• You probably have to have Stalk liquidity before the market can become particularly efficient or abstract from a user perspective.
• You could in theory have a Deposits for Pods marketplace with no consideration of Stalk whatsoever, which would be a minor upgrade from the current Pod marketplace, but not up to par with the full functionality.
• There's a lot of unanswered questions around how to facilitate the most efficient and abstract interaction with the different axes of Deposits.

Other Markets

• In addition to Pods and Deposits, some sort of Bean Deposit future where there is forward looking expected yield priced into current BDV is an interesting Market to consider.
• Probably makes sense to have full spot markets before moving to derivatives.
• Fertilizer markets are worth considering
• In theory when Stalk is liquid there will be the Deposits, which will be 1155 and are effectively the right to burn a certain amount of Stalk and Seeds with the Deposit to receive the underlying, an ERC-20 Stalk, and then some sort of semi-fungible Seed where the Seeds are yielding Stalk based on the underlying asset that is deposited.
• There is some work being done to further abstract the concept of Seeds, but at least with regards to Stalk and Deposits, there should be the opportunity to exchange Asset A for Stalk or Asset A for Deposits and those are distinct once you have Stalk liquid.

Does it make sense to have a marketplace that trades deposits before Stalk is liquid?

• The major use case for Deposits will be people willing to buy Pods with a Deposit, and the Deposits used will be known ahead of time. So it does allow for users to make decisions about how to value the Grown Stalk. The smart contract won't necessarily need to make assumptions about the Grown Stalk.
• There might be value in the short term for people to be able to buy and sell Unripe Deposits on the marketplace.
• These markets aren't going to be fully efficient until Stalk is liquid, but there is likely still plenty of utility to be realized by enabling users to create buy orders for Plots with Deposits.
• Once deposits implement 1155, they can also be made available on Opensea, just without the advantage of any sort of pricing function or the ability to use Bean, and users will have to pay fees.

Further Questions

• Facilitating Deposits on the marketplace even just as ERC-20s (including Unripe assets), and potentially also Deposits for Pods, seems to be the highest leverage.
• After that the question is around Stalk and potentially Seed liquidity and how that fits into everything.
• Should Stalk be divided into governance tokens and seignorage/interest tokens? What's the best way to facilitate efficient markets around Beanstalk?
• How does everything fit into the overall timeline? Which markets should roll out first?
• How does the liquidity around Stalk and Seeds affect the creation of markets for Deposits and does one need to happen before the other?

Priorities

• One interesting angle is that before Stalk is liquid, Stalk per BDV is really a bonus because the Deposits come with the Stalk. Whereas after Stalk is liquid, it is really a penalty because the Deposits do not necessarily come with the Stalk. That leads to some additional complexity on the UI front.
• It might be necessary to develop a market that facilitates the transfer of Deposits both with and without Stalk and Seeds, depending on user preference.
• Starting with 1155 Deposits and then later adding liquid Stalk would not change much from a UI perspective, but it would require changes to the order structure and aggregation.
• It may make less sense to start thinking about Stalk liquidity because it adds another degree of dimensionality, which is pretty tricky to solve from a UX standpoint. If the immediate goal is to be able to exchange Deposits, it might be a good idea to focus on that and put Stalk liquidity on the back burner until it's more clear that the market requires it.
• In addition, the development of liquid Stalk is quite complex and will probably be a multi-month endeavor from the point that development starts in earnest.
• So in the short or medium term the starting point should just be around a basic implementation of Deposits without Stalk and Seed liquidity as an 1155. This could be done in parallel with the development of Pods as 1155.
• The consensus seems to be to start with a Deposit for Pod marketplace and then add the Stalk functionality after the initial launch of the market.
• None of this needs to include the complexity of Stalk for BDV, but that can ultimately be added at the UI level at some point.

Transcript

GM farmers. I think that for today, a lot of what we wanted to cover is in the context of markets that we should be building on top of Bienstock and hopefully getting as specific as possible to sort of better inform whether we should be using existing tech like sea port. I think Brian has been doing some research on that end versus to what extent, you know, bespoke software like tractor is necessary to be built, audited, etc. in order to support all these markets that we do want to build on top of Bienstock.

So perhaps publishers think it would be helpful if you help us get into the weeds a bit on what all the things that you think we should be covering today. BE You want to kick us off or you want me to go ahead. All right. So Bienstock has some base assets at the moment. It has beens which are in C 20 token pods which don't adhere or don't implement any RC standard at the moment.

Fertilizer, which is an 1155 token and then deposits which also do not adhere to any industry standards at the moment. And as of the last down call, there was a lot of discussion around the implementation of pods and deposits as 1155 tokens. And in short, the question becomes independent of whether pods and deposits are implemented as 1155 tokens.

There's all of this exchange, let's call it software being and there are smart contracts being implemented to facilitate the exchange of various assets. And some of the stuff like Wells is starting with just ERC 20 tokens but GRAFTER slash sea port, the latest version of sea port, which Fucci made us aware of on one of the recent dev calls, can already support effectively arbitrary orders, or at least in theory should be able to support arbitrary orders for 1155 720 ones and ERC 20.

And so in short, the the main topic of conversation and it probably is helpful to get into today is around which of the markets around any of the beanstalk native assets. It is most helpful to facilitate in a market forming on top of a dex forming on top of for a given assets. And so what that what we'd like to cover today is running through some of the different options for markets and what implementing those markets might look like and then the potential trade offs to be in stock and the trade offs around developing any of those markets in the particular order and then hopefully trying to get some clarity on which are the markets

that make the most sense to start working on. So that's maybe the starting point or maybe just pause to see if people have any questions or thoughts to begin with. And then otherwise we can start talking about more specific market implementations worth considering. Not a specific question, but on this and would like to better understand, you know, given that the pod market is the first market that we built on Beanstalk would like to better understand in what ways it'd be made better, more efficient, etc., by the use of something like sea, port or charter.

So if we start with the pod marketplace, which is where Beanstalk Farms effectively started, the there was and to some extent continues to be some inefficiency in the secondary market for beanstalk debt. And because pods are not a do not implement any standard in particular, there was no way to exchange pods in a permissionless setting. So the pod marketplace be one facilitated the exchange of pods through the beanstalk contract in exchange for beans.

So you could list a plot for a given amount of beans. And similarly you could place an order with beans for some pods. And because pods are ordered, all of the orders to buy or sell could could include some parameter around the place in line. So an order would be in order to buy pods up to a certain place in line at a given price.

And similarly, an offer to sell would be to sell a plot at a price until the vegetable index reached a certain amount, and what that facilitated was statically priced orders denominated in beans per pod. Now the there's an obvious inefficiency around static orders because in theory, if what you're willing to pay for a pod at one point in the line is not the same price as what you'd be willing to pay for a pod at another point in the line.

And so in practice, in order to create any sort of dynamic curve in the pod marketplace, you'd have to place a significant amount of orders, which is very expensive. So pod marketplace would be two, which was largely implemented by multisite supported polynomial functions such that you could place an order for a set of pods or list a plot along some pricing curve where the price in terms of beans per pod is a function of the place in line.

And that is a potentially very significant improvement to the efficiency of the pod marketplace. But as of now there is no UI to support that and so it's not particularly used and therefore the economic efficiency around or the benefits potentially gained from the pod marketplace be to have not necessarily been real. Now to answer your question, die around what av3 might look like and how that fits into the conversation today, and what are the additional benefits you could get from a V3 implemented on C part is that you could now potentially offer deposits for pods or fertilizer for pods.

I think deposits for pods is the most interesting one, certainly because whereas currently in order to place an order for pods on V1 or V2, the marketplace only accept beans. And the concept is that therefore you need to forfeit all of all of the stock and potential being seigniorage accrued while the beans are in an order for the pods.

And there's obviously some inefficiency there around creating liquidity. So the concept of a V3 and something that is introduced by something like tractor slash seaport is the ability to basically bid or place orders for arbitrary assets against arbitrary assets. So in this case it could be deposits implemented as an 1155 for pods implemented as an 1155, and that order could be similar to how V2 works, be a function of the place in line.

But the assets themselves can change, so you can do away with the economic inefficiency around around only being able to offer billions in orders. Now this sort of lends itself to the larger conversation, which is Tractor Seaport facilitate off chain orders, which can be significantly more complex in nature with less on chain development, but are particularly complicated to support at the UI level.

And so there is really an explicit conversation around what what markets, assuming that there's going to be a pod marketplace. V3 implemented on Tractor Seaport, there's a lot of open questions around creating a user interface around that that can support whatever the the pair is that the V3 is supposed to highlight or pairs, which is going to be a significant thanks.

And it's highlighted by the fact that there still isn't a V2 UI. So the concept is part of the point of having this conversation is around trying to decide some sort of tier or list around priority for markets that could be built on tractor or tractor seaport. And again, still just not sure which whether sea port ultimately has all the functionality functionality necessary.

So still not sure whether it'll be tractors, seaport, port, but the concept is figuring out which are the the products, the the actual exchanges that it is in the interest of being to facilitate is really the goal of today's call. To that to that answer your question, guys, sorry for the long winded answer. It did. That was great.

So I guess one thing one question that came to mind is I assume like at the contract level, Tractor or Seaport would not prevent someone from ordering pods with a shit coin. But your point is that the UI level, you know, when you want to, you know, facilitates, you know, a particular user experience like it obviously would not be worthwhile to support making orders with that token and it would be worthwhile potentially making the ability to create orders with deposited beans, for example.

Is that sort of what you're getting at as a should coin pod pair, let's call it, and minimal benefit to bean stock per say. So yeah, that is explicitly the thing we're talking about is what is the, what are the things worth. You know, building a trading pair is for exchange Paris for that will help the beanstalk ecosystem or help Beanstalk explicitly.

So what are the what are the exchanges using Tractor seaport that are most important or most beneficial to beanstalk for us to collectively try to implement and just to just to understand when it comes to development work, like if we're talking about building a pod market such that you can order pods with deposited beans, like what would be the additional development cost of adding support for ordering pods with usdc, for example, Is it nothing?

Is it some amount? Just asking because I have no idea. Or is all the work in your mind at that point? At the UI level, I think Chad might be better suited to comment on the complexity of supporting deposits for pods versus like call it a set of five assets for pods. But I think that from an economic perspective, separate from a technical perspective that will yield to chat in just a second on that front.

From an economics perspective, there is some sense of value in having multiple errors, but there still being some fragmentation of liquidity. And I guess in theory, if you have a great aggregator for all this stuff, then for even for like a normal market participant or a taker, that it shouldn't really harm them, that the liquidity is fragmented, but that that would add a significant amount of complexity.

The under the UI level per se, although there will over time, there is probably some need for a complex aggregator to be implemented, but that probably is, you know, that's getting significantly ahead of ourselves here. But curious for what other side with regards to the markets, I think stock marketplace or the deposit stock marketplace, fertilizer and then the marketplace, that's your tier list mod?

I think so, yeah. Because all of these are secondary markets for Beanstalk or Beanstalk, you know, assets. So I think those those would be the first ones or the low hanging fruit. It makes just like Beanstalk as a little bit more liquid. And what do you think are the pair of that should be support? So I think my understanding is that the main advantage by making these markets more liquid is because of the reduced transaction fees in creating the offers.

Correct. So we can expect people to create more offers a lot more cheaper and that would in theory make the markets more liquid, as my understanding, correct. Not sure I'm following you there. So my understanding is that, you know, first off, you know, tractor and opensea allow for kind of, you know, asynchronous order creation in order indexing, which means that the orders don't necessarily have to be stored on main.

And, you know, this is just one of the byproducts of, you know, something like tractor or seaport. You know, it should also be mentioned that, you know, it makes it very easy to create one of and orders where you can, you know, say create five or six different orders and, you know, basically have some you know, all of these orders can be created cheaply, potentially free, depending on the indexing solution.

And then, you know, say someone executes one of them and four, it it can automatically have the other orders be canceled. So the system allows for very modular, you know, kind of order creation and, you know, kind of, you know, you know, very easy to make kind of order is dynamic in that sense. But kind of every single complication made at the order level, you know, is going to be is going to introduce, you know, more complexity at the indexers slash UI level.

As you know, every single kind of, you know, bell or whistle that might be added to an order ultimately needs to be deciphered at some point. And that's, you know, both deciphered from a this is some arbitrary abstract data perspective. You know, the indexer needs to now create some sort of structure to that. And then at the UI level, it needs to be able to kind of display the structured data.

So it's like with with new additions, like with new markets comes complexity at the indexer and UI level and you know, ultimately kind of, you know, it's, it's kind of, you know, given that, you know, I think you picked a great starting place talking about parts deposits and fertilizer, you know, but ultimately they'll need to be some sort of consideration made around, you know, what is the scope of you know, kind of everything that you can you can pair against pods.

Now, it should be noted that, you know, say I'm willing to sell my pods for beans. I mean, I guess, like, you know, I want I want to sell my pods for USD UCC, you know, there are kind of two options here. You know, option one is someone just sells UCC into my apply option to if someone sells beans into my plot and then, you know, the beans are kind of automatically dumped into UCC.

Now that that can happen as a part of the order fulfillment. Or it could happen kind of after the fact as I as a user, you know, want to sell, you know, there are plenty of ways we can make this complicated, but I think, you know, it's important to have a strong basis on what the you know, what the community seems to agree, as, you know, kind of the minimum viable implementation that still allows for economic efficiency.

Do you want to comment substantively on the concept of having orders for pods in a variety of different tokens and the additional workload that would add for a single market? Yeah. I mean, you know, not going to speak on you know, not going to speak in detail on the on the UI level as quite frankly, you know, that is in my area of expertise, you know, on the back end level, you know, it's not necessarily too difficult.

You know, I mean, it's already possible, right? You create five different orders and, you know, potentially or I can you know, or you can either create one massive order where it's like, I'm willing to trade pods for UCC or beans or Bitcoin or ether or die. And so long as the user pays me some amount of any, you know, or some combination of those tokens evaluated against some oracle that I also include in the order, you know, basically willing to sell my plot and you know, kind of an alternative to that would be to create five different orders where it's like now I have an order to sell this plot for UCC in order to

sell it for being in order to sell it to Ethan or someone for Bitcoin. And, you know, kind of there's some sort of contract that's submitting the total amount of pods sold. And I, you know, or there's just, you know, or, you know, I'm willing to sell the whole point at which case it's like if I no longer have the plot and then if these orders are valid, you know, from, from an indexing perspective, you know, or I guess the downside to the second the second solution is that, you know, it requires a signature for each different order.

You know, this is only really a hinderance at the you at the user experience level where it's like if I'm creating five different orders, I now have the same using a trezor you know, I know how to sign five different things on my Trezor I have to verify that I'm signing something legitimate. That's what I expected. You know, I think with tractor, if the decision is made to use tractor, you know, there is potential optionality for the ability to sign a list of orders at one time.

You know, we can, you know, improve the user experience that way you know, now now. But, you know, kind of the point is from the back end, there are multiple ways to do it. The back end already kind of supports it with different trade offs, both, you know, gas efficiency of executing for filling the order and, you know, kind of how the user experience for that sort of order creation goes.

But kind of what's most substantive is, you know, kind of the effect on indexing. You know, it's quite clear that kind of, you know, the UI market and the index are the two the two bigger coding challenge are the two bigger pieces of technology that need to be built here. And from the index or level, you know, it seems like the less custom functionality, the better meaning, you know, every the indexer will somehow need to be able to decode every single function selector that's used.

So, you know, kind of from the index or perspective minimizing kind of the, the, the, you know, the, the set of possible functions selectors, you know, makes the indexing task simpler. Now getting back to the idea of you want to encode one large order that says beans or usdc or ether or etc., you know, that makes it a lot harder for the indexer to process as now it needs to do some like or condition where it's accessing all five of them.

It needs to have like some conditional oracle variable where it's like calculating the price of being. And if bitcoin UCC all simultaneously verses if it individually supports the ability to do, you know, trade, you know you cannot apply usdc pair the plot BTC, pair the plot usdc pair, etc. It makes this question, you know, it makes it simpler from the perspective of, you know, that logic already exists.

Let's just add support for a new token type. Now, I guess one important consideration to make, especially as you know, the you know, we're talking about non stable tokens, for instance, someone is willing to buy, you know, pods with ether. You know, my my guess would be that, you know, there's some desire to denominate the price they're willing to pay for the pods or that they want to have the pods paid for in stable currency.

And it's like if I'm saying you know, I want to buy or sell you know, I want to sell these pods into Ethe. Now it's like you have to specify some Oracle price from this perspective. Like, like there needs to be some oracle, some ether usdc Oracle on chain that is used to calculate the payment that the user ultimately has to pay for.

Like that's where it starts to get complex as now it's like, you know, the EUA and we need to evaluate some oracle for this given order and you know think if it can be kind of generally you know again getting to the point of the indexer problem, you know, the indexer can be expanded to include more function selectors as time goes on.

But when really thinking about a minimum viable set of function selectors, you know, kind of getting into the Oracle territory might be getting complicated, you know. But, you know, I guess it's kind of inevitable if multiple tokens are to be supported, you know, because from a UI perspective, if I only have beans and someone has an open order that they're willing to sell pods only for USD seed, you know, there's a potential route where I sell my beans into UCC and buy the pods.

And if that is cheaper than the cheapest, you know, then the cheapest order to sell a plot similar in caliber to that one. And beans, then, you know, it should kind of, you know, the UI needs to somehow abstract away the fact that the sell from beans to usdc is happening, you know. So ultimately it's like this can get as complex as is desired and you know, used in combination with pipeline.

You know, I think the possibilities are quite infinite. So maybe, you know, kind of perhaps, you know, narrowing the scope to at most a few currencies would probably make it an easier task. I mean, narrowing the scope to just beans will make it probably easier overall, especially from the UI perspective as now it doesn't need to, you know, potentially denominate things in multiple different currencies.

Yeah. I mean, you know, those are kind of my thoughts on, on, on the topic. But you know, curious to hear kind of, you know, how important people might think it is for, you know, you know, those I mean, because it's like I guess, you know, from the fillers perspective, right. If I'm for filling your order, let's say you're buying buying a plot for beans and I as a user want USD C it's very easy for me to, you know, fulfill that transaction and sell or fulfill that order and sell my beans into USD C in the same transaction.

So, you know, the fact that the offer was only created to be denominated in beans isn't necessarily a problem because through pipeline you can just sell before or after, you know, for some liquidity fee and extra gas costs. Now if I'm the order creator, let's say I'm selling a plot and in order for beans, you know, there doesn't seem to be any natural synchronous way to, you know, automatically sell once my order is fulfilled.

I mean and think you know, that functionality would either warrant, you know, kind of the actual selling of beans into usdc in the order itself where it's like, you know, my order is willing to create the sell order. I mean, I guess it would probably make sense for the person creating the order to denominate the order in the currency they want.

And it's kind of up to the for filler to figure out the path to see how they actually get that currency. So if I want USD C you know, kind of if I create the order to be fulfilled in being, you know, given, you know, I'm not the one creating the transaction, I'm not going to have control over execution flow to have it automatically sell into being when the orders fulfilled, meaning I'm probably going to be left with being unless that sell is encoded in the order.

But encoding a cell in an order seems like quite overly complicated, whereas from my perspective I'm probably better off just saying I want USD C and leaving it up to the profiler to perform the sale of beans into the UCC and they just send me the UCC. So it's like from a perspective of, you know, trying to match the output, it seems like you probably make sense to leave that up to the for filler.

But you know, ultimately, like, you know, gets back to the question of like, you know, I guess how complex that is from, from an SDK UI perspective to build out functionality for situations like that where, you know, we obviously want every user to be able to fulfill any open order in one transaction. So it's like to implement some sort of, you know, sell in for a fill atomically, you know, would be very helpful from that perspective.

So to me, I think that's very helpful context. On the complexity of the development itself. Maybe then to talk about, you know, what pairs makes sense, it, it would make sense to first talk about, which would be economically beneficial to be stock. I mean, the deposited beans for pods, you know, seems like low hanging fruit and makes makes a lot of sense intuitively, I guess, if you like in the case of selling plots for us.

DC, I guess I could see a couple different ways of explaining it where, you know, maybe that person only wants the Usdc add one wouldn't sell otherwise, but it's hard to see how that benefits beanstalk directly. I don't know what what what do people think is the right way to think about that in terms of what pairs would benefit Beanstalk The the more accepted assets, the more liquid the the asset pods become.

I think maybe for some there's just beans and if we want to expand it, then whitelisted assets. So whatever gets whitelisted is also one of the assets that can be used that I think more or less this would capture the markets would interest of them. When you say whitelisted assets, do you mean deposits? Yeah, like for now it's like speak of once we have been recording different than like being recurve LP tokens in the silo.

Right. Those are different assets. So you're suggesting that we do three curve. Are you suggesting that we do being three curve? LP tokens that are deposited in the silo or are you suggesting being three curve LP tokens, which is actually what's on the waitlist. No, like the asset that three curve itself. Yes. So you can, you know, you can put offers of course offer them one if there's whitelisted.

But when you say is whitelisted, what does that mean. Like now we have a proposal pool in the silo but the whitelisting is technically around the being eith LP token. Yeah, I understand my, my thinking is just like implicitly, if we're whitelisting a certain asset, then we value that asset. I understand the technicality that sort of whitelisting an LP token not on the asset itself, but but when we're doing that, my thinking is that this automatically will means that to a certain extent we are valuing that asset and hence we may also accept the took place.

Orders ought to be allowed to be used to place orders. This is my thinking, but like there is no science behind that. Do you have thoughts on the complexity of the number of assets that would be supported against pods and in particular, you know, 20 versus 30 fives? I think a lot of it comes down to how the design side shakes out there.

But I you know, I think that to get a good technical understanding of what it's kind of what like what does the UI end up actually looking like for trading both of those against pods. Can you help us understand why that is important to like an index immediately after? Well, it's hard to to give an accurate measurement here.

All I can say, all I can say is that I think, you know, for example, like we've talked a lot in the past about, you know, various forms of of charts or sort of like general interfaces to to trade between different assets if that kind of interface applies in this case, I think that may bump up the development time pretty significantly if there's some sort of, you know, fusion across multiple assets like earlier you were talking about aggregation.

If there's UI side aggregation that might do that, I think, you know, very simply just displaying the order book is probably not that complicated from a UI perspective, and it really comes down to what the indexing looks like. And I think the indexing question is downstream of the tractor versus sea port and angle. To some extent though, it seems like from our preliminary research that the that, you know, the architecture is somewhat the same or at least in the same ballpark.

So it seems like at the moment you don't have strong opinions on how additional pairs against a given beanstalk native asset adds to the complexity. And it seems more like how complex the UI is going to be is going to be the main determinant thereof. Is that correct? I think that's right, though I would caveat that different set types see 20 versus 721 versus 1155 probably greatly increases the complexity.

So I think that constraining those would make a lot of sense. I in the case of pods, I think, you know, we've talked about being deposits is kind of the asset to support. There's an active discussion going on right now about making bean deposits I.R.S. 1155 compatible, in which case, you know, we might able to support 1155 more generally by focusing on that as the, you know, the other side of the market from pods, we've also talked about making pods the RC 1155 compatible.

So, you know, that's an example of where if we do those changes which obviously have their own, you know, their own requirements and relate more to the architecture on the beanstalk side, as it stands, it would probably be easier to support or to develop the market rather than having to develop two new interfaces for, you know, one that talks to deposits and one that talks to pods.

So with all that said, do people have which bits are a priority? I just want to add to what Chad was saying. I think supporting 1155 against 1150 fives just totally from a user interface perspective will be difficult. I think. 1155 to twenties will be an even arbitrary twenties is a lot easier than doing 1155 against 1150 fives.

So that's not, you know, an opinion on what I think is higher priority. Just sort of adding to to Chad's point there a related question. Once stock and seeds are liquid, what is it about deposits or being deposits or either that are semi fungible at that point? The it's the obligation to be able to burn a certain amount of seed in stock in exchange for the underlying token makes sense.

And and I guess on this topic of what assets to support like for for from my perspective you know one of the big you know one of the very important, you know, things to take into consideration here is you know that you know kind of these order books enabled deposits to be used. And I think it's very important to make to get, you know, to to make the like to make the, you know, the BTV of a siloed deposit and the being ere see 20 token very interchangeable.

And again, there are numerous ways to do this from an interest based perspective, But you know, kind of the goal is to, you know, one of the one of or one thing that would really benefit bienstock is to be able to, you know, kind of abstract, you know, away deposits from from the orders. And I guess that's not quite clear what that means.

But, you know, it's it seems important to be able to enable the use of deposits. And, you know, they're being ERC 20 token interchange ably such that, you know, if I have been deposits and I'm creating orders, you know, if if I'm creating orders to buy plots, that it's very easy for the user selling in to me to be able to sell that plot, you know, kind of into beans or vice versa, where, you know, if I'm willing to buy a plot, whether I buy the plot with beans or deposits, it doesn't really matter.

And you know, the end user is able to get which asset they prefer of the to the actual raw deposit, meaning it withdraws and transaction beans or, you know, if if the goal is to transact in beans or if the goal to transacting deposits. And at that point it's like you know it probably just transfers the deposit or deposits the beans and you know, uses that deposit to buy the plot or something.

But from this perspective, it's like, you know, the the pod marketplace is going to open up a lot of liquidity in the form of, you know, now being deposits and being three curve deposits in the silo can be used pretty frictionless, Ali, in order to to buy pods or buy fertilizer and you know, making sure that users, you know, who are using the pod marketplace with beans are able to access all of the liquidity that is existing in the form of, you know, deposits you know, is is quite beneficial.

So one want to dig a little bit more into three red beans was talking about around the complexity of supporting 1155 against 1150 fives. Obviously given the somewhat arbitrary nature of 1155, it'll be hard to get to a totally generalized implementation at the UI level. But what about like starting with deposits for pods, pair and then, you know, sort of working backwards from there to add potentially other?

1155 if necessary, but you know, feel like feel like deposits in pods are economically a major step up from other like call it early twenties against pods and therefore curious for your thoughts on how complicated that makes it and how that factors into which markets to build first. Yeah, I guess if I could. I think so. And this is mostly thinking in terms of the pod market place that we spent some time trying to build the charting for.

But I'm sort of imagining like there's probably a simple user to let people exchange deposits for plots. But I think if you really want to enable sort of the efficient pricing here, like I have a hard time imagining how to display like they're both both assets sort of change in value depending on position like pods, the place in line and deposits the season deposited.

And so I guess I have a hard time imagining how to sort of display that in a digestible way to let somebody discover the right pricing there. So and maybe I just to spend some more time thinking about it or somebody else has has good ideas here, but it's a little bit easier when one asset has a fixed price and is fungible.

But I think when they're both semi fungible, it's it's difficult to imagine like a sort of good way to to display this. I'm not sure if that makes sense or if that lands. So when it comes to 1155 being liquid in general, like in the case of this deposit plot pair does like if if the if the pair cares about both the stock and see the associated with the deposit and the place in line of the plot, does that not inherently fragment liquidity or is that the wrong way to think about it?

And the point is like any taker would have the option to care or not care about one or the other, like the semi fungibility of either side. So a lot of this depends on how it's ultimately implemented, but to some extent it's worth it's worth considering the difference between the efficient stock is liquid versus liquid in the sense that the the real difference in a deposit for a given season I guess in addition to the the underlying asset that is whitelisted and deposited is the stock for BTB.

And so what would really be, you know, in a perfect world is that the deposits themselves are still abstracted away from the user to a large extent, and there are some premium or bonus denominated in stock that is factored into the order. So there's an axis and then there's a stock or stock for BDB. Access doesn't the same thing.

And the, the concept there is that you basically get you get to the to the point where the orders can start to be, you know, only two dimensional on the other side to currently one guy. Right now if you're doing deposits you actually do have fragmentation by season because in season three token and then you've got a bunch of different seasons than other assets, so you have a ton of fragmentation.

So economically. The real the real way to get around this is some abstraction through stock liquidity, if that makes sense. So I read your comments on on market complexity atomically, how, how it would probably hopefully make the most blocks.

So if I understand you correctly, you would you're saying that you would abstract out the well, I guess you would be measuring the BTV of the deposit and you'd be displaying it as a trade with. I guess it would, it would sort of function like a 1155 and an RC 20 at least at the UI level, and you would like sort of route through the I don't know, maybe, maybe I misunderstood this, but the deposit, the bean and deposit market to make the trade is is that right.

Well let's let's take an example where someone has some I odds on to sell for some worth of an additional let's call it X percent of the BD re in grown stock or in accumulated stock. It. In this case, I guess we're assuming that the person with the plots of the pods doesn't care or which type of deposit they receive, although in theory that is another ax that they could specify on their order.

But if we keep it to just some BDB and stock per DB B, you can effectively have the order be filled by any set of deposits that fulfill that fulfill those parameters, if that makes sense. So what you really want included in the order is the the ability to encoded in order which the 1155 underscore good in the case of deposits is asset type BTB and stock for BTB and then on the place the line the question is around making it as simple as possible to abstract away down to the axes the 1155 tokens themselves so that when you're a bond you are really only interacting with that access itself, which is the price line.

But when you're buying deposits, your only really acceptable asset types, the BTB that you want and the stock per BTB, if that makes sense. So there's your point when you are buying some asset with a particular asset that the asset that you're buying with, you sort of inherently don't care about some particular component of that asset, right? If that's really the right way to work.

The question, but it's really what the market is about, right? You have some an asset, some set of deposits and you want some pods, you know, under certain parameters you are willing to list your, your deposits and exchange them for for pods or for plots that fit certain parameters. So if someone now comes and wants to fill your order with pods, be willing to accept either the deposit that you are willing to put up for this or some combination of assets that there is already liquidity for for your asset.

And that's really where the complexity lies because more trading pair a spin out question around aggregating the most efficient liquidity path such that you can match more and more of these orders together, even if there isn't a direct match. But if you're if if you're the one initiating the trade, the asset that you're selling, the user interface could abstract away the properties associated with the 1155 that you're selling.

Is that is that the point? Is that I guess one of the points and I think that's a okay. Yes stings certain deposits and you're saying this is what I want for the deposit now what the market I've used is sort of a different question than what the seller is willing to sell. Right. So then when people are filtering in to fill that order, they may want to filter the order based on acetate, based on BTB, based on stock for BTB.

But beyond that, you know, it doesn't matter to the seller. It only matters to the buyer. That's how it fits into like the user experience perspective. So here's the asset I'm willing to sell, here's what I want for it. But the real point is that which angle you're coming at it from really does matter here because I'm just listing my deposits.

But I'm I'm not particularly when you have assets that don't have like they're not a single price is not real, but you're now matching sets of things. What the market is ultimately going to want to come to is some sort of prices, right? So a price for BTB, a price for stock, and that's why there you will expect aggregation or multi hop trades created to facilitate the most efficient exchange because the what the seller views as valuable versus what the market views as valuable are not necessarily going to be perfectly aligned.

I assume you'd still probably want some way for the seller to understand sort of the the relative pricing around the I guess I'll call it position or property of the asset that they're selling. Right? Like that would still probably be important for me to see. Like if I'm selling pods for deposits, like I would probably also still be curious like the pods maybe ahead of me or behind me have open bids at, I don't know, some, some price.

Yeah, but it's going to be that there are multiple axes. Right. So it'll be there's some BTB there's some stock for BTB and then the BTB and stock for BTB that you can get for a given size will change in terms of the ratio. So like in some cases you'll be able to get more stock. Me or vice versa, right?

So it's around like as soon as internal assets, it's not so simple. I give people a single reference price. Right, Right. There's two, there's, there's two. It's not a price, it's the BTB in the stock per bib, which can be different depending on what the the the what's really two prices. And the point is that the way that the two prices are related change necessarily expect there to be a a linear relationship between the two.

There may be but you can assume that with regards to the conversation about which trading pairs like if we say yeah, trading, you know, plots for deposits makes sense, like what are the additional parameters to figure out other than like which deposits like is it is, is one of the questions to answer whether the plot holders should care or be able to specify how much stock per BTB you know some you know some threshold above which they're only willing to trade deposits for their plot.

Or is the point that the market should be opinionated, but go ahead. My final question was just or is the point that the market should be opinionated and not allow a pot holder to specify that? Well, there's a question. Please feel like objectively the desired and functionality should be for market to specify things like stock per CDB. It adds significant complexity question around my end, but I can't hear you anymore.

I could hear him. Maybe you guy. So the to sort of summarize, it seems like being able to trade deposits for hogs is like a I don't know if we can call it low hanging fruit because it'll be complicated to implement, but certainly low hanging fruit from a obviously economically beneficial to being stock to have. And I think that some some key points from this conversation are that, one, you probably have to have stock liquidity before this market can become particularly efficient or abstract from a user perspective.

Two, you could in theory have a deposits for pods market place where there's no consideration of stock whatsoever, and that would probably be a minor upgrade from the current pod market place, but not up to par with the full functionality. And there's some open question as to how to facilitate the most efficient and abstract interaction with the different axes around deposits and, you know, maybe it makes sense at this point to sort of broaden the scope of the conversation a little bit and talk about what other assets are worth considering in this mix.

In addition to pods and deposits, for example, some sort of being future or being deposit future or something like that, where the there is some forward looking expected yield priced into current BDB. I think that that's another very interesting market worth considering. Probably makes sense to have four spot markets before moving to derivatives, but feel like it's worth throwing it out there for this conversation.

What are the other you know, there's fertilizer which hasn't really been discussed much what are the other assets or things that it makes sense to build rating support for with regards to being stock in the medium term, let's call it. Would you expect there to be separate markets for a deposit marketplace versus like, uh, like liquid stock marketplace, or is it different markets?

Do you mean like a UX, different UI? Maybe? Is that the same thing? Or maybe I'm just like, if, if, if stock is liquid that you know, are you, are you buying and selling deposits there or are you buying and selling like a erc20 of a stock or something? One theory you could do both. One stock is liquid.

There will be the deposits which will be 1155, which as mentioned, are effectively the right to burn a certain amount of stock and feeds with the deposit, receive the underlying and the. Then you'll also have a erc20 probably stock and then some sort of semi fungible seed where the seeds are yielding stock based on the the underlying asset that is deposited.

I think that there's some work being done at the moment to like further abstract the concept of seeds. And so not exactly sure actually on the implications of the liquidity thereof. And maybe Kouvalis wants to comment on that, but to shed a little bit of light there. But the concept is at least with regards to stock and deposits, there will be different.

There will be the opportunity to exchange or there should be the opportunity to exchange asset for stock or asset for deposit. And those are distinct things because stock deposits are distinct things. Once you have stock liquid, this is maybe backtracking us, but I guess I don't really understand whether the takeaway was that a marketplace that trades deposits doesn't make sense and stalls until stock is liquid or or if some of that development work is, you know, just additive.

Like if we had the ability on the part of market today to just use deposited beans without any care for the stock or seeds and then you know what work would be required after that to generalize it, if you will. I mean, I personally would say, you know, on on the pie and market place, right. You know, the majority of the the major use case for deposits will be someone willing to buy pods with a deposit.

And, you know, the deposit or deposits that will be used will be known ahead of time. So it does kind of allow for at the margin, some sort of arbitrary decision about whether to use, you know, about whether to value the grown stock at all. And, you know, don't think, you know, it's necessarily going to be the case that, you know, kind of the smart contract it needs to make assumptions about the growing stock, you know, kind of from the from the fulfillment side.

If someone is willing to sell a plot for a deposit, you know, I would expect the, you know, kind of kind of the you know, kind of you know, maybe, you know, they import some grown stock price, but, you know, think that's much more or less of a use case that for, you know, deposits than it is now or then.

The alternative it's people buying plots with deposits on the deposit deposit marketplace side overall you know think there's going to be value in the short term for with unripe deposits being able to put those on some sort of marketplace that people can buy and sell. But, you know, kind of agree with probably it's in a sense that, you know, these markets are not going to be fully efficient until there's some sort of stock liquidity.

But I would argue that even even before that, there's still plenty of utility to be realized through enabling deposits in this marketplace, namely the ability to create orders to buy plots with deposits. You know, if someone's selling a deposit for being if someone is selling a plot for beans, you know, there's already the option to through pipeline. Do you know, I withdraw and purchase and you know imagine that the majority of people are trying to sell plots or trying to, you know, exit their position instead of transition their position to a siloed position and thus it's like, you know, kind of I don't see I don't see much demand for training, you know, plots for

deposits, you know, by, you know, through order creation. There, you know, But there is the big point to be made around the specific deposit market place and, you know, and not, you know, unripe deposits will certainly be something that would be great to allow the permissionless trading of. You know, it just should be also be noted that once deposit top 1155 standard you know they will be on opensea at least so people will be able to you know, trade DRC for 1155 on Opensea you know just without the use of any sort of pricing function.

So that would be the advantage of a bespoke market for unripe deposits is the pricing function. Yeah. Which you know, quite frankly isn't very large. I mean, these, these opensea markets are not going to be able to be denominated in them. And I think some investigation was done at some point and it imagine it would be quite a substantial, you know, kind of campaign in order to get been on opensea.

So, you know, kind of a deposit marketplace would also allow these transactions that happen in bean and through the being website, you know, opensea used to have a 2.5% fee, which is quite substantive, but I think they've since reduced it to like a point 5% fee. I may be wrong, you know, but but kind of, yeah, regardless like the standard 1155, the ERC 20 case is kind of already handled through seaport or opensea.

Yeah, I forgot about the nominating and Ben's part. That's a great point. I think it is worth sort of thinking from an economics perspective about what's likely to have the most impact on stock and facilitating deposits in marketplace. It's even just deposits for early twenties and that can be unripe and ripe deposits and you know, then potentially also getting it to be deposits for odds that seems to be at least on this end, where there's clearly the highest leverage and the, you know, probably a path forward.

The question then becomes around the integration on stock and potentially seed liquidity and how that fits into all of this and how to make feeds liquid excuse me, stock liquid in whether or not stocks should be divided into governance tokens and age tokens and interest tokens are how exactly to facilitate the most efficient markets around being stock through these tokens and how all that fits into the overall timeline for which markets to roll out first.

So I mean, maybe an open question is which has already been discussed sort of here is what how does the liquidity around stock and potentially seeds affect the creation of markets for deposits? And does the does one need to happen before the other? I mean, the most interesting angle on this front is before stock is liquid stock for BTV is really a bonus because the deposits come with the stock, whereas after stock is liquid, the stock for BTB is a penalty because the deposits do not necessarily come with stock.

And that is a you know, then then there is some additional complexity on the UI front around. Are you expecting to bundle the stock so that when you buy the deposit you're buying it with stock or not? And it probably particularly given the you know, the goal of this call is to orient around planning timelines and timelines around specific products or exchange pairs.

You you know, there is going to be a significant change on the UI level around supporting deposits after stock is liquid versus before. And so I am curious for comments on, you know, whether whether it makes sense to to do stock before, which is probably what it seems like makes the most sense versus after. And when you say penalty yeah that that would be because the stock does not come with the 1155 token and so the the receiver of the of the token after selling their plots may have to buy more stock and seeds than they you know than they would have otherwise in order to liquidate their position.

Correct. So it's like if you thought, you know, you're buying it for the underlying beans and the liquidation value of the beans, when you received the the deposit as it currently is constructed with the stock, you can then just withdraw and sell. But once the stock is liquid and distinct from the deposit, now you have the deposit which is effectively the right to burn a certain amount of stock and seeds for the underlying asset that was deposited.

At that point. The order for the pot, if it is just the deposit and there's no stock included, actually isn't worth what the underlying is worth because you'd still have to go out and buy the stock in the market to get to get access to the underlying. So it fundamentally inverts the relationship. And as as time goes on, you would need a greater amount of stock to access the underlying in the deposit asset right?

Correct. Would also just mention here that, you know, the nature of what's being transacted, you know, is is you know what the actual tokens that are being transacted are not as important from the perspective of, you know, like the deposit marketplace is assumed to be transferring stock and then stock becomes liquid, you know, like some sort of, you know, orders created going forward could just include the transfer of stock and or seeds as well.

And it could just be a market place. You know, it's like you user has the option when they're transferring a deposit. Do they want to transfer the deposit, including the stock, including the seeds or excluding. So ultimately some sort of market that facilitates, you know, both those you know, both those you know, both those situations will probably, you know, in the long run be in order.

So is it fair to say from a development perspective, if this market was built, you know, on top of the 1150, five tokens and then liquid stock was implemented, nothing in the market would necessarily have to change. It would just be the economics of the market that change at that point in time. Yeah. And the economics of the market don't have to change if the market is adjusted to include, you know, grown stock and grown seeds, somehow there need to be some, you know, cancellation event of all existing orders or something.

But there's no reason why, you know sure the market the economics of the market might change or you know the the order structure of the market changes so that it transfer stock in seeds and in a deposit of just the deposit, which, you know, is assumed to include everything else. Right. But the order structure changing would be development.

Yes. Well, in that case, that doesn't necessarily sound like there's a cost to starting work on a deposit plot marketplace before stock is liquid, even though the economics would change after that's implemented. I think the point is there is a development cost, right, in the form of this new order structure and the aggregation of sending the stock and the seeds with the with the now deposit slip.

So it would seem that it would actually be I mean, I guess from a UI perspective of like straight the like the what the user is doing might not change, but everything else would actually have to change. We back out of the technical requirements here for for just a minute and maybe think a little bit more about about the product.

I guess do we have a sense for like how we would we would determine how many people, for example, want to trade liquid stock? Well, what you know, to me, I think a lot of this makes sense in the in the world in which everything is composable tradable. But trying to think about things in terms of, you know, what actually how do we measure market demand, be able to trade those sorts of different, you know, things in that matter?

I mean, I think that it probably can be intuited by where is the most inefficiency in the market. And from that perspective right now, clearly there's a ton of inefficiency around deposits and the exchange of deposits, because if people want to exit in a silo, there may be someone else that is willing to buy their deposit from them so as to gain the stock or so the stock is in burned.

And that that's probably the most glaring economic inefficiency of the system right now. And therefore, there's probably the most alpha there and therefore there's probably the most demand for market market markets on those assets would be how I would think about it my sense. And I guess in addition, you know, deposits being tricky to use in defi is like a second component of that.

And you know, the pod market liquidity thing that we've discussed is a local excuse me, a local example of that, but perhaps like making deposit 1155 will help, you know, for example, with the seaport side, which obviously that's, you know, a bit of a separate conversation. I guess like the reason I ask is because, you know, it seems to me at least at first glance, that if the goal is to reduce the friction around using deposits in the manner as you described, then it probably makes less sense.

Start thinking about stock liquidity, because it's pretty clear that stocks liquidity adds another degree of dimensionality, which at least from a unique standpoint, seems to to be something pretty tricky to solve. And so if the immediate problem is just being able to sell a deposit and withdrawing it or, you know, use it as liquidity or use it as, you know, one side of an order to do something that seems to me to be a problem to an extension, maybe we should focus on that and push the stock liquidity side down the road to when it's more clear that that's, you know, what the market needs to reduce it or to improve efficiency.

I suppose that's a great point and we'll have to think a little bit more on where or sort of the marginal inefficiencies lie and whether that is more of the deposit level as a whole or whether that is at the stock level. Yeah, This is a very fascinating point you raised, Chad. Curious for what other people are thinking about this.

Can you restate the point or one of you? Yeah. So we talked for a bit about how making liquid, for example, would impact these markets. And I think I'm trying to zoom out a little bit and ask ourselves if it's worth going that many layers down the conversation here or I guess my my position is basically doing that increases the complexity of building an initial market to solve a clear existing problem, which is more or less that deposits are kind of stuck and can't really do a thing.

And I'm not sure how much adding stock liquidity to that equation helps solve that problem in the short term. And at least to me, I think the stock liquidity stuff is interesting in a theoretical sense and will probably have some applications, but it does not seem to affect any of the more immediate, you know, sort of things that that we can imagine makes sense.

And yeah, in addition design and development of it is probably a ways out. A question for the solidity developers how does implementing deposits as 1155 is a before stock and seeds become liquid? Does does that add any sort of complexity on effectively then changing what a deposit represents or as you were saying earlier, prove this? Would that just require some sort of one time cancellation of all existing orders associated with those old deposits drops?

You know, nothing changes from a development perspective, you know, But you know what? I guess transfer function would change in the sense that, you know, now you transfer deposits. It includes the stock and seeds. When seeds are liquid or you transfer a deposit or not include the stock in seeds. So there actually is like some functionality difference there.

You know, it's hard to you know, it's going to take some time to think through all the potential ramifications of this. But it seems like from a at the surface level, you know, if one just you know, if all the open orders are canceled, insufficient notices given it's you know, I would imagine it's not that big of a problem overall.

I would also just say that the development of liquid stock is quite complex. And, you know, we'll probably be a multi-month endeavor from, you know, the point at which it's seriously, you know, that development has started at some some substantial capacity. So then maybe in the short term or the medium term, even the starting point should really just be around a basic implementation of deposits without stock in seed liquidity as an 1155 and sort of in parallel potentially the development of ODS as an 1155 and then the implementation of the ability to exchange deposits for ERC 20 tokens first, followed by the ability to exchange deposits for pot.

And none of this need include the complexity of stock per BTV, but can ultimately be added at the UI level at some point. I mean, would just ask the question, you know, doesn't it make sense to start with deposit for a pot and, you know, kind of a combination of deposits and or being per pods using the new market structure given that, you know, deposits will already somewhat be supported by opensea or do we feel like, you know, the the marginal you know, kind of now this is happening on, you know, the beanstalk UI for Beanstalk technology denominated in beans.

Is that beneficial? I think that ultimately depends on complexity around and for the people working on this or whether it you know, whether it it it makes it easier to start with pods for deposits, which seems like it's the more complicated task and then work backwards or start with the deposits for ERC 20 tokens and know the pod functionality after that.

But, you know, I think that's really more of an implementation question. Do any of the devs have the UI doubts about this? Sorry, perhaps could you, could you reframe the question for me briefly? Particularly we're trying to get into the weeds on whether or not, you know, the complexity of developing the deposit as 1150 fives without stock or seed liquidity against pods and then working backwards to add deposits against erc20 and pods against Erc20 is better or it's preferable to start with deposits for ERC 20 and then deposits for pods, then pods for for CRC for.

Great question. Thinking about that, you know, at first glance they from a like UI build out perspective, none of the three seems particularly harder though I think on the margin anything that GRC 1155 ish will be comparatively hard, but all of them have that. So not sure I see like any particular technical angle, I'll think on that more.

I think what that means is basically like, you know what's most useful to be in stock in the short term? And so I think that comes down to like the marginal, you know, on the margin, the value of being able to trade deposits instead of withdraw versus like adding more liquidity to the pod market. So yeah, curious if other people feel that characterization is the same.

And then also for the UI team, if you guys feel like that's that's a fair assessment. So if we were to support deposits for plots market, would that be in the structure that we had sort of discussed previously on this call about being able to define the sort of BTV of the deposit and the stock per bit of the deposit, I think you could start with just BTV to keep it as simple as possible and then stock or BTV could be another axis added over time.

And so the consideration here is to sort of determine if makes sense to build a native bean stock market to trade deposits when you can do that on opensea, when deposits sort of match the 1155 structure versus building out the sorry, building out the deposit market as a separate beanstalk native, set the right question. Well, ultimately the there will be some sort of beanstalk interface, native way to exchange deposits in pods for ERC 20 tokens.

But yes, at the margin, once they're implemented, that's 1155, you will be able to use Opensea for those exchanges. And so there's a question as to creating a new market, which would be deposits for pods first and then working backwards to incorporate the the 20 tokens which are already supported on Opensea versus working forwards and just matching Opensea functionality, adding the ability to denominate things in BNB and then going from there and then adding the deposits versus pods market.

That's the question. I tend to think it's the deposits for, for pods one. But yeah, curious how few others feel. Why do you feel that way? Chad Just out of curiosity. Yeah, well, I think at first glance, so the pod market has pretty limited buyer side liquidity and the pod market doesn't function nearly as well in a sort of manual like trading OTC form.

However, we've seen a ripe like an unripe deposit market pop up that OTC, which well, obviously like pretty janky for the purpose of at least trading unripe, which seems to have been the most common factor for this so far. Like it works. And so to me that problem is like it's not solved elegantly, but it is, it is like possible.

And I think probably the the the way in which adding, you know, deposits a market to buy and sell deposits themselves moving forward is to, you know, add an alternate path when withdrawing from liquidating your position and frankly not sure I think it makes a lot of sense. But now sure we see like a ton of demand for that exact product.

Right now, though, I guess we also don't have the data in terms of, you know, who would be willing to purchase a deposit, you know, under you know, under what parameters. But that's I guess that's my first thought. I think the second is that we've talked about both deposits and pods becoming I.R.S., 1150 fives. And as I understand it, you know, Opensea, for example, does a decent job of trading in ERC 24 DRC 11, 55 and the market cases of ERC 24 deposits and ERC 24 pods would both be fulfilled by interface in the case where we make them both.

I.R.S. 1155 compatible. Basically what I'm saying is like to some extent OPENSEA has already done the work and you know, we can, we can look at other marketplace uses as well. So to me the on, on that front, like we should probably test the interest for those markets by making deposits in pods of 55 compatible and then trying to encourage people to trade them on Opensea if if they so desire and you know, try our best to make the user experience as good as possible for those for example like we we did, I think decent job with fertilizer of making it legible on opensea.

It's tricky because of the, you know, the way we do IDs, for example, for gas efficiency kind of makes each individual fertilizer opaque, but you know, adding metadata, customer data and that kind of thing has been able to help solve that problem. So I would expect that we would want to do the same for both pods and deposits.

But deposits for for pods, which is like two, you know, 1155 for 1155, I don't think as far as I understand it is nearly as well understood by something like Opensea. And frankly, since both of those are beanstalk native, it I think on the margin makes more sense to us to build our own UI around them rather than for any ERC 20 token.

I think I generally agree that uh, if you can already deposit exchange using opensea when they match the 1155 standard, I think probably right to start with the deposits to pods market, but that's what I think plus one. So as of now it seems like the consensus opinion that people feel just to feel free to disagree is to implement deposits in pods as 1130 fives and start with a deposit for the marketplace and not include stock in the stock functionality after the initial launch of the market.

Yeah, maybe that makes sense to me. I guess before we dig into a couple more details with our last 15 minutes, anybody else any other thoughts on that front? I guess I had a question around where the existing pod market fits into that and whether we just leave it there or do something else. When you say it makes sense and what does that mean?

Like, would it make sense to migrate? Well, that seems a little invasive. But what I was going to say is like migrate existing orders to like deposit the beans in the orders and recreate the orders like as as a migration. Like I asking like what's the point of the existing pod market still existing or like rather I guess, you know, more importantly like the orders and liquidity on it once they deposit for pod marketplace exist?

Well, I think the short answer is there is none. The longer answer is that it goes back to the benefits of having orders on chain, which is the way that the current pod marketplace works. So if there was some sort of borrowing happening against pods with liquidations happening on chain, it may make sense to revert back to an on chain marketplace as opposed to an offline marketplace.

But otherwise there's no real reason why the current version should continue to exist. But you're saying a version like a deposit plot marketplace that does exist on sea part would not have that proof of liquidity, correct? So over time it makes sense to try to implement something on chain, but you know, that'll be much further down the road.

Another and other question, how does that relate to the person who wants to sell pods, like in world where there is some need for the proof of liquidity, would there be some sort of incentive to sell on the on chain marketplace versus the off chain one? Or because otherwise, why wouldn't everyone use the off chain one, even if even if some other protocol needs it be an easy on chain data is not a question specific to the pod marketplace.

The short answer is that there can be some fee charged by the person creating the order of the wallet, creating the order for being filled through a liquidation, if that makes sense. So it's like this this liquidity is being provided to be used for liquidations. And therefore if you're going to, you know, liquidate into this liquidity, you know, you have to pay a certain premium.

For example, I see. So like the the order itself could encode some sort of vig charged by the liquidity provider to compensate them for that child. I think you had something you wanted to say earlier. I didn't mean to backtrack this here. Good lost the thread, but I think the existing marketplace question is really interesting. Maybe the other thing is in the world I described where we're trading deposits for pods when both are 1150 fives, that off chain order book or the off chain approach would not without additional work support early 24 for pods as sort of I guess that's implicit, but it kind of made me realize that if we're only doing 1155 or

1155, for example, there wouldn't be a way to actually trade been for pods using the off chain approach. So that's something to take into consideration and relates to the existing pod marketplace. QUESTION Given that that's exactly what it does, even though it's on chain, I mean, to me the two the two go hand in hand trading pods for beans and pods for deposit should somehow try to be implemented as a singular market.

As you know, for instance, there'll be people wanting to sell plots for beans and maybe that order will actually sell plots for deposits and through pipeline, then perform some sort of withdraw and maybe even to sell. But it's like to me, it's like the the market structure should be done from the perspective of, you know, it somehow supports orders of both so that it can kind of cross leverage, you know, the use case for people wanting beans and the people wanting deposits.

And in particular until the stock for BTB is added to the interface, which it doesn't seem like will be and be one, there is no difference other than whether you're loading up erc20 beans or deposits and to prove this point, it should definitely be abstracted away. You're talking about from a UI perspective. Yeah. The, the, the idea is that until you have stock for BDB, it's still just a being denominated marketplace.

So whether you're using toes or being deposits, you're still just denominate in some sort of order and beans for pods, right? Sure. So maybe let's go one step further and think about what the simplest implementation that takes stock into account looks like. I mean, from people creating orders to buy plots with deposits, you know, the stock's kind of already taking into account from a protocol perspective.

But now it's like they use user, you know, from choose if the user wants deposits, meaning they don't, you know, they don't want to withdraw and sell or something, you know, then they receive some sort of bonus stock for choosing this order over one that say uses being in the case where someone is by or I guess selling a plot, you know, then they would need to specify some kind of grown stock per bonus which basically would say, you know, I'm willing to pay some number for some bonus grown stock instead of, you know, just taking into account the BTV.

I mean, not to add too much complexity to this, but could see over time some sort of like stock per BTV or place in line or being made. So then it's like in order for a given order to be filled, it needs to satisfy both a B2B fee for place in line and a stock per BTV per person line.

So it really be two values that need to be satisfied and that would probably create the like an efficient market in this case. But that may be too complex where you want. Let's roll it all the way back though to so the starting point is a deposit gets used to buy parts and we completely disregard any concept of stock.

So we're just looking BDD. So that's sort of version one, right? And I think like even that product is probably quite valuable given the ability to just use latent liquidity that's in the silo lien deposits to place orders. So that's, that's the first step in my mind. Then the second the second question is like what is the simplest form of taking into account that different deposits have different amounts of stock relative deposits?

And how can we if we were to boil it all the way down, what would that look like? And that's probably relevant as well for the ERC 20 to deposits side. So very much so. So I think maybe the question I'm asking is like, let's imagine, let's just imagine for a second we're placing an order for pods and you have a deposit or I guess maybe the other way around.

What do you, what do you envision the inputs to look like? In the simplest, simplest form? I think it'd be something like me picking from my set of deposits, which ones I want to order with and what place in line. I'm willing to trade pods for those deposits and I additionally maybe some sort of preference structure around. Are you willing to sell any of them?

Are you going to or are you only going to sell the earlier deposits first? Are you going to start with the later ones, etc.? Yeah, I was thinking about that. There's a partial fills are going to be a huge pain in the ass here. I'm actually not sure how Bryan would probably know more about this. I'm not sure how support handles partial fills in this kind of case.

So yeah, I mean, so simpler. Yeah, I would be curious about that as well. It's my understanding that you can specify some kind of miracle. I mean, everything should be flowing through pipeline, even if it's routing through seaport, you know, still not completely convinced that seaports capable of doing everything that's required. And still a big fan of the kind of things the tractor interface.

You know it's going to be way I think cheaper and have less overhead. So, you know, that's a whole separate conversation. But, you know, I would assume that we're operating in a world where there's generalized functionality and, you know, if if an order book doesn't support what we want to do, then it's not getting us well. But on the buy side.

So I'm buying with deposits, buying some pods. I just take the deposits that I'm willing to spend. I pick a place in line. Any pod below this place in line is good to go. And then I maybe order the deposits. Obviously, this doesn't take into account some sort of like pricing curve across the you know, you could do it even simpler that you could condense stock for BBVA down to a single value, and you could do that for both sides of the market.

So when you're selling, you're saying like, I want at least a certain amount of stock per BDB from the deposits that are buying my pods and vice versa when you're buying and in theory constructing your set of deposits, those average out to some stock per BDB. So understand that it may not be the most efficient thing to send like a pro-rata portion of all of the deposits, but think that there can be some optimization done on creating the most efficient combination of deposits that aggregate to the stock for BDB value that you chose.

That's probably yeah, that's, that's helpful. I'm trying to imagine imagine what that looks like. So let's say that you have this variable. I mean, in theory you could still have the static prices for the pod side of things, but that's like painful, particularly given the timelines on this. Like we should be able to get some sort of variable pricing from ODS.

The concept is you've now got these curves for pods that aggregate to some, you know, BTV overall. And then the only additional feature to include stock in the in the market is some stock for BDB value that when an order is filled, it just has to be greater than or less than depending on the market. The stock for BDB value specified in the order.

Yeah. Still having a little bit of support here like envisioning the this doesn't feel like the simplest form of making this happen to me. Maybe let's go to the like the user side, like what's what guy said earlier in terms of just like picking deposits. And when you say this, do you mean including the variable prices for pods or not?

So and correct me if I'm wrong here, but there's kind of two dimensions of additional pricing. One is a varying price for pods based on place in line. And then the second is including stock in the calculation, like some sort of threshold, right? Or as a variable like a, you know, a curve in and of itself. Correct. If I'm thinking of that wrong.

Okay. So those are like the four layers, the four tiers, you could call it static pricing for the pods for BDB. Then you a variable function pricing for the pods based on flex line. Then you have static stock for BDB and then variable stock for BDB based on place in line. So they're sort of sisters, let's call it cool.

Okay, So, uh, I guess the point I'm trying to drive to is what's the simplest implementation of some sort of static inclusion of stock in pricing model, much like we, we made. Yeah. So assuming you have the static or variable pod per BDB, let's call it, the point is that the order itself still has some BDB value. So the BDB value is, you know, if you're ordering pods, you are putting up X amount of BDB in the BDB value, believe in the in the order.

And so you put up a thousand beans or PDB in the order. The question is now you can add some sort of multiplier to it where when you are. Well, let's, let's think about from both sides. It's much more intuitive from the sell side where you're selling odds and you're saying that you want you want deposits with at least one point to stock for BDB.

So if your pods are being bought for a thousand BDB, then you want at least 1200 stock associated with those deposits, if that makes sense. So when you're placing an order for or to list, when you're listing pods, you can specify that you want at least a certain amount of stock per BDB. Now when you are selling your deposits for pods, thinking out loud here, but to some extent there's no notion of getting credited for the stock, but there is some notion around the stock per BDB on the on the order as a whole, meaning that if you aggregate two different deposits with different stock per DV, it's obviously in the interest of whoever selling

into that order to take only the if they're going to partially fill it, take only the, the deposits with the higher stock per BDB and then leave the rest of your order with less stock per BDB remaining. And so I guess the the point is that you similar to saying how you're willing to pay a certain BTB per place in line, you could also specify that you're willing to pay a certain of stock, but no more than that amount of stock per place in line.

So it would be a maximum stock per BDB, either as a static value, as a or a curve as a function of place line, saying I'm willing to pay no more than this stock per BDB as a function of place in line, if that makes sense. And this is in the case where you're suggesting that I put multiple deposits in one order for number of pods and then it's like the deposits have different stock per PDB.

And so I'm setting like a threshold basically correct. So when someone fills partially, they can fill partially, but they can't extract more stock per BTB than you're willing to pay this. It only applies in the case where there are multiple deposits in the order, correct. Otherwise, it's like I'm kind of implicitly setting the threshold by only having the single deposit, which has a specific stock for BTB that is talking about that, right?

Yeah. But you have to assume that people are going to be putting multiple deposits in a single order. Well, maybe from a UX perspective, it makes more sense to like combine the deposits and then and then list rather than having a bunch of deposits in the order. Yeah, but then you lose. You would literally take away this exact complexity.

Like this is a benefit to the user, right? Yeah. I guess also, since this is a blockchain, you could just place a bunch of orders with smaller amounts rather than having to. Because one thing that I'm trying to think or I'm not even sure how you would do this. No, I think the point is that's not how this works because you don't have know.

The point is, if you have two different deposits with different stock per BDB, they average to some value. You can't segregate them two different orders with the two different stock per BDB and then still get the benefits of the average stock per bid unless you're combining them in the order itself and then encoding some maximum stock for BDB you don't like, you don't get any of the benefits of the aggregation.

Yeah. Having a little hard bit of a hard time following, following all of this on the buy side, to be honest. Maybe like if you boil it all the way down more or less, what I want to do is get more pods or get better pods. My deposit has more stock. Would you agree that that's like the simplest description by better pods?

I mean further up in line? I don't know if I mean, that's one way to say that it will manifest, but the concept is that you want rent. You want to be credited in some capacity for the stock, right? So the base implementation is we don't factor in stock at all. You basically don't get credited for stock. The concept is now through allowing the the buyers of pods that have deposits to impose some parameter on the stock per PDB, you're basically allowing them to specify how much they want to get credited for the additional stock in practice, because what you're really doing is imposing a maximum stock for BDC that can be taken for a

given place in line, and that is what creates the the limitation. Whereas before it's like any whether it has a lot of stock on top of it or almost no stock on top of it, or a grown stock on top of it, we should say what you're going to get credited for. It is exactly the same, whereas now you can impose a limit and say this is the most amount of stock I'm willing to in exchange for this pod, which creates more scarcity on the stock.

And therefore you'd expect the pricing, the assets to start to factor in the value of the stock. So the idea is that the way the parameter itself plays out is there's some maximum stock for BDB you're willing to pay on your order and then you can just load up your order with as many deposits as you want. And when it's filled it has to be filled with some aggregate of the deposits or some combination of the deposits that have a lower average stock per PDB than the maximum order.

Cool. Trying to draw some of this out while we're talking just to just to visualize a little bit. So sorry if I got quite curious. Anybody else as has thoughts, could you speak a little bit about the aggregation of the of the deposits and why that happens? I guess because you have deposits that have different stock for BTV and need to be combined in such a way where they have enough PDB to fill the order, but not enough stock for BDB to violate the maximum stock for BDB parameter.

And you repeat that. So the the basic idea is that when you are when you have a set of deposits that have different stock for BTV and you put them in an order and you've said there's a maximum stock per BD re that I'm willing to pay for any of these cards. The idea is that when the order is filled, the deposits that are ultimately exchanged can be any set of the deposits that fill the two parameters specified in the order, which is that you're paying enough BTV for the pods and that you're not paying too much stock per BTV for the park.

And so the to some extent, whoever is filling the order can choose potentially can choose the set of deposits that they want to draw from the order that fill those parameters. And, you know, to some extent it's up to the UI to either abstract that away from the users or to allow them the opportunity to customize the deposit they receive.

But because you have deposits with different stock for BTV ratios, you're ultimately going to need to create some sort of aggregation or combination within the set of deposits in the order, unless you're going to fill the entire order and take all the deposits. For what it's worth, I'm not sure that partial filling is going to be I think partial filling is going to significantly complicate the engineering.

So like in this in this example, somebody creates an order. They put ten deposits in it for some number of pods and then a partial fill would constitute me looking at the order, seeing that there's some deposits in it and picking a couple of them and then executing it sort of halfway. So now like six, you know, the, the other, the user on the other side holds six out of the ten.

And that the problem is that we now have to index that this is not even sure how we would go about indexing a partially filled order because it would require us to have parts of the order to the extent that we know we're able to track like the you know the users deposits individually rather than statically checking to see if the order is full syllable in aggregate, for example, which is kind the original idea for at least on my end for simplifying the process.

So I think that yeah, all that to say I think the indexer gets much, much harder in the partial field scenario and I bring that up not to say we shouldn't do it, but just to say I'm curious if, you know, if we can think of ways around that problem in particular, since when we, you know, what of the constraints that we've kind of lifted by moving things off chain is just making it much cheaper to create orders.

All right. So about 15 minutes over at this point, it seems like the the first market to really focus on is some pods for deposits market. And there are open questions around the complexity in terms of stock per BDB and partial in and the complexity thereof. But otherwise it does seem like there's some sort of consensus on the first market to work on and how that relates to the implementation of the pods and deposits as 1155 switch would have to happen first and stock and seed liquidity should happen after.

And that seems to be working right at our analysis. So it probably makes sense to have another dev call on this specific market at some point in the near future, but I feel like this was a very exciting and productive call. Agreed. And just for everyone's reference, we're not going to have one of these dev calls on Thursday given that various folks will be at ETH Denver, but we'll continue this next week, on Tuesday and Thursday.

All right. Thanks everyone, for coming.