Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week I sit down with some of the brightest people building Web3 to talk about what they're working on right now. 0xMons is my guest on this episode. 0xMons, aka Owen, is a blockchain artist and the founder of PseudoSwap, which just launched its v2. In this conversation, Owen and I cover the big questions. Why does the world need an NFT AMM? What's new in v2? And why the reverse course on honoring ERC2981 royalties? We also role-play LPs on PseudoSwap and walk through how LPs might choose the parameters of their positions. I was particularly intrigued by the new 1155 Open Edition pools, which sound like a great fit for the bounty of NFTs minted during the most recent Open Edition meta. The new creator settings contracts, which let LPs share pool fees with NFT creators, could create more alignment between those parties. A further blurring between meme coins and additions seems inevitable. Every chance to interact with Owen is exciting, and this conversation was no exception. It was fun hearing just how heads down Owen has been the past year, learning and growing PseudoSwap in new directions. I hope you enjoy the show. If you'd like to sponsor an episode, visit web3galaxybrain.com for details. It's as simple as minting an NFT. As always, this show is provided for entertainment and education purposes only and does not constitute financial advice or any form of endorsement or suggestion. Crypto is risky and you alone are responsible for doing your research and making your own decisions. Now onto the show. Hey Owen, how's it going?

0xmons: Yo, Nicholas. Thanks for having me on. Of course.

Nicholas: Welcome. I'm super excited. You're like a major guest on CT, no doubt. Everyone's excited to hear from you.

0xmons: That's very flattering. I've been locked up in an apartment for a while, but I'm out again.

Nicholas: It's nice. Is that the development prison? Yeah. I want to know, are you the only dev working on the protocol or are there other people working on the smart contracts with you?

0xmons: No, no. So there's three authors on the smart contracts. So there's Saigar, Zephram and me. And then the authors are all on the source code, which is verified on GitHub. And I think we'll be opening up like the repo and putting that all up on GitHub today so people can take a look at the arduous set of tests and things set up. But yeah, those are the three people who worked on the protocol.

Nicholas: Tests are brutal, right? It takes so long.

0xmons: Oh my God. Freaking tests. And I'm sure we'll get into this for the protocol stuff, but because for the pools, right, we have like 721, 1155 support, ETH and then ERC20. There's like this huge matrix of combinations. So trying to like exhaustively get all of that running was also gross.

Nicholas: So maybe we can just jump in and talk about some of the technical stuff about building it. So is it written against Foundry, I presume Forge?

0xmons: Yep, yep. So project is built with Foundry. There's like some minor fuzzing again for the bonding curve stuff for the math parts, but rest of it is just like scenarios set up in Forge for tests.

Nicholas: I've done a fair amount of fuzzing, but I've never done invariant testing in Forge. Is that something that you make use of?

0xmons: Not for this set of tests, just fuzzing. I think that like runtime concerns were an issue. Just some of the stuff like wasn't terminating. And maybe that's fixed now. Or we could have like scoped the test better. But no, not for this release.

Nicholas: Got it. Well, I guess we should start our conversation properly. In a world of off-chain order books, why do we need an NFT AMM in the first place?

0xmons: So I think the biggest reason is that there can be data loss. So if you are just talking about a reliability standpoint, when like sites go down, and I feel like the AWS outage recently is actually a great example. You want to be able to ensure liveness of orders. So having on-chain promotes that in the sense that you don't have to rely on a specific client or service provider to fill the orders. That's sort of like the easy answer.

Nicholas: Because the order books, the off-chain order books, the orders are on some server somewhere.

0xmons: Right, right.

Nicholas: But actually, we'll get into all the details, but with sudo v2, and maybe even with v1, you do need to do some off-chain processing of, I guess, events emitted from on-chain transactions in order to construct the route, right? You need to supply the route when you go to make a swap?

0xmons: Yeah, yeah. So the way that the events are emitted for the assets themselves in v1, there is some bookkeeping. So you can, in certain cases, figure out like which IDs are in a pool. For v2, you're going to have to be listening to transfer events or querying balances to figure out what's listed. So that is the indexing component.

Nicholas: Is that something you think you'll open source as well?

0xmons: So there's a subgraph set up to track, and then Defined, who has been really great in providing API, has that. So it's actually, we have some stuff that we run in-house, but there's also other providers listening to the blockchain stuff. So I think that the index that we have might not actually even be as robust as some of these other options, but certainly something that we can look into setting up in the future if people were so inclined.

Nicholas: Got it. So one reason why NFTMM is interesting is just uptime, on-chain, unstoppable way to trade NFTs. But there's other advantages too. One other thing that comes to mind is NFTX, which offers in some ways has some overlapping features with sudo even v1. But what do you think makes there room for both of these things to exist in the world? What makes sudo worthwhile in a context where NFTX exists already?

0xmons: Yeah, I'd say that one of the things that is difficult to do for a lot of NFTMMs is supporting orders, both large and small. If you just have one or two assets and you want to list them and you just want to take profit when they sell, this is difficult to do in a shared pooling style or even in general AMM cases where you would require people to put up both sides of both tokens and NFTs. So to that end, I think having the flexibility to be like, hey, I just want to put up NFTs, turn them into tokens when the price is right for me. And that's sort of the end of the story. You can do that with the sudo swap contracts. This is on top of, if you care a lot about picking the exact price ranges or how you want your prices to change, you have a whole suite of tools. if you're using the bonding curve stuff.

