All right. So towards the Dovecote caucus today, it was my understanding we wanted to spend a amid of the discussion talking about concretely what some of the markets that we should be working on, on top of infrastructure like tractor and wells. So call it, you know, improvements on top of the existing pot market markets to trade deposits, fertilizer and the like. But that said, I believe Fucci is here to talk a little bit about what they're working on. And so so last Tuesday we had mod talking about the module and protocol that they're building. Mr. Manifold was showing some context on what Root has been up to these days. So in that light, perhaps crucially, if you want to set the scene a little bit as far as what you're working on, how it relates to Beanstalk and perhaps we can take the discussion from there. Hi. Yeah, I don't have a million things to share. Thank you for young Musk for inviting me, but yeah, so I'm working on an MMO called Pyramid. I'm going to send you guys a link. But just so you know, like we haven't launched this publicly yet, I just really love being. So I'm giving you guys Alpha because I love you. But yeah, I, you know, I have a lot of pods and I've been involved in being for a long time, kind of from the shadows. But there's basically four ways to create demand for a stablecoin that have emerged in the last like five or six years of defi existing sidechains as a gas token like xdai staking yield like fracs and static pools as an institutional onramp like usdc or being used to create leveraged positions like DAI is is on chain and I would really like to see more work happening in the being ecosystem to create demand for being and bring the price above peg and pay back the pod holders. So one of the ways I think to do that is to create a to just use it as a currency in more places. Like if we're working on a game, we should use being and have people doing business development to say, Hey, put being into your games, put being into literally everything that you possibly can. So we're doing that. And I also think that a lot of crypto focused memos have failed recently or in the past several years because the product was the token and they spent too much time trying to do token engineering and optimize around the tokens and really just creating yield farms like Defi kingdoms and others. But if we already have been, which works great and is the only stablecoin with no maximum amounts that can be minted, that can meet the only stablecoin that can meet any demand, then all of that is already done for us. And the main engineering left there is one the UX challenge of microbeads, which I'm happy to talk about a little bit next and to the how we want to handle as kind of the being community bringing being to other chains. And do we want to have an official version of that on Arbitron or do we want to have an unofficial version or a rap, the version that goes into micro bands or things like that. So that's that's kind of the gist of what I have to talk about today. I feel like I just talked for a long time, so I'm going to stop there for now. And if there's any questions or anyone facilitating or wants to jump in is holy moly, holy moly, insane, insane. Great. Alpha, we love you too. Thank you. Do you have any idea of what chain you plan on launching the game on Arbitron? Nova Yeah. So, you know, it's, it's interesting because we can just I can just bridge beans to Arbitron, right? But making sure that there's liquidity and that people can actually access it. You know, there's going to be a Dex inside the game that the the protocol kind of side of it is collecting fees from. And I would like that being to be sort of the the LP token to pair items with and pairing game currencies with. So if we can do that, you know and there's a few different ways it's either bridging a lot of beans and moving liquidity or there's some kind of interesting things that I know Mr. Manifold and Yung Musk, where we're working on and talking about in terms of the root token and how that could apply to kind of cross-chain apps and things. So for for micro being, kind of the unique thing that I mentioned before is if we're on Arbitrage Nova, the transactions are really cheap. If we put a certain amount of being for completing a quest, etc., it's going to be like 0.0000007 billion for doing something and that looks absolute shit in the interface. So the idea of micro being is just being one millionth of a being. It's basically a wheat contract and you just wrapped your bean into 1 million micro beans and that's it. So, so kind of splitting the beans into a ton of tokens makes the interface look cooler and then we can have a separate bridge contract where we can just bridge micro beans. And I think I think there's some some kind of interesting fun stuff there to just like teach people what beans are and how it works. But as an education thing. But you know, I'd be into having an official version of that, that being stock farms or even just the Dow says, yes, this is the official micro bean. It's not really like a big deal because it doesn't do very much. Besides, it's just wrapping the token and making it easier to look in an interface for that. That could be a cool thing that that we start with and say, what is this? Go and does it create enough demand for being to be interesting to everybody? So solidity already exists without decimals and thus as far as the on chain contract is concerned, you know, when you have one bean, it really is one micro bean. And it's only the fact that bean is defined as having sex, decimals defined as far as there is a function called decimals that returns six that this concept of six decimals even exists. So from, you know, the the on chain realm, you know, being, you know, all of these tokens really exist without decimals. And the concept of decimals is something that, you know, off chain clients add to the token to make it more interpretable. So is there any reason why, you know, for this micro bean implementation, you know, the decimals itself could just be ignored and thus, you know, one being becomes one micro being simply because whatever UCS is being built on top of the game just chooses not to perform that division by one in six. Yeah. So the reason for that is it looks really confusing if you have in your interface that I own 700 micro beans and then I go to transfer that somewhere and if I bring it into Uniswap and I bring it into any other Dex outside of the interface that we've built for it, then it doesn't say that I have this many micro beans anymore. It says I have 0.00000007 beans and that is, I think, really confusing. It's it's really a UX point of view of how does this how does this affect other people? Do they understand that they control their assets in the game, They understand what that asset is. And if we're calling it something different in our interface and yeah, we could just do that and it can just be a UI, just be a UI, a UI trick. If, if you want to do that on the interface, that's fine. But I, I, I think it is a little misleading and it will lead to confusion and people getting fish if it's not a separate token. So that's just kind of my idea there. I understand like it's going to be extra gas, it's going to be extra, you know, steps for switching it over. But that can all be automated very easily on the front end and people don't really have to even think about it. I hope I hope that answers your question. Like I understand that you know the math. It's technically useless. You could just show it however you want. But I do think it is an interesting user experience improvement. Understood. You know, forgive my ignorance, but not too familiar with kind of web3 gaming and kind of how games actually kind of snap back to the blockchain in kind of save items and mint items. Would you mind walking? I mean, I'm reading through your little paragraph here. You know, it says there's going to be monsters, quests, bosses, raids, etc.. How does the actual game engine and the blockchain interact in that, you know, say you're fighting a monster, you know, does it somehow snapshot your player health every time you do damage? Does it snapshot after you fight in the monster? If any loot drops, it automatically saves it to the chain. You know, say you die and lose items. Does it save to the chain then? Or kind of how does that all work? Yeah. So this is also, you know, there's different levels of decentralization and different levels of on chain tests that you can take with these type of projects. And for me to say, oh yeah, everything is on chain, you can do all set, like that's not realistic. And I'm not going to bullshit people and say that it's the most defenseless thing ever, it being built in Unreal Engine and the focus here is on ownership and usability, not on decentralizing every aspect of the stack, right? If you're still using, you know, being that money is part of DNS. So, you know, DNS, it's not decentralized. So the part that really wants inventory and you have the ability to move your coins and move your different assets from your from your wallet or using Web three off and a tool called Use keep built on top of Web three off to give everyone social wallets and non-custodial lives on your device. And then the items in your in your backpack, the items that you have and things like that. You have the ability to swap. You have the ability to send to your metamask and ownership over your assets and the organization really controlling the centralized part of it, which is there is a centralized server. There is kind of the standard of how you build MMO is on Unreal Engine, MMO is like like Runescape and you know, others that you're more familiar with. You can't cheat the server parts of that where it's checking your health every, every, every tick and doing things like that. And I don't I don't believe that there's a way to do that in a decentralized way on chain and still have a clean user experience right now. Maybe there will be in five years and we'll look at it again. But that's that's kind of the plan is is the assets are always on chain and you have the ability to snapshot it or kind of cash out or on ramp or off ramp whenever whenever you choose. Got it. Thank you for walking us through that. So I guess, you know, kind of give an example of when some sort of snapshot would happen. You kill a monster or maybe you pick up an item. When that item enters your inventory, the game will then post that to the blockchain if you want. Yeah, I mean, it doesn't have to do it. Then it can be when you log out or when you choose to go through the interface and move all of these items that are just stored on the server and connected to your backpack locally and say, okay, put these into my, put these into my vault, put these into my wallet to save and I can create a transaction so that you're not having to constantly interrupt your gameplay to sign everything constantly. But if you've ever played room scape, you know you can go kill 100 monsters and or a thousand in an hour. You don't want to make a thousand transactions every time you pick something up, but you do want to make a transaction to move everything into your bank account. Once you get back to a bank and once you're ready to kind of snapshot and sync up. So that's that's kind of the guiding philosophy with that right now. Very cool. You say here anyone can submit new content directly to the game. Can you walk us through a little bit how you envision that kind of process taking place? Is there kind of an open source? The code is the code like open source. Some people are submitting pictures or is there kind of like a suggestions box that people are suggesting new content to kind of a kind of a hybrid right there? Again, nothing is open source yet right now because like I said, we haven't announced it yet. We're planning on announcing and dropping the first version and the first kind of open source repos for the project and starting to take Alpha like pre alpha sign ups at East Denver. So we'll will be around there and launching the charms claiming will be free and launched at Denver. And then what part of it is open source or there's anyone anyone can make a suggestion right. You can always make a suggestion and right now if you make a suggestion on like a traditional game, like maybe happens, maybe it doesn't. But we can use on chain governance like, you know, I've contributed to Moloch Dao and other like on chain governance kind of tools like my personally my, my background is in solidity development for the last six years and now we're, we're like a small team of four right now, but I'm the only person working, working full time. So it's going to be like very, very barebones in terms of what is actually in there and what you can add at the beginning. And I think the interesting part is that anyone can can add things in a way that it feels like you're modding a game and we're kind of taking a lot of the marble libraries that have already been built for Unreal Engine off the shelf so that we have as little as little as possible built from scratch and just take as many like a sort of libraries that are extensible, they're extendable as possible and let people, instead of just suggesting and creating mods, but actually absorb those into the game. If, if governance votes are met and it's going to be very cool to connect the actual on chain voting to what content gets pushed into the main repo for the game. And the plan is to use radical for that right now. But we're still we're still in such a early stage for that. It hasn't been set up yet. So I hope I hope that answers answer is a quick lesson. Appreciate you walking us through that. This is all very exciting and, you know, looking forward to hear more about the project. So maybe to comment on the economics a little bit, see if if you're just using the beans in the marketplace, unless the like the the orders themselves are the where the the DEX orders, where the assets in the game are being traded against the beans are deposited in the silo, you're going to easily have yield associated with that going to the the users of the system. Whereas if you used like other deposits. So if they were implemented at some sort of 1155 and you use deposits and just didn't even show the users the stock per say or use the routes, either you use deposits or routes, then users or holders of the beans in the system would or would earn more beans over time. In theory, is that something that you're trying not to do or you'd like to incorporate from an economics or a like a game perspective? So this is like what Mr. Manifold was talking about before, right? With and working on the routes and stuff. And also why I started posting in the discord here, because I actually want to have everybody's input. And I think that's actually a really great idea, you know, to instead of just using the token, why not use the version of it that earns yield for the holders? Is is that that's basically the question, right? Like, why would you do something that is earning yield for everybody. Yeah, exactly right. That's the question. All right, let's do it. Show me how to do it. Like, I don't know how routes works. I checked out the GitHub repo. I haven't read every line of code. It sounds cool. Let me let me know how. How, how we should do it. What? Like, what's the smartest integration? What what other ideas do you have for driving demand for being and and not just having it be something that is passively connected to the game, but actually earns yield for the players or creates more demand for being? I would love for there to be more defi protocols and stuff as part of inside the game beyond just swapping. But also, like I said at the beginning, you know, there's kind of this list of potential ways to create yield or for stablecoins. One of those could be creating leveraged positions in in-game assets using being right. And if being is our stablecoin of choice for that and we have a lending protocol, maybe that that that's an even better way to create create more yield for being. So I'm in for any of that and I'd love help or more ideas working on on any of those things. Well, I would just say that the the way that all of the tech that we've been working with root and with module and on build them is designed to make doing that type of stuff as easy as possible. Now it's not all going to be ready in the next couple of months, but yeah, hopefully over the next year, let's call it anything that you want to do along those lines. Can, can be facilitated in the game. So that's very cool. If we if we want to sit on the economics just for a little bit and dive a little deeper the two ways at this point that you could realistically do the integration in such a way where there was a way to accrue yield would be to I mean, well, maybe there's three there's a beanstalk level upgrade where any any beans that are trading against assets in your game can be whitelisted for deposit and therefore probably your game could just be deposited. Maybe, maybe Pugliese could correct me if I'm wrong on that, but maybe it could be facilitated where the game itself is whitelisted. So any of the I guess they would also require the deposits to exist on the Layer two. So the much simpler integration would be to send like the assets that already have gold to the layer two. Just thinking out loud here. So probably bridge either deposits bridge being deposited as 1150 fives or bridge routes. Yeah, those would probably be the two best options. Bridge bridge deposits. So being deposit or bridge routes to arbitrage in your case and then have it such that people can trade against the being deposits or trade against the routes. Now routes are erc20, which would probably be simpler to start with. But on the other hand, depending on your timeline, maybe it makes sense to do a little bit more groundwork and try to facilitate using deposits directly because that's something that will ultimately have to be done. But that's probably an open question for the devs. Yeah, I'm willing to spend some time looking into that more. You you lost me a little bit with the different token standards and, and that was like a lot of information. But if you want to if you want to write some of that down or hop on with me one on one, I'd happily go, go through any of that and whatever, whatever we can do to make it so that we're driving more demand for being whatever, you know, at that from being stock forms. And you know, there's a million fucking assets now. And I say that with love in my heart, but whichever one we should use, you know, let me, let me know and let's make it happen. And just, just to like add add on there for like timeline things. I know you said something's not going to be ready for two months. Like we're in like very early stages. The first, like real playable version of this is probably not going to be up until close to the end of this year. And I will be providing updates. And as we as we're going here, starting starting with the launch of Eve Denver. But game development takes a lot longer than Defi development where you can just, you know, publish a contract. So are the game are the tokens in your game going to be 1150 fives are some of the some of them will be there's basically five five tokens you're giving us shit for having too many tokens. I know, I know, I know. No, it's not shit. I said there's love in my heart. It's all shit. I love it. I truly do love. It's all love. It's all right. Does Baba just baba go ahead. Okay, so there's. There's five tokens. One of them is a secret, and then the other four are one being micro being. And just to have something that is stable inside the game charms, which are 1155 magic is an earth 20 and baller is a it's a it's early 20, but it's non-tradable it's like shares and a more locked out or I guess stock kind of similar to that but it's going to be early twenties 1150 fives and then are you also going to have 720 ones even if you can't tell us about them? Probably not. Probably not. If there's other if there's other like semi fungible things and items in the game that they're most likely be 1155 just to save gas on on transfers and great flexible fastening. So I mean from that perspective we probably see you probably want to do it as either are the two options are a deposit marketplace where you're trading being deposits against all of these assets. So it would be 1155 against 1155 or 1155 against 20, and that could probably be done through tractor or you could use routes which are wrapper for deposits, and that would be DRC 20 against 1155 and 20 against C 20. So there's some question that you can sort of pick. I think it's worth diving a little bit deeper into the economic implications of what you're offering users or maybe ultimately offering users. And you probably don't want for users both. You probably want to guide them towards a single experience. So maybe it's just worth spending a little time now talking about the different economic implications of the way Route works and how that compares to deposits, if you would find that helpful. Sure. Yeah. I'm also not really worried about, oh, you know, is it easy to trade? I'm 55 for 20 or vice versa. And basically the plan here is just to use the seaport contracts, which has a version, has a basic order offering for switch for between 3.87 21 1155 It has it has every version. So there's there's no reason we can't just use all on one one contract and just use that as a dex there. So I'm not through I'm not super worried about you, you know, different token standards clashing as long as we're kind of using the main three there. So let's go ahead, please go ahead. Yeah, let's just say that kind of on the on the deposit side, there becomes this issue of, you know, how do you plan to move from a layer to, you know, if if the goal, you know, think in the long run this is going to be a problem that's going to come up more and more as more, you know, products in the being ecosystem grows and expands to layer twos, you know, So ultimately that will require a lot of kind of jiggery at the protocol level to make that possible. On the route side, you know, it it is kind of a yield bearing ERC 20 token. And if the goal was to kind of create this micro being token, which represents some fractional stable value and very easy way to do it would just, you know, while still allowing it to accrue yield would just be to wrap the root token in a micro being contract that just rebase is based on the number of routes and therefore has convertibility directly would be in, you know, through the root token. In that way it's like you have some micro balance that's increasing over time. You log back into the game, it can say, you know, you earned, you know, 2 million micro beans since you last logged on or something, but, you know, think, you know, the deposit methodology is going to be quite complicated to get started with and you know, but, but that's not to say it is you know, it is the most probably efficient option as it maintains direct exposure to the the actual underlying asset. So, you know, if if you are interested in that approach, you know, we'd be happy to talk more. And it's just important to note that it would require, you know, kind of significant modifications at the protocol level to support cross-chain planting and cross-chain mowing across the virtual machine. No, it's it's a really it's a really good question. Like if the ownership and the governance and all this stuff is happening in one chain, how how can you how can you mow on that? And I don't think there's any particular reason that there can't be a contract deployed on Main that who only has two functions and one of them is to mow on behalf of all the users. And if if that contract is the micro being wrapper, then there's there's no particular reason that can't own all the beans on main that as they're wrapped and the only thing that I can do is mow and send those the yield on to the other chain. So I don't think really are a wrapper there is, is very complex. I'm sure you and I together could figure that out in an hour. But it's a really it's a really good question and I think it will be really cool to see some more experiments as being kind of grows and goes multi-chain of of how people choose to deal with that. And I'm totally down to work on some prototypes together if you want, just not even for Pyromania, but just in general for how, how do you mow from from other places and and do so autonomously in permissioned mostly just just would say that like if if it is some wrapper contract then inherently the user no longer has direct exposure to the underlying deposit. For my understanding, this is pretty much how the token works, where it serves as sort of like an aggregator, where you know now pretty much everyone is own some fractional share of the same shared account to allow it to be easily composable and fungible, removing the need for anyone to mow or plant at the individual level. And it introduces this kind of collective farming where everyone is kind of sharing the same silo account and has some fractional ownership of that. So if if that is the goal and to provide simplicity through some sort of micro being token, you know, think leveraging the existing root contract would be great to prevent kind of duplication of that work. Okay. And are you saying that you're saying that's not ideal for some reason? Because. No, I'm saying that. No, I've I've, I've always kind of thought about, you know, yields yield for a Dow is on one chain, but it wants to yield farm on another and we'll just we'll just deploy a wrapper that owns everything. And all I can do is send the profits across the bridge to the to the Dow or what have you. Yeah, that's a good question. Not saying it's not ideal. It certainly works. There is just like one small caveat which, you know, might not really matter to users and you know, how much it matters to certain people varies. And that caveat is once you introduce this kind of collecting collective farming, you know, now users no longer have direct exposure to the exact deposits, you know, So if I you know, if I if me and you are combining a deposit, say you're deposit season 4000. I have a deposit in season 5000 now we collectively combine them and mint some sort of proportional share token. You know first off how many tokens do we meant to each other. And in this instance, you having an older deposit would be contributing more grown stock to the pool than I am. However, we're contributing to the same amount of BTV, you know, as stock is a nonfungible token that really doesn't have any sort of price tag. It's hard to kind of determine should you get more, you know, of this proportional share token or should we get the same? How does this wrapper token denominate, you know, the body of the contract? And if you get more because you have an older deposit, why would I ever contribute my later deposit when the underlying value of the deposit in terms of beans is the same? So it ultimately, you know, introduces several, several different problems where it's like either direct exposure is maintained to kind of the the exact deposit. But but you know, kind of or it's like we somehow take some sort of average and one of us gets penalized. Either you get penalized, you don't get the benefit of that extra grown stock or I get penalized in the fact that, you know, I don't get a direct mapping to the actual BTV. And, you know, deposits are most similar to an 1155 token because there is this one, you know, variable action to the token, which is how much grown stock have you accrued on top of it. So just the nature in the an ERC 20 token is obviously a single token where there's kind of no variable associated with the token. So just the nature of reducing some one dimensional token, you know, where there's one dimension on which the it can vary being the idea in the case of a deposit the season into a token where like an NFC token where it's there is no dimension on which it varies, there's a single token, you know, inherently there's going to be some, some sort of loss of, you know, ownership such that you lose that direct exposure. But, you know, it should be noted that it's unclear, you know, how how actually impactful that is. And, you know, I think Root has done a really good job of trying to make it as fair as possible while still maintaining scalability. You know, in a sense that I believe the way the new token root token works is, you know, when you convert root back to be in, you automatically with you get the worst deposit that root has, you know, such that existing token holders are not necessarily taking advantage of the worst deposit in terms of the lowest grown stock. And, you know, when it's minted it mints deposits based on the BTV. So, you know, again, I think it's a great system and it works very well. And it just there is that that little bit of loss and it's kind of a very small caveat that's that you know, could be considered quite marginal. But it depends on who you're asking now It's it's a really it's, it's it's nuanced. I hadn't really considered that. So, you know, thank you for bringing up the difference between the wrapper and, you know, giving everyone a proportional amount. It it is it would be super simplified to just use to just use being you know, and then you don't have to worry about what I am that being was minted or or you know the differences in in stock. So yeah it's definitely it's definitely will be a balance between keeping it as simple as possible just to get it out and ship a prototype really soon. But I'm happy to talk more about that. And I definitely don't want to penalize anyone for joining later. Right? Totally. And I would just say, you know, if you know, from a simplicity perspective, I would argue that using route is, you know, marginally more difficult than using being in the sense that, you know, in both cases you're dealing with an ERC 20 token. So, you know, if you know, to keep things simple, you know, it would probably like, you know, by using route you still allow users if you're game to have access to kind of silo yield over time and wouldn't have to overcomplicate things by getting involved with, you know, managing deposits as 1155 So just would say at the very minimum I would recommend using route for that purpose. But you know, again, ultimately, you know, it's up to you and you know, if it makes sense to use being it makes sense to use being cool and all that think are there any other final, final questions for me or well, I don't want to take all the time. I don't know what other topics are You guys, can you hear me? Yes. Well, first off, there's no rush whatsoever. In fact, I feel like the one of the point of these calls is for these types of like beanstalk developer problems to be hashed out in a public setting such that they can they can be considered and answered collectively and we can all get on the same page about where we're at. So there's no rush here whatsoever from our perspective. And this is great content and appreciate you very much for being open to, to discussion. It's very exciting. I would say that based on what you said and your version of like simple versus elegant way to do this sort of wrapper, definitely, I think it probably makes sense to take a serious look at root, particularly the new root token. I'm not sure if they have a new whitepaper drop in describing the implementation or exactly where the best documentation is on the new root token, that's under audit, but I think it would be probably pretty in line with what you've been talking about. And from that perspective, then the question becomes how to best facilitate a market for early 2020 and 20 against 1155 for a year for the Dex, for your game, and maybe just want to spend a minute talking about Opensea versus tractor pull because there's been a lot of work going into building a an extension of depot and pipeline that effectively allows for multiparty transactions. And I think that in practice, the implementation of a Dex like you're describing is probably within the scope of tractor development in terms of the timeline that you've been talking about for your games. So maybe you just talk a little bit about tractor versus Opensea and what might make sense given what she's building. Yeah, just just to add one one thing there before you do, I don't want to interrupt, but it's not it's not Opensea, right. Seaport is a protocol on its own. Excuse me. Not there's no series. There's no rules to opensea just for the record of people listening as it's on its on chain. Anyone can deploy it anywhere and use it how they like. Great Correction. Apologies. Thank you. Yeah. So appreciate you bringing that up. Fushi You know, Tractor is very loosely based on Seaport, you know, the inspiration from tractor comes from kind of seaport and really thinking about you know what currently the seaport allow seaport currently allows users to exchange at least one of ERC 20 1155 or 721. You know, the three main on chain token standards for at least one of those three standards. And it creates a very generalized interface for exchanging value on chain where, you know, we we you know, in our kind of research, you know, we're we've discovered seaport is noticeably lacking in its ability to extend functionality be on base asset transfers. You know there there is a demand to be able to do more than just exchange ERC 20 tokens in a you know in order for in some fulfillment of an order. So what tractor does is it takes everything that's possible and seaport is possible with tractor, but seaport or but tractor provides access to pipeline through the ability to add pipe calls such that as a part of this transaction where value is being transferred, you know, the the fulfillment, the order can have access to pretty much all of defi. So say I wanted to, you know, say you wanted to exchange, you wanted to, you know, sell a plot for beans and you only want beans and I have a bean deposit I could fulfill your tractor order with, you know, like some sort of withdrawal. Let's assume the withdrawal time. Zero. I could fulfill your order with a withdraw and send you beans such that you receive beans. But at the start of the transaction, I didn't have beans at all. I'm performing this withdrawal action in order to get beans. And that can be encoded in the order. And you know, this also helps with complex pricing and, you know, kind of variable constraints on when orders are valid. You know, one one common use case that's brought up a lot is exchanging pods for deposits, you know, really allowing the unlocking the liquidity that's locked in the silo to have access to a variety of financial markets and let's assume deposits implement some 1155 interface. And you know, on Seaport, it is my understanding that when you create an order to buy in 1155 contract, you just specify which IDs through the use of some Merkle proof or Merkle tree to specify by which 1150 fives you're willing to accept. Now, in the case of deposits and someone selling a plot for deposits, you know, they may want to price grown stocks somehow such that if I have two deposits, one has an extra 20% grown stock. You know, you may be willing to accept the less of the deposit with grown stock then the deposit with, you know, less stock. And so some kind of arbitrary pricing function can be encoded into tractor such that you can have some kind of Y equals M X plus B, where you know, B is the the value, what you're willing to value the the vet. And you know, X is the amount of grown stock in M is inherently the price of growing stock you're willing to accept. On the pod side, you may, you know, you now want to determine the user is, but you know, buying some amounts of your your plot and you may want to price that plot differently based on what part they're buying. Again, through tractor, you can encode some generalized pricing function that, you know, perhaps also has some Y equals M X plus B format or some power format or some polynomial format, whatever's desired. But you can encode different parts of the plot to be priced at different places. But you know, kind of in just in general it extends. So I guess, yeah, I'm not sure how coherent that was, but I gave it a good effort, you know. But in general, the idea behind Tractor is to do everything that Seaport can do and more by extending the functionality for which, you know, an order can can be comprised of to anything on chain within DEFI and you know that being said track your current state is you know is that it's you know kind of there's some some prerelease version ready for kind of review and testing and with the hope to get that into audit sooner rather than later. You know but most of the development focus seems to be on the wells for now. Now to talk about the the big problem with, you know, systems like Tractor and Seaport is that there's no on chain order book solution. Now, it is my understanding that seaport runs some sort of centralized order book that exists on, you know, some server that they own. And orders are in the form of IP 75 signatures for both seaport and tractor. And there needs to be some sort of order book which takes in all of the orders, determines whether they're valid or not, and then reports that back to the UI, obviously the UI can do it itself, but you know, there does seem to be a fair amount of nuanced computation in there. So curious from, from your perspective, fishy. Have you thought much about kind of the order book problem and you know how that relates to Seaport or you know, how how are you thinking about handling on a no worries if you haven't quite got there. Just curious to see where you guys are at. And I mean, that was that was really cool. Thank you for the overview about tractor like like you said, it's just kind of getting started and most of the focus is on Wells right now. I think. So. I haven't like I'm not familiar with Tractor or what it does. I am very familiar. I was in the Katrina for Seaport being there on it, and so I'm much more familiar with that. I do think a lot of the things you've mentioned are already possible with sea port, for example, unlocking beans or having some equivalent that you get, that you unlock the beans on chain and then give someone beans at the end of their order. I think you can do you can do a lot of that with a customs zone now that zones have hooks in sea port 1.2. So I, you know, my preference on creating a stable, scalable product is going to be use sea port that already has, you know, billions of dollars of volume going through it and has already been audited by literally everyone in the whole world who knows how to do an audit and has that a higher level of security right now. And if there's if there's custom versions of that or some version has some code in tractor on top of the basic sea port order flow stuff, you know, it's cool. We can we can talk about that. But I mean, I think I think for such a core feature, it's going to be pretty unlikely that we use any code before it's been audited very heavily and really proven itself the way that sea port has. And then to just like, where do you do the order book yet to be determined. It's super easy to do it off chain on just like a serverless or even like a as simple as a virtual app. It's like incredibly easy and there's already a sea port SDK and these JavaScript libraries that make doing that incredibly easy, and you don't really have to think about it. Or I can just give that to, you know, a junior frontend developer and I don't have to teach them anything about Web three because the JavaScript libraries are already built. So a lot, a lot of kind of what I'm thinking there is just how do we get to market faster and give everybody the powers and tools of divine Web three in an actually fun game. And I want to spend as little time as possible thinking about the defi aspects and let being do the stablecoin for us. Let seaport do the marketplace for us and spend as much time as possible making a fun game. So in terms of decentralizing the order book, I don't have a plan for that right now. If someone wants to contribute and convince the future community of Borromeo that we need to decentralize the order book and come up with a solution for that, cool. Like that's that's something that we can do. But like the timeline on that is not probably soon and I'm never I'm never going to like pretend and say that like we're going to decentralize this whole stuff. And, you know, I don't I don't think that's honest to say. There's I don't know any NFT marketplace that's successful right now that has a decentralized order book. But maybe will we'll start to see some of those in 2023. I hope so. Not too familiar with seaport zones, but looking into their documentation right now, it seems like they zones contain a view function that determines whether the the order is valid. You know, kind of the problem that tractor's trying to solve is generic function execution view or non view, I guess. Could you walk us through first off, is that understanding of zones correct in that it only allows execution in a few functions or is there some other way through seaport to perform generalized execution? Yeah. So in the seaport that's deployed right now that everyone's using is like 1.1 and it only supports what is shown in their docks, which is that one view function. And then in the next version and 1.2, that is done, but I don't think it's been deployed yet. Maybe like their code or you know, for that finished this past week like literally a few days ago. I think then it adds to the zone a external function that you can you can make arbitrary calls so could do something that's like, oh, the zone just checks the order. Right now the zone just says, yes, this order is valid. I'm not paused. And if there's a protocol issue or a security vulnerability, you can pause the zone and have that function that you function return false and then or throw an error. And then that will stop or stop orders that are using that end zone from from completing. But there is there is a new added way. I don't I'm looking at I'm just pulling up their docks right now and I think they're a little behind on it, to be honest. But there is like an arbitrary execution there. So you could reward someone, you know, one NFT marketplace, one looks rather token for every volume of ether, for every one it's going through your marketplace or, you know, arbitrary, arbitrary things like that. So I think you could just call, mow or call whatever whatever you needed there. I'm fairly certain you could you could do that inside of while the order is executing. I don't know what, what the what the gas for that would look like if it would be too crazy though. But it's something to look at. Yes, definitely Appreciate you bringing up this to us. You know, I mean, if if sea Port can already do everything we need it to do, then you know that that is fantastic and great news. You know, it doesn't have to all be done internally, you know? You know, I guess, you know, probably on this end, going to have to spend some more time looking at it. But from from what you're saying, it seems like it would be possible to, you know, do something like transfer some 20 tokens to a zone and then through this generalized function execution, do something like, you know, deposit into of a, you know, as collateral, take out a loan and then transplant you. Yeah. Awesome. And so you can even see the pipeline itself so you know which which would be awesome. So if, if everything you're saying is true like that's, that's great news as far as I'm concerned. And you know, I think it's very relevant to what's been discussed on the last few days of calls. And, you know, it now seems like, you know, going to have to do a deep dive into this contract. You know, And I really appreciate your your your your thoughts here to make sure that, you know, two CFC port supports everything that, you know, is intended to be supported. Three track there and you know and and all that really from my perspective needs to be handled is you know some sort of generalized, you know, execution flow such that any value in your account can be unlocked to perform any sort of action within DEFI and for that to be properly permissioned by both parties involved in the order, you know as well as proper, you know, allocating into the message, you know, to the person who created the function or created the order. You know, one thing that you know, tractor can do is, you know, basically, you know, copy and paste call data, you know, from the message that sender address into the order so that it can perform some sort of variable execution logic on that front. And we just need to make sure that there's some way to I mean, I guess the zone address and the function call, you know, that that the user, you know, that is a part of the order that's input by the person that's specified by the person creating the order, Right? Yes. And all of these every everything like that is when you create when you create the order. So that's that's stored off chain for most NFT marketplaces right now. Totally awesome. And and what if somewhere in that call data you know, wanted to you know, some in this generic function call wanted to set one of the addresses to be the person fulfilling the transaction should that be possible. Well, I mean, I don't have the code in front of me right now. I'm going to I would have no worries at all that. No worries, really. I just I just put in the in the Barnyard chat zero Age is like the architect or seaport posted a thread like ten days ago or two weeks now, I guess about more powerful zones and being able to make stateful calls after token transfers so that that's probably a good starting place if you're interested in learning more there. But yeah, in terms of like where, how that relates to Peroni, Yeah, it's super, super early to start talking about that particular implementation and how we're going to handle that totally and appreciate you kind of giving us that context. And also, you know, just in general, you know, the only reason Tractor is being created is because, you know, sea port, its predecessor, was not properly generalized to be able to do anything. And now hearing that there might be a sea port version that does what tractor intends to do, you know, is great news. Yeah. So save everybody engineering hours. You know exactly. That's the goal of you know kind of building a properly composable on chain you know tech stack and you know really, really excited to hear that, you know, sea port has been pushing that kind of forward. So you know definitely on this person they need to do some looking into these contracts and you know would appreciate it if you know other developers on this call would do the same and really just kind of look into the logic of sea port and truly see if, you know, everything someone could possibly want to do within a transaction is possible within the sea port. 1.2 UPDATE You know, because and if so, you know, being able to leverage their existing, you know, developer documentation, their existing SDK would be, you know, a huge, a huge leap, you know, for for the ecosystem overall. And so I appreciate you bringing this to all of our attentions. Yeah yeah happy to fun conversation actually. So to summarize on the economic front, I think it probably makes the most sense for you to use routes. And then on the order book side, this sea port 1.2 sounds like a wonderful solution. So hopefully this has some, some clarity on some of the stuff you raised. Do we want to talk about like a dedicated Arbitron bridge for loops? What it I mean, there's already a Arbitron bridge, right? Like you can just send things across whatever your route is. Or perhaps maybe I misunderstood your question around some sort of like DAO ratified version of a micro being. Are you talking about something other than than like an approved and approved wrapper on Arbitron or what? What was it that you were hoping to get like ratification of? Yeah, I don't have an agenda for that. I just have this is something we're going to have micro being. It's going to be some kind of wrapped being asset. It's going to be on RH or Nova. What do you think about that? And really I'm really just here for for feedback and to just like sell the ideas. But I don't I don't have a particular plan and, you know, I, I'm posting about Perro, MIA and Mr. Manifold and Yung Mask and other Gain Community members are encouraging me to join this call and learn learn more there. I think it would be really cool if we had a micro being wrapper and it was linked somewhere in the being being the money docs. And we said, Hey, this is like the official micro being of Arbitron, Nova and like there's only one way to do that, right? If we have an official token and we use the the standard bridge, it will create whatever address it creates. I don't know if it's deterministic or create through or what, but yeah, I don't know. I mean, to this point, I think your proposal, but yeah, to this point where you're really looking for a some sort of rebasing version of route so route becomes this erc20 wrapper and then you're trying to then rebase the wrapper effectively to assume that people earn more micro beings over time. Well, I think that's something that one of the other clubs has suggested today. Well, I'm also suggesting now that it would make make sense. All right. Yeah. If you think that makes a lot of sense, that's really helpful feedback for me. Yeah. Because then you can offer, like, everything is denominated in micro being when people go to, like, either exit the system or just redeem into being stuck in whatever capacity, like they'll they'll have the bills that they thought they had. And there is some notion of friction around leaving the root system based on the way the route contracts are currently architected. But to some extent that would probably just add a little bit of friction on leaving your game in practice. We can dive a little bit deeper into some of the economics around that. If you think like a marginal cost to leave the system entirely, as you know, but stay within being stock is too high of a marginal cost. But frankly, based on the way you've described, you know, the the user experience that you're trying to create, I don't think that would be meaningful, assuming that's the case, feel like this is like pretty much definitely the right way to go forward. And then there's just a question as to, you know, getting some sort of development from the Bienstock side if necessary, to help to help you out with the rebasing. But it should be pretty basic. Okay. I'm glad I'm glad you think all of that is basic. Oh, it's great. It's all relative, you know? Yeah. Yeah, it's it's definitely, definitely don't write any of the code. So maybe it's one of those blissfully ignorant issues. Yeah. Well, thank, thank you for that. So on, on the bridging fund, you know, believe that, you know, root, root is currently on, you know, regular arbitrage. I think it was part of the paradox thing, but believe it was just bridged directly over using the arbitrage standard bridge where, you know, it does deploy some canonical token at some deterministic address. There was kind of one problem that came up though, and that's it didn't seem like the Arbitron native Bridge and I guess not sure how much this actually matters for token deployment. Probably not at all. But there was some problem with the arbitrage. Native bridge would not allow you to one set the address the the recipient address the bridge and to execute some sort of on chain function after the you know, after the tokens were bridged. And where where this functionality was kind of desired was the ability to perform some kind of cross, you know, virtual machine transaction where someone, you know, who holds ether on layer one may want to using pipeline, you know, swap that if into root, you know, on layer one, send that root into the bridge and then upon receiving the roots on the other side have those roots go directly into a pipeline contract on arbitrage and then the bridge would, you know, kind of follow that up with some kind of hook where it would call Pipeline to then place a bet and transfer the bet tokens to the user's address? You know, and upon reflecting on it as I'm talking, you know, don't think this has any impact on the actual token implementation and just don't think it you know, would would warrant not using the arbitrage native bridge you know to bridge you know route and or being over to arbitrage Nova. But you know, I guess, you know, the question becomes, you know, kind of is there any desire need to use a custom implementation on arbitrage instead of the implementation that is provided by the bridge? And that's why that's another reason that having a wrapper for micro being is if that is deployed on NOVA, then you can just bridge whatever assets on the basic bridge. And yeah, the contract that they deploy is kind of vanilla and shitty, but you can just wrap it into micro being that has whatever other features, whatever other you know, flexibility and extensive extensibility that you need. So I think that's another point in favor of like actually having, having another token that whatever, whatever, be an asset we want to bridge over actually gets wrapped into something else. So I hope that makes sense. Yes, totally makes sense. You know, unfortunately not too familiar with arbitrage as implementation of the RC 20 token, so I'm not too familiar with its functionality. But yeah, agree that, you know, if there were some micro being implementation, any sort of custom functionality, desire to for this token to have could be implemented at that token level. And you know the canonical route token could be that you know basic implementation deployed by the arbitrage bridge and you know customizability can be built, you know introduced at the micro being level, right. Why wouldn't, why wouldn't the micro being contract be deployed on main that to wrap routes on main that. And then it could also then just be bridged over. Well I think the blue bias number two was saying you know maybe you want custom features there, maybe you want to be able to call multiple contracts at the time that you bridge it over. So and but instead of doing that at the time that you bridge it over, could be at the time that you wrap. Right. And then you're calling get this from the bridge, call this Dex, whatever, whatever you want there, do you as you do, you know, if you can kind of have the arbitrage bridge use a custom solution or does the you know, the main arbitrage bridge only allow deployment of their kind of custom contract. For instance, if a micro being implementation was deployed on both Arbitron and Nova and made that such that it's up to the user do they want to perform this wrapping you know on main that or arbitrage Nova would there somehow be some way to link those two contracts through the bridge? I, I don't know about that, but I seriously doubt that there is. I can ask the arbitrage based dev folks that are kind of like helping us a bit about if there's a possibility to do that. There definitely is not the ability to do that. If you just do like the regular bridge, like just their standard standard standard token across our origin for the first time. But I don't know if it would be possible if we asked them for help. Yeah, I kind of doubt it, but it's it's possible, I guess. Maybe I can. I guess I'm curious. Yeah, that would be. Appreciate it. I mean, curious to know what kind of usdc and tether, you know, have done. I mean, you know, imagine Usdc is going to need a custom contract on every chain. As you know, blacklisting is one of the functions they need to be able to support. And, you know, so either so then, you know, that would either imply that all the usdc that's being bridged is using some alternative bridge, you know, and maybe that's what arbitrage solution is, is kind of, you know, create your own custom gateway for that. But yeah, definitely something to look into and explore because in this perspective, the best user interface for micro being would be to be able to wrap it on either side so that just the most functional, right? Yeah, I mean the most and gives the most power and flexibility to the user, which is the entire the entire goal is that you actually own your assets and have that kind of flexibility. I do have to run in 3 minutes, but thank you for all the other question and stuff. Was there any like final final thoughts for me or anything else that I can help with? I mean, on this end, you know, I think this was an incredibly productive conversation and, you know, hopefully will serve as kind of, you know, I think, you know, a lot of kind of, you know, kind of the philosophy of, you know, how being stock, you know, kind of, you know, spreads its routes across, you know, different chains and virtual machines is, you know a very challenging problem. So I appreciate you taking the time today to come discuss that with us and kind of start to our idea about different solutions that, you know, being stuck, you know, and being can use in order to achieve that. And, you know, really, really excited to hear about, you know, your project that you're working on and you know. Appreciate you coming on the call today. Yeah, thank you. And I really appreciate the feedback and and ideas from from everybody really. So thank you Thank you for the time and giving me the chance to to ask a few questions to would just comment that it would be great to have you come back in a couple of weeks and continue this conversation once you have more answers to some of the questions that have been asked today. And we can just continue to publicly figure things out together, whether that's in a week or two, whenever you feel like you want to do that. But from our perspective, this is exactly what these dev calls are supposed to be used for. And really appreciate you coming here and just chopping it up with us and figuring some stuff out. Yeah, Thank you. And also, this is the first time that we've had any public event or anything for Oromia. So everybody listening, you're you're in you're in the front row here rather cheering for me to be on it. Congratulations. Thank you. Thank you. And we're building in the open. Like I said, we're going to launch the first kind of iteration of a few parts of the economics and the tokens and a few things that you Denver. So be on the look out for that and we're building in the open. Things will be open sourced as soon as they're available and I will be sharing updates. Will you be at to Denver? I will be under another pseudonym so oh my goodness. I don't know if you guys are all going to be where, you know, it'll be a bunch of guys and bean costumes, all with the same name tag. And we'll we'll see what you guys look like, but I'll be around. Hit me up. Brilliant. All right, Well, hopefully we'll see you there. I hope so. Up. All right. Thanks, everybody. Take care, brother. Thanks for sharing. All right. On this end, don't feel like it really makes sense to get started on another topic that the Gobi Desert conversations to really get really deep into something and not have a time limitation. So, you know, we've been running for 90 minutes and probably want to call it here unless people have certain things they wanted to talk about or discuss. But I don't think it makes sense to necessarily have a full conversation about markets and we can just save it for next hour. Call a great here. All right. Why don't we call it there then? Unless anyone has any objections, speak now or forever hold your peace. All right. Thanks. I guess I'm listening. Just would say, you know, the point Fucci made about support. 1.2 is, you know, very interesting and, you know, think, you know, kind how how these markets are ultimately implemented. You know, are you going to, you know, be shaped, you know, by, you know, kind of by whether or not, you know, it seems like that, you know, this new sea port update is capable of supporting all the functionality that will be desired. But, you know it's really exciting to hear that, you know, kind of you know, there are other teams working out, you know, out there working on kind of general Composability, which is quite exciting. A great, very exciting. Well, nothing else. I think we can wrap it up there. Thanks, everyone, for coming. Take it easy.