Nicholas: Okay, so we'll get into that in a second. And I want to walk through what the experience is like. First, just for sudo in general, and then later we'll talk about the specific new things in v2. But I guess, yeah, let's just dive in. So if I want to create a pool on sudo swap, we'll talk about the 1155s later, but I guess right now we can just talk about NFTs and think of 721s to begin with. What is the process of creating the pool like and what are the, I know there's like linear exponential and XYK constant product options. Maybe you could walk through a little bit of what that process is like for someone who wants to LP.

0xmons: Yeah. So to back up a bit, I guess one of the questions to answer is like, you know, why would you want to have a pool in the first place? Or like, you know, what is the benefit of an AMM pool? So there's, I think two reasons that you might want to have a pool. You know, one is the reason that people often have pools for other AMMs like Uniswap is if you want to earn fees off volatility, right? Like if you have a large amount of assets and you're sort of indifferent between if they're tokens or NFTs, then it could make sense to set up a pool because, you know, you can give people the option of trading between them, collect a fee on both sides. And then, you know, over time, if you are somewhat indifferent, right, you might take out like a different proportion than what you put in and then the fees that you earn would ideally offset that. So there's like the whole impermanent loss discussion, but like, you know, broadly one reason why you might want to provide liquidity is to earn fees. Another reason why you might want to set up a pool is, as I mentioned earlier, if you want to do some sort of dollar cost averaging, right? If you have like 10 NFTs and you want to just sort of ladder them out, so you know, you sell the first one at 1 ETH and then 2 ETH and 3 ETH, you know, you can set up a pool that is just selling. So then all of the NFTs will be listed and then anyone can purchase them. And then when they get sold, you know, the ETH goes straight to your wallet and then all the other ones get more expensive. You don't have to do any adjustment there. So I think those are sort of the two reasons, you know, primarily that you might be interested as a user.

Nicholas: Got it. For the second example where you're looking to DCA, I guess either into or out of an NFC collection, how would you say it would compare with like something like the ladder option on Blur, where you can set prices across a range? Is there a particular reason why we better to use pseudo in that case?

0xmons: So if you're doing a ladder thing on, you know, Blur or OpenSea, you would have to go and manually, you know, set the prices for each asset. If you have them in a pool on PseudoSwap, they're all listed at the same price to start. And then any one of them, you know, can be purchased and then the other ones will adjust. So you don't have to worry about being like, oh, you know, if this one's a slightly higher rarity, should I put this, you know, like farther end of my ladder of prices, right? You just put them all in and you're like, I want to sell from 1 ETH to 10 ETH and then the rest of it is taken care of for you.

Nicholas: So I guess because in, let's say in the Blur ladder context, if it sets them up for me at specific preset prices, but then they're purchased out of order, I'm not following the way the market is shifting. I'm now dependent on the specific traits of those NFTs, potentially in the prices that I set once, one time at the beginning.

0xmons: Mm-hmm. Mm-hmm.

Nicholas: Okay. So those are some reasons why you might want to create an LP. Is it difficult to collect fees on LPs? You know, Uniswap V3 is like infamous for it being quite hard to succeed as a liquidity provider. Is that the case, do you think, in pseudo swappers? Is it simpler because it's earlier in the NFT AMM market? or are NFT AMMs a completely different thing than fungible AMMs?

0xmons: I think that a lot of the mechanics are similar. I think that figuring out fee math has always been messy and was one of the things that I really wanted to improve on for the second version of the protocol. So there's some cool stuff happening in the math there. But basically the short answer is if you make a pull on V2, the fees just get automatically sent to your wallet on each trade. So accounting becomes a lot easier, right? You could just set them to your own wallet or another wallet if you wanted to have just like a wallet that was collecting the fees.

Nicholas: Oh, I see. Okay. That is simpler. Okay. So what's the process? Let's say we have a bunch of, I don't know, I guess Milady's are the classic or one of the most popular things. So let's say we have a bunch of NFTs and we're ready to do some ETH or even another ERC20 and we want to create an LP. What is the process for reasoning about how you might set up that LP? Because everyone creates their own for themselves, right? Everyone has an independent contract when they create a pool.

0xmons: Yeah, yeah, that's right. So the general way is probably similar to how you'd be thinking about things on Uniswap V3 in the same sense that you're picking sort of your start and end prices. So in the case of Milady's, right, if you think that it's not very likely that they're going to drop below like a 2 ETH floor, you might want to have your lowest price that you're willing to sell at be 2 ETH. And then if you think like, you know, for some time duration, they're not going to go past like 4 ETH, then you would pick that as the end of your range. And then your assets would be spread out evenly from 2 to 4 ETH, those sell prices.

Nicholas: That's what the linear option?

0xmons: You can do this with any of the options. If you go to the create pool on the new version of the app, there's an auto feature that's set up now that actually spans like from half of the floor price to 2x the floor price. So you can get generally good enough coverage over the range that you care about. But if you wanted to tweak it, like, you know, percentage wise or incremental wise, you can adjust that too. So it doesn't have to be with linear in particular.

Nicholas: And that would be if I'm providing both assets to the pool. or the automatic setting applies?

0xmons: You can. So the automatic setting will basically pick how much ETH is needed to match the NFTs in your wallet one for one. But you don't have to deposit that much. You could also just scale it back. So you're just depositing NFTs in that price range instead.

Nicholas: Got it. And you said that it'll select even half the floor price as the starting point. So immediately you're going to be selling NFTs. if someone purchases, you're going to be the lowest price.

0xmons: Oh, that was poor phrasing on my end. The buy side, if you wish to also put up tokens, it basically lets you buy all the way down to half the floor price. Yeah, yeah. But the immediate like sell price is set at the floor.

Nicholas: So if the price shifts downwards, you're still going to have exposure. Got it. Okay. And then maybe for someone who is LPEing, can you explain the maybe decision matrix of choosing linear, exponential or XYK?

0xmons: Yeah, I think that there's definitely a lot more like tweaks that can be done to like make that decision easier. I would say that one way to think about this is, you know, if you sort of think that the price ranges can vary or you like don't want to be playing, you know, like a range game, then having a behavior that behaves like, you know, you know, swap V2 would mean that you would just pick like the XYK curve, right? This sort of spans the price range from zero to infinity. And then, you know, your assets are just sort of in the middle there. So if you sort of have like very little bias, then that's probably what you would pick. The ways that I would differentiate between having linear, like a flat increase of like, say 0.1 ETH every time a trade happens or exponential, which would be a percent increase, you know, like a 10% increase each time a trade happens is to, and I'm trying to figure out like the cleanest way to phrase this, but basically like the higher the price gets, if you're doing flat increments, then like the percent change between the prices is a lot lower, right? Like if the floor price is at 1 ETH and your increments are in 0.1 ETH, then this is like a 10% increment when the floor price is near 1 ETH. But like if the floor price goes up to 10 ETH, then as you go up by like 0.1, right? Like the percentage difference between your marginal prices goes down. So the flat increment has that property. Whereas if you always want to have, you know, like a fixed percent difference between your marginal prices, then you'd be picking an exponential curve.

Nicholas: I see. I see. So maybe if you anticipate that the price is not going to move a lot, maybe the linear option makes sense?

0xmons: So if you think, yeah, yeah.

Nicholas: That roughly, okay. And when would the X times Y equals K be an appropriate choice?

0xmons: So I think that if you like just don't want to like have to worry about your pool for a while, yeah.

Nicholas: Got it. Okay. And I was curious on a technical level, why is it that every pool has to have its own new contract? I assume it's because you can't intermingle people's assets?

0xmons: Yeah. So if you were doing like a singleton, right, you'd have to, in addition, keep track of like which balances go to where. So sort of like the methods that we had explored early on contract wise just meant like additional gas because you'd have to store like who owns the assets sort of natively in the 721, which would be the singleton. And then you'd also have to store like which one of the actual accounts owns the assets. So you'd end up with like, you'd be paying extra to do this sort of double accounting. The other thing too is in terms of like customization, right, having individual pools is like a very far end of one spectrum, which is, you can change your prices at any point. You don't have to be worrying about like the global pool adjusting for you and whatever goes in and out is yours. It also makes things like claiming airdrops easier. So those are sort of like the main design decisions around having like individual pools because then like. it also makes the accounting easier, right? Because like if each pool has a different address, then like that's just stored. You don't have to do like the additional double accounting if you were in a singleton.

Nicholas: Got it. Yeah, and it is cool that you're able to and since v1 you've been able to claim airdrops. How does that work? Actually, you're able to execute some arbitrary bytecode from the making a call to the pool itself?

0xmons: Yeah, so you can make certain calls from the context of the pool. basically.

Nicholas: Okay. So do you anticipate specifically what like the claim signatures are?

0xmons: You can pass in like it's just like ABI encoded. so you can pass in like appropriate call data.

Nicholas: Okay, got it. Cool. Yeah. And that doesn't introduce security challenges?

0xmons: So it does, which is why it's restricted to. so there's like certain things that you like shouldn't be able to call. So there's like restrictions on that.

Nicholas: Okay, okay. And there's specific things that you that are on the pool contract?

0xmons: Yeah, yeah.

Nicholas: Got it. Okay, so it's not exactly not reentrant. It's just specific functions will be non-reentrant.

0xmons: Yes, although the reentrancy thing is also interesting and might be worth talking about if people want to nerd out later.

Nicholas: Please.

0xmons: Okay, okay. Well, I so I've been doing like this weekly thread series on like a series of code dives and continue to do so. But one of the things that's sort of interesting from the v2 code is having like a global reentrancy lock across all contracts. So like usually contracts will maintain their own lock state. But one of the issues with like 1155 is actually is that there's like a transfer callback. There's no like normal transfer from there's just a safe transfer from. So there was like a convoluted scenario where, you know, even if the pool itself was managing its like unlock, like the callback could call into like another pool that would also be reading from like the callers balance. So you could have gotten like double credited. So one of the important things is like if you're in any pools like swap context, you shouldn't be able to enter like another pool swap context, hence like the global reentrancy lock. And then originally, you know, there are some thoughts of like, well, is it safe to let anyone call the lock? Because like usually the ways that like the lock works is you do the check in the open lock call, right? And then you just free it and the close lock call, right? You like check if it's toggled or not on open, and then you just like free it and close. So if you're doing that pattern, right, it would be kind of messy because then you'd have to go and check like if someone had like touched the lock before you, then you might have to like do certain permissions. But if you move the like call and close lock, and this behaves like functionally the same, then you can make like the open lock call permissionless, which is just kind of like a fun side result. I don't expect like anyone else to be using the lock besides the pools. It's just sort of interesting and it saves a bit on like checking the caller gas wise.

Nicholas: Very cool. Are there any other topics that have come up in those weekly threads that come to mind that are worth discussing?

0xmons: So there's some additional composable stuff that I want to be talking about. So I'll probably be for this Sunday and then probably like some more of the interesting specifics on the router stuff.

Nicholas: Very cool. So people can follow the sudo swap account for those threads?

0xmons: It's been on the Xerox funds account for now, but definitely will be like cross sharing it across.

Nicholas: So V2 introduces a bunch of new features. One of them is property filtering and there's a few different ways that that can work. Can you explain how the property filtering functions?

0xmons: Yeah, yeah. So it's pretty flexible. The setup is just that contracts can pick a different contract to do some logic for them. So the V2 code base comes with some factories. So you can do pretty standard checks. Like if you care about doing ID set based on a Merkle route, you can do like a Merkle proof check. If you care about some ID range, like in the case of Artblocks, you can do an ID range check. But the intent of like sort of having it open is to allow people to hack things on top. If you wanted to do like a private offer, like you know, you only want to purchase NFTs owned by a certain address, you know, you could do that as well. You just write like a contract that implements the property checking interface and then does like an owner of check before returning true.

Nicholas: And that's something that would be done by the buyer?

0xmons: Yeah, so it would be done by the person making the pool.

Nicholas: By the person making the pool. Okay, so you're... Yes, yes. So let's say I wanted to do the token ID range. Let's say so I could make a pool that only allows token IDs under 100 into the pool, essentially? Yeah, yeah. Yeah. So and then I would, that would be a limitation imposed both on me as likely the first LP or the only LP because it's my pool, but also for anybody else trading against it, they wouldn't be able to sell me NFTs outside of the range.

0xmons: Right, right. So that's the restriction on the filling of the order.

Nicholas: Very cool. And like you mentioned, for people who haven't seen the docs, you can do Merkle trees to do the properties of the NFTs in the collection. So you can have trade based limitations on the pools.

0xmons: Right, this is if stuff is off chain and you wanted to make like an ID set. But also really keen, especially as like games are moving certain assets on chain. You could, you know, in certain cases, maybe just like do the verification on runtime. Like, you know, if like if some certain armor set has some property that you care about.

Nicholas: There's also creator settings contracts now, which let you share fees to creators of NFTs, if I understand correctly. How do those work?

0xmons: Right, right. So there's two, so the first one is that pools have royalty enforcement set up on the contract level. So rather than, you know, having to add in like additional transfer, if you were doing assigned orders, or like rely on some EOA to update something. There's like a broad lookup check that uses the manifold royalty registry. So you know, like for a given collection, it tells you like where you should look it up information about the royalty. And then from there, there is a royalty engine that's similar to the manifold one. The main difference is that this one isn't upgradable. Generally, like protocol wise, that's something that definitely have a bias towards. And trades will basically do like a series of lookups to figure out how much additional they should be charging to do the payout. So that's happening by default. But obviously, you know, like for certain collections where either like the creator wants to have like a lower fee environment, or if the idea of like sharing trading fees is interesting, there is this entirely new set of optional contracts for things called creator settings. So a creator setting again, is really flexible, like the property checking. So again, it's like you can delegate this out to another contract. But the basic setup is you can pick a reduced royalty percentage in exchange for some properties that like you as the creator pick. So this could be like a share of trading fees, which is sort of the canonical version that comes with this release. In which case, you know, somebody who's making a pool is like, oh, you know, I see that like the Crypto Skunk Deployer has said that, you know, if I share like a quarter of the trading fees that I earn, you know, they'll apply like a 1% royalty instead of the normal, like 5% royalty, as an example. And then, you know, you as a pool owner, you know, you can decide to opt into that if you want, or, you know, if you're fine having the royalty be applied, you know, you just keep all the fees for yourself. The exciting stuff here is that, again, it doesn't have to be like a trading fee share. It could be like, you know, literally any property you care about. It could be, you know, you only apply the reduced royalty for collectors that are on your whitelist. You could ask that like pools lock up for some duration. So, you know, the liquidity is there for some amount of time. You can even set like an upfront payment. So that way, like, you know, you care less about the trading fee share. You just want to like, you know, get another stream from like the participants. So there's a lot of room for hopefully better collaboration between creators and LPs.

Nicholas: That's interesting. So I know there were a bunch of collections early on in the V1 where people were creating collections specifically for distribution on sudo. So I guess this kind of supercharges what they're able to do with that. They could, for instance, not charge royalties, but instead collect fees directly on their own pool or do a similar deal with other people creating their own pools to give an incentive for people to trade through sudo. And maybe, can you explain a little bit about what the logic is of like a sudo maxi NFT project? How they would maybe in the first case, like if they wanted to do the issuance essentially through sudo, how that's approached and then maybe after how they can go about using these creator settings to incentivize people to trade through pools and collect fees that way. In the first case, just how, if I'm an NFT creator and I'm like, yeah, I agree with the sudo model. What strategies are there that I could use to really make the most of it?

0xmons: Yeah. So the issuance can certainly be done using a pool if you wanted to. I'm definitely sympathetic to like, you know, many collections having a more tailored minting process. So, you know, like definitely however primary issuance is done, whether that's like listing through a pool or, you know, like auctioning off or doing some sort of like direct minting on your pool. You know, the second setup is, you know, if you wanted to encourage users to trade, you could have a setup where, you know, you set up like some royalty or fee recipient that receives ETH when trades happen and then sets those up to go to like a pool. So this way, if the pool has like both NFTs and ETH, you know, you can like increase the ETH portion as trades happen, which has the effect of like increasing both the buy and sell price of the pool. So if you're trying to go for like a, you know, like protocol and liquidity or like rising floor kind of setup, that's sort of what you would do, right? You would just set fees or like revenue in some way to a pool and then you would like adjust the prices, the fees come in. If you wanted to also then

Nicholas: encourage like

0xmons: liquidity, you could go through the settings factory, set up a setting where you're like, you know, for example, waiving the royalty fee, deciding instead to take like 10% of trading fees and then again set that recipient to be sort of the pool that you own. that's got like the increasing backing price.

Nicholas: Very cool. So you can establish some revenues from the issuance or from secondary market that is applying royalties, pipe that into the pool and that kind of pumps the pool price for the tokens. And then you could even disable, choose to disable royalties or decrease royalties on trades that are done through sudo and instead take

0xmons: fees

Nicholas: as to take profits, for example, to the creators while it's directly on every trade to kind of encourage people to trade through sudo and increase the price. Very cool. We talked about it a little bit before, but V2 also introduces 1155s. That must have been complicated.

0xmons: It's not something I would wish on anyone, but I'm glad that it's set up. Yeah, definitely like basically double the amount of work we had to do for all the tests.

Nicholas: For just one bullet point on the website.

0xmons: Yeah, so 1155 stuff is really exciting. If people haven't played around with the site, you can, for a specific ID, set up purchases or sells. For a lot of collections, there's a lot of price disparity between the different IDs. So the pools are keyed in for a specific ID. Like Parallels is going to be probably the paramount example where you have very big price differentials between the different cards. So in this case, it makes a lot of sense to tailor your offers for a specific card rather than filling anything in the collection by default.

Nicholas: So this is really perfect for the open edition meta. So maybe if people aren't familiar, like Zora and for in some cases, the manifold contracts, like I think especially their burn to redeem are 1155s. So all of those would be pretty good place for this. And it seems to me like it would make a lot of sense, especially for these huge Zora issuance events where there's so many tokens. It doesn't maybe make as much sense for it to be on OpenSea.

0xmons: Definitely making sure that the checkout and stuff is all handled smoothly where, you know, having like one page to sort of view the assets and then abstracting the checkout behind the scenes versus, you know, seeing like a whole grid of like the same asset. That's definitely like part of the decision and trying to make 1155s more friendly on the site for sure. Yeah.

Nicholas: Do you think Zora will integrate it into their front end? Could be an interesting secondary for them.

0xmons: So if anyone listening here has more contacts in Zora, please let me know. We did talk with one person at Zora who mentioned that at least on their collect page, they're pulling from Reservoir at the moment. So some of the v2 listings have been picked up on Reservoir, but I think just the 721 stuff. So I think still some more work if 1155s are the way they end up going. But definitely like an ongoing effort in us trying to, you know, talk more with Reservoir about what else is needed for indexing. And then if there's like separate ways people want to tap into the data, I dropped like this small package that uses defined. A few days ago, people wanted to like pull info programmatically about how things are priced. that allows you to specify like a given 721 or 1155. So that's up on like GitHub and npm for people if they wanted to pull quoting. Otherwise, if anyone else knows Jacob from Zora, please strongly, what is the word? Request. Yes.

Nicholas: This makes me want to ask a question about aggregators. I guess the aggregator meta has changed in a lot of ways since v1 dropped. How do you think about sudo with relationship to things like blur, OpenSeaPro or other aggregators out there? Is it just like another good thing that they should all be indexing?

0xmons: I think that, yeah, I mean, obviously, I'm very biased in this regard, right? I think it's definitely something that users would prefer. I think more broadly, the aggregator stuff is, I feel like it's definitely brought a lot of convenience to people. Where, you know, plurality of marketplaces means that prices fracture. I do think that there is some room to be creating more tailored experiences for certain types of checkout. So that's something that's on my mind, as well as thinking about, you know, when there's a lot of places to list, what are other things you could be doing with your sudo swap LP position that could make it more attractive? One of the things that Abacus had done, which was pretty neat, it's really unfortunate that I think they're winding down, was like letting users, you know, take out a loan against like various positions in NFT AMMs. So that's where my thinking is at. I don't think that it's like, you know, been net negative necessarily that aggregators are driving a lot of the usage at the moment.

Nicholas: Right. I want to rewind, actually, I forgot to ask, you know, V1 was sort of famous for not honoring royalties. I'm curious why the change of direction for V2?

0xmons: Yeah, I think that the discussion has shifted dramatically since last year. But sort of reiterating, right, like the thinking going into setting up protocol was like, okay, from a liquidity first perspective, what are ways that protocol and liquidity can work? What are ways to make this sort of like a backbone for launches and markets? And for certain collections, this is a really great fit. And for certain collections or for artists, right, this wasn't the thing they wanted. So it's definitely a question that I thought a lot about. And I think like, I don't know if it's the correct answer, but sort of I think like an answer that is very tenable is that it's sort of like up to the asset issuer. And ideally, you know, if collections or like this collection owners, you know, want to encourage liquidity, you know, make tools to have that be possible, but, you know, not making that sort of the sort of default. And that's sort of where the thinking around all this collection setting stuff came from. Right. So, you know, how do you get something that, you know, behaves really well in like a low fee environment while also, you know, ensuring that, you know, asset issuers can feel like excited about doing so if they're like also getting, you know, like a cutoff volume while not necessarily having to manage a pool themselves.

Nicholas: Right. I guess one thing that comes to mind is that the, I mean, Blur has now, is now, are they still honoring 0.5% royalties or has it increased since then? I know they were planning to increase every few weeks, but do you think pseudo with full royalties by default will have, V2, will have, will it be the floor price or will there be markets that are not honoring royalties that will be below the pseudo price as a result?

0xmons: I definitely think the like price competitiveness for certain assets isn't going to be reaching parity sort of like by design. I think that for like collections where like settings can be set up, then you can get stuff that's competitive and like the optimistic case, right? The sense of being a lot of the stuff that is well traded. For the other assets where there like isn't parity, I think that that is sort of a compromise that comes with moving to the protocol. My thinking here is more about like some of the other stuff that I mentioned where like, you know, how else can you make it attractive for people to be setting up and using pools in different ways? Sort of like expanding the utility there on the protocol side.

Nicholas: Right. Maybe some simple way for NFT collection creators to do a swap out there. I always think of the Indiana Jones thing where he puts the bag of sand for the idol before the big ball rolls after him. If they choose to, maybe a simple interface for choosing to do something else, take fees for instance, would help them along.

0xmons: Yeah.

Nicholas: If you were Uniswap, would you be building pseudo swap? Is there a difference in philosophy between Uniswap and the way you've approached pseudo swap? Or do you think this is the kind of thing that, is there a platonic ideal NFT AMM and that's what you're aiming for? Or are there many specific choices that make it something that's a product of your taste and your team's taste?

0xmons: I definitely think that there are many trade-offs, right? Like even between token to token AMMs, there are a lot of different conscious design choices that are made. One of the main things that drives the protocol design for the pseudo swap AMM is configurability. So making it possible for people to choose different prices for things, as well as being able to hack on top. So providing ways of redirecting where assets get sent, providing ways of sourcing pricing information. And I think those are the main things that form the design. And certain things are going to happen as a result. I'm not going to be as arrogant as to speak on behalf of the entire Uniswap team. I feel like everyone is probably still digesting exactly how hooks can play into things. But I will say that a lot of the same ideas behind minimizing governance, moving that to something on-chain, removing upgradability, a lot of those ideas that power the v2 deployment. And that sort of spirit is definitely something that's really top of mind for me.

Nicholas: Got it. Is there anything stopping Uniswap from copy-pasting pseudo swap and offering it on their site as a Uniswap product? Not that that's the kind of thing that they would do, really. But do you think about that? Is there something about the pools that makes it harder for a transition like that? Or is there anything sticky in particular about pseudo swap?

0xmons: I think that the real sort of test of this is how things shape up for the next six months. And speaking a bit more forward-looking, if I think that there's a lot of cool integrations that I can be writing out, we can be working with, then I think the velocity there matters a lot more. I think this is sort of the same sentiment towards forking in general, where a lot of the infra here is kind of messy. A lot of the guts are gross. Yeah, you could grab the code, but why?

Nicholas: Sure, sure. It might be easier to write your own protocol.

0xmons: I didn't want anyone else to be mucking around with the v2 code base. The periphery is on top, sure, but some of the math calculations are kind of gross.

Nicholas: In what way? They're just really intense?

0xmons: So one of the fun things is making sure that there was an efficient and correct implementation of partial fills. I like to say this to everyone, so if anyone here has already heard it, I apologize. But I feel like it's the one thing that got to nerd out about during the development cycle. So imagine you have like 10 NFTs that are being sold in one pool, and say the prices are going from 1 ETH to 10 ETH. So each one goes up by an ETH. each time an asset is sold, and you're trying to buy like five of them, right? So as you submit your transaction to buy five of them, say someone goes and then purchases the first one. So now the prices go from 2 ETH, 3 ETH onwards, and you were trying to buy five. The question is, you probably don't want to buy the next five if you said slippage to zero, right? You're willing to buy prices at 1 plus 2 plus 3 plus 4 plus 5, but now the prices go like 2, 3, 4, 5, 6. How do you efficiently encode your preference to buy at the price of 1, 2, 3, 4, 5, such that at execution time, you would fill for 2, 3, 4, 5, and then not fill the last one at 6. And you can show that as long as the pools are all using bonding curves, where the prices at minimum stay the same with each marginal purchase or go up, then you can binary search at execution time to figure out the optimal number of items that you should fill. So that was fun.

Nicholas: That's cool. But that's not the same thing as robust swaps, right? Robust swaps is different.

0xmons: So this basically supersedes that. So the idea behind V1 and sort of like an earlier idea of this was like, okay, well, you know, if the prices move too much, then just like don't try to fill at all. Whereas now the idea is like if the price has moved too much, calculate exactly how much it moved and figure out how many items, if any, can still be filled.

Nicholas: Wow. And that's not too painful on the gas side?

0xmons: Right. So if you did it naively, it'd be pretty bad, right? You'd have to like iterate from one to the number of items you wanted to buy and then calculate like the on-chain cost and then compare that, right? So that'd be like O of number of items you wanted to buy. You'd have to do like a bunch of storage lookups. So if people want to like keep the router code, you can, it's found verified on GitHub under AGPLv3, like repo will be out later today. So maybe we can add a link after the chat. But basically, there's a bunch of storage variables that are first like stored onto the stack so you don't have to do like multiple reads. And then you end up doing like binary search. So it ends up being like, you know, O of log number of items you want to purchase. In the case where like the prices don't match up, right? If the prices match up, then you don't like do this at all. So it's all like behind a conditional block.

Nicholas: Got it. Very cool. Have you seen anything in the Uniswap v4 codebase that you're excited about or that you maybe want to take inspiration from in some future work?

0xmons: I'm going to be real with you, Nicholas.

Nicholas: No time.

0xmons: All I've done is seen the word hook and meme on Twitter. I have not had a chance to dive into the codebase.

Nicholas: Well, that would only make it you and 99.9% of CTs. Don't feel too bad. You've been busy. What's the hardest part about building an NFT AMM?

0xmons: I think the competition for getting liquidity is always, I think, part of the big challenge where you want to make it clear why the platform is worth LPs on. So, you know, like for any marketplace, grabbing two sides. And then a thing that was really messy earlier on before we started talking about defined was some of the indexing stuff, which was, I think, depending on how you structure the protocol, it can be more or less painful. In the case where, you know, like each listing is basically its own contract and has information stored and then might be reused, indexing becomes more important.

Nicholas: Is there a pseudo company? I know there's a DAO. Is there a company like Labs as well?

0xmons: Yeah, so the setup is both the V1 and V2 contracts are set up on-chain, owned by an OZ governor. And that's all set up with actual token voting. So changes of adding which bonding curves, configurations on the factory are all set up through the OpenSAP and governor. Separately, though, there's me, other people that you might have seen on the team who are employed by a Labs entity. That's the Corp side.

Nicholas: Got it. And what's the status of the tokens? Are they completely issued or are they still being issued over time?

0xmons: So tokens are out. There's been like some stuff, I think, in the forums talk about doing certain liquidity mining ideas. I do think that, you know, like markets being as they are, like a lot of those conversations have sort of stopped. Definitely think like spend right now is something that everyone is conscious of. So I don't know how much more steam those discussions are getting in. like the short term.

Nicholas: How do you think about the role of the DAO? I saw there's been a few proposals. I think one or two have passed so far. How do you think about the like a token voting DAO?

0xmons: Yeah, I think that in I feel like I'm of two minds here. I feel like one is that it's definitely like. it's definitely useful in certain cases to have like certain decisions be like fast track, right? Like you don't want to be voting on like every particular proposal. I think separately, like having, you know, the on-chain structure is really important versus something just like snapshot and a multi-sig. Otherwise, I do think that like if possible, sort of minimizing or having like PID setups are also useful. I think some of like the recent I think like lending markets, for example, are one where like, you know, by default, you have to be making a lot of governance decisions and that doesn't seem like an enviable position having to keep track of like what a good collateral ratio is or like when to lower that. So like a lot of the like recent Aave discussions have like put that into light with the CRV stuff.

Nicholas: So do you, are you excited about the future of the DAO's role in managing the protocol?

0xmons: I think that there's definitely some like some really cool space between like some decisions on upcoming bonding curves, as well as some more experimental ideas with like allocating the capital. that's sort of present already. So I do think there's like some cool stuff.

Nicholas: And so fees from the protocol accumulate to the DAO, the OZ governor, to allocate about tokens. And so there's no financial relationship currently between the DAO and the labs?

0xmons: No.

Nicholas: All right. Got it. So I wanted to turn a little bit to one last topic. If anyone has any questions or wants to request and come chat with Owen, please, please request and we'll switch to Q&A in a second. But you know, you're really accomplished NFT artist in addition to all this protocol work. And I'm curious how you got from being that artist to doing sudo. Is it, do you consider it a part of your art practice? Or just the next step for you? How do you think about the relationship between the art and the protocol dev?

0xmons: I think they're, they're very different. It's like a very different state of mind. I feel like there are some people who might be thinking things like, you know, oh, coding is also an art form or like. there are things that are aesthetic or beautiful and like somewhat sympathetic to them. But I feel like, you know, when working on protocol stuff, I'm not thinking about like, you know, oh, this is really elegant. I'm just thinking more about, you know, how to get to the goal. So I feel like they're, they're very different. Definitely think that a lot of this wasn't something that was like very predictable, you know, two years ago, sort of a core impetus of like the original OTC site was that people who had this Xerox fonts on NFTs wanted to trade them with one another. And the setting of a site to do that was sort of where the original idea came from. And it's obviously grown a lot since then.

Nicholas: Yeah, it's wild. So this wasn't your plan from the start?

0xmons: No, I did not have a 100 step plan that ended here.

Nicholas: That's the end of my list of questions. But I mean, I'm sure there's tons of things about PseudoSwap that I wouldn't know to ask questions about, not just even technical things about the protocol, but even the social process of building it or what you've learned along the way. Maybe, do you have any insights, especially since V1 and things that have happened since then that have informed your actions in building V2 and going forward?

0xmons: I think that probably the biggest thing that I wish I cared more about, like, one year, two years ago was really simplifying the process to interact with protocols. I think that, you know, like, users have a lot of choice and like focusing really hard on both like making certain decisions, at least at first, for the user, so they can get their feet wet is important. So that's probably like the biggest sort of design takeaway that I've been thinking about.

Nicholas: So just building efficient protocols isn't enough?

0xmons: Oh, yeah, definitely.

Nicholas: And do you have any... One thing we talk about at Juicebox sometimes is how, really how valuable the front end is. The front end is incredibly valuable. It's maybe more important than the contracts, ultimately, which I think is similar to what you're getting at with giving sensible defaults to first time and new users. Has any of your thinking on that changed? I know you did a complete rewrite of the front end for V2. Any reflections on the power or specifics about building front ends for complex protocols?

0xmons: Yeah, I think that, you know, there's so many different ways that you can be expressing, you know, like the same action. I think one of the coolest ones that I've been like nerding out about a little bit recently has been taking a look at like Wasabi, which is like this NFT options protocol. And they've been doing some, I think, like really interesting work and like, you know, you're like buying options, right? Like, everyone knows how that works. But I think they've been doing some really interesting work in like setting up like you know, like an option and casting it in different terms of like, you know, if you think the price is going up, then you'll make money when the floor hits this much. And then there's just like a buy or sell button. So yeah, I definitely agree there. You know, there's like a lot of ways that you can be like representing actions. The user interface there is like a really big determinant of that.

Nicholas: I guess when you integrate, if an aggregator or Zora or somebody integrates Sudo, are they only generating NFT buy side demand? Is there an issue like because of the nature of the marketplaces that there's you don't get the other side of the trade represented in third party interfaces as easily?

0xmons: I think that I think there's definitely a bias, you know, towards volumes coming through on on like the buying side. Although I feel like that's more nature of like, you know, if you're if you're like showing people where to get an asset, it probably makes more sense to figure out how to let them acquire it versus remove it. Right. I feel like that's sort of just crypto nature of like everyone jokes about disabling the sell button. But I do think that there's like, you know, there's like some bias, I think, towards like one side of the market. And I feel like that probably flows into like user design, maybe even unconsciously, or like sort of shown and how much easier it is to integrate listings versus bid side.

Nicholas: That's it for my questions. I don't know if anybody from the audience wanted to come up and ask. I see there's a bunch of brilliant devs and builders around. if anyone has questions for Owen. He's not that scary, I promise. If not, I guess we can call this a wrap. When did V2 drop exactly? It's been what a couple weeks?

0xmons: It's been one week.

Nicholas: Wow. Congratulations. That's huge.

0xmons: Thank you.

Nicholas: If you knew how hard it would be to build at the start, would you have taken it on?

0xmons: Absolutely not. I would go to the Bahamas and party with SBA for a few weeks before all the debacle happened. No, it's definitely been very rewarding and grueling, but a very cool experience.

Nicholas: I'm sure the token holders thank you for being in that apartment for so long. Owen, this is great. Thank you so much for coming through and explaining V2 and your whole process for building PseudoSwap. It's super educational.

0xmons: No worries. Thanks for having me on, Nicholas.

Nicholas: All right. Thanks, everybody, for coming to listen. Thanks again, Owen. Next week, same time, same place. Trying to get Vitalik on the show next week at ETH Waterloo. We'll see if that turns out. Fingers crossed. So thanks, everybody.

0xmons: I'm one of me.

Nicholas: Well, we'll see. All right. Thanks, everybody. See you. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5 p.m. Eastern Time, 2200 UTC, on Twitter Spaces. I look forward to seeing you there.