 I'm zero age. This is Ryan. We're with OpenSea and we're going to talk about the seaport marketplace and some more advanced techniques for how to utilize it and interact with it and build on top. So seaport is a beast. There's a single contract but there's a lot going on and so we're gonna work our way through first start with some of the high-level key points and then from there we'll we'll get into some of these advanced techniques. So first thing to understand is that there are two arrays that dictate the basics of a seaport listing or offer. The first is the offer and that's all of the items. Native tokens, ERC-721, 1155, you the offer are gonna spend. Then on the other end you have the consideration which is everything that you or others are gonna get back. If you want to spend the offer items you gotta get the consideration. So there's also this idea of a zone. Every seaport order has an optional zone that you can set. That's a contract that gives a thumbs up or a thumbs down on whether that particular order is still valid. There's also a concept of a conduit which is it's a contract that you can approve to transfer your tokens. So you set your approvals on the conduit and from there you can set additional marketplaces or contracts on that conduit, support multiple marketplaces, migrate to new versions of seaport, so on so forth. So when it comes time to create an order to list your NFT the primary way to do it is you just sign an off-chain listing. This is an example payload that you would see in MetaMask. You're gonna have to pop open the expanded view to get this whole thing but it's got the offer array, consideration array, start time, end time zone conduit. Then another method you can use to create an order is to call this function validate and that means you don't need a signature at all. You just provide the order and it gets listed on chain so to speak. The interesting thing about both signing an order or calling validate is you have to explicitly cancel. You have to actually call and tell seaport I'm no longer interested in filling this. Signatures are not just standard ECDSA they're also support for 1271 which is valid signature. Seaport will give the offeror a digest basically the order hash and a signature and then leave it up to the contract to say yes this order is good this one's not and that works with both traditional signatures as well as validations and you can use this technique to list from a smart wallet or a multi-sig without having to pay gas. You can also and here we start to get into the advanced techniques you can utilize 1271 to do dynamic orders where you might have a contract that's willing to it's it wants to update the order based on a price that's coming back from an oracle or maybe it's implementing a bonding curve or it's a pool something to that effect. So what you do is instead of giving the signature for 1271 you actually give the order itself then and this there's a trick you can do here where you can actually supply an offset to call data that reuses the same segment of call data that you already provided with the order and cut down on the overhead of doing this but then what the offeror that's getting called will basically have to do is rehash the order derive that digest and compare it to the one that was supplied by 1271 but it knows that the order that you gave is the signature is in fact the correct order that's being filled at the moment and then it can go and look okay let's check out this offer item this consideration item and make sure that they match whatever the the latest state that we expect is. So that's a really interesting technique to to do with more dynamic orders you got a question so this is not zones this is if you have a contract that is going to serve as an offeror and so it could have its own validation logic on the contract as part of this but it could also utilize a zone right that's very much a something that it could piggyback on validation logic in its own all right so that's creating orders let's talk about fulfilling them the standard method for fulfilling an order is to call this function fulfill order and or fulfill orders is the actual function and you basically just give this whole payload just like the payload that you signed you provide it to this function and it creates an implied second order a mirror image of the first one where every item that's being offered on the order you're fulfilling you just say all right I will take that and take all of those items those are your consideration items with you as the recipient then look at all those consideration items I'll I'll send those out I'll pay them that's the the basic method but there's also a basic method which is there's a small subset of orders that actually constitute a pretty wide swath of what people are generally doing which is I want to buy an NFT I want to sell an NFT and maybe pay a fee seaport doesn't actually have a notion of fees at all so it's everything is just another item but if you have one of these simple subsets you got a single offer item you've got one or more consideration items and you take up that sum total of all the items there's one NFT that's part of that everything else is a single item type it's a they're all wet or they're all die or something like that then you can call this other function and performs a more optimized fulfillment let's call data you just need to supply a subset like give all the additional recipients which spells out usually it's used for fees and on top of that the basic fulfillment methods have a slight deviation where if the offer is the item is a ERC 20 token or native token then it will be used to pay for all the non NFT consideration so you don't have to take everything you can minimize the number of transfers that are occurring that's a common theme with you'll see as we get into these subsequent fulfillment methods it's all about cutting down on the top efficiency gain is from reducing the number of transfers right particularly with tokens native tokens a little different but with other tokens it gets very expensive if you're doing redundant transfers so when you want to buy five NFTs you want to sweep the floor right oftentimes you'll have each one of those has a fee attached what if those that fee recipient is the same recipient you don't want to do five transfers you want to do one so we use this fulfill available orders method this basically goes through each order and says has this been fulfilled has it been canceled if it's still valid then we'll go for it if the order is not valid anymore we'll skip it and you supply the you basically point to okay this order this item that order that these all have the exact same item type they all have the same ID if you're talking about 1155 token they all have the same recipient effectively they can be condensed into a single transfer cuts down a lot on the number of transfers there then you have this method match orders when you're talking about fulfill orders fulfill available orders seaport's not going to be able to figure out on its own how to do these transfers the way that it works is you're going to walk through every single fulfillment and it's the same idea as fulfill available orders here's the order here's an item here's another item here's another item let's let's aggregate all these together then we're gonna match those with this item this item this item on these orders on the consideration side and that whole group gets to still down into a single transfer so this method is it's not utilized as often if you just want to buy an NFT this is what you really want to reach for in the power use cases where you have your maybe you're searching like you're looking for MEV where you can find a price mismatch or you want to compose multiple different orders with zones and get them all to all fit together in a neat little puzzle piece the big thing to be aware of with this is that if there's a problem after you supply all these fulfillments it's gonna go through and make sure that every single consideration item on every single order has been fully credited it's got to be zero on every single one or else the whole batch will come crashing down it will revert so definitely this is this is the power feature and the first thing you want to reach for if you're looking for searching or or more advanced strategies okay let's talk about some zones zones is the it's the main mechanic by which you would extend seaport any order can choose its own zone and then say I'm a restricted order set the type is restricted now the zone gets to decide whether or not the orders go to bad and in addition you can always extend the consideration rate you can always add items as the filler we call them tips this is it's cool because you can take an order that came from one marketplace you can fulfill it on another and apply a tip what you can also do is you can use logic in the zones to ensure that the tip that got supplied matches whatever it is that that you expect it to maybe that's dynamic calculation of on-chain royalties right something like that so let's talk about a couple potential zones things you could use them for so one application of zones is for dynamic NFT metadata certain items in seaport they're called criteria based items and in place of giving a token ID an identifier you instead give a merkle route and this merkle route is comprised of all the token IDs that are valid or you can give an empty one and that signifies it's a wild card you can pick whatever token ID you want but this only gives you so much granularity because at the time that you sign the order it might have certain metadata but maybe the metadata gets updated right so the traits the attributes that that this had with the time you created the order they've changed now so you can obviously leverage zones for this anytime the creator of an NFT updates their metadata they go and they update the zone registering that hey this particular merkle route is actually now this other one and you can't match the tokens that have changed another potential use cases for compromised NFTs you might have an NFT that gets stolen and you don't want to be able to trade it anymore and that's one potential use case for a zone is to just check and make sure that the items that are part of the order are no longer fillable another cool potential use case is for front-running resistance say I have a zone where I have to call five minutes ahead of time and commit similar to how you would do it with I believe E&S has a similar thing you register ahead of time and say I want to fill this and you wait some period of time and then you reveal you include as part of the parameters called extra data when you're fulfilling that gets passed along to the zone the zone then can look and say oh there's a I'm gonna hash this looks like you committed to being able to fulfill this order another interesting one is leveraging oracles maybe I have a listing I don't want this listing to be fulfillable if the floor falls out so I could read from an oracle that is periodically updated and if the price drifts too much then cancel the order don't let it be fulfilled or you can even leverage this along with that trick with dynamic orders with 1271 to create a strategy that will buy NFTs below the floor price sell NFTs above the floor price that kind of thing so here's some links we've got obviously the seaport repo itself as well as any any questions or do you want to get into the weeds the discussions there are great place for that seaport JS is a library for interacting with seaport makes a lot of this stuff much more straightforward one thing that I will note is that much of the match orders functionality is a little more rough around the edges would love any contributions if anyone finds themselves working on that and then this last link seaport order validator this is a contract that we put together to make it easier for checking an order or if you are accepting new orders coming in there's a lot there's a lot of gotchas things that can go wrong and it's a quick way to say oh this order it looks like you're not actually getting anything from the order right you're not set as one of the recipients on a consideration item you sure you want to do this there's a hundred permutations of things that can be maybe a warning or an outright error right so it'll check on chain registry for creator information like make sure that the the tokens implement EIP 165 that you're not trying to pretend like one one token that's actually as NFT is an ERC 20 token something like that all kinds of interesting stuff and if you're trying to just piece together the potential things that can go wrong this is a great resource so how we doing on time alright I think we can open it up for discussion first off if anybody is currently building on top of seaport and has a sticking point or question by all means let's let's hear them yeah here let me bring Mike over so certain NFTs have royalties associated with them I was wondering do you include the royalties in the orders themselves or does that get handled somewhere else in the contract and if so how does optimization happen on that front yeah so the basic approach as I mentioned earlier seaport doesn't have any notion of fees or royalties it's baked in it's just you could very easily create an order that doesn't include any fees or royalties whatsoever so it's really up to the discretion of the application whoever's building on top of it one approach you can take that I think is a pretty good one is to just read from the registries at the time the order is created this depending on your perspective is either a feature or a bug one thing that I would consider a bug is if when I go to create a listing the royalty is 5% and I'm like okay I signed my listing now the creator goes and changes that 50% that's a problem and I might not have listed it if I knew that I was gonna have to pay that right then there's also the question of well what if they just want to tweak the recipient of the royalty or something like that for those cases you can leverage tipping right so I mentioned earlier that you can always add additional items to the consideration you can't add them to the offer you can't decide that the offer is gonna spend more than they originally agreed to that's that's a very important invariant not to break but you can always say oh yeah I'll I'll give out something extra you combine that with call it a royalty zone the royalty zone will go it will read from in real time from the registry and ensure that the last consideration item this tip matches what the registry has on file so then the only way you're gonna be able to fulfill it is to supply the correct updated information that's sort of the gist thank you cool yes I have a question about one of your earlier slides so you on the matching orders slide you have this statement you wrote something along the lines of like if a searcher identifies an opportunity there it is so I searcher identifies an opportunity can take whatever leftover item amounts and match them to a new consideration item takes itself so I'm a little confused because my understanding of the architecture is that in every single type of order or function call you make all considerations have to be met on the other side so I'm a little confused how you like like in the in the case of like the classic case of arbitrage right like there has to be an opportunity on the table for the arbitrage or to take and as it's not clear to me what this means for an opportunity if the considerations are always evened out or yeah it's a great question and this is actually a good a good opportunity to get into just the the nitty gritty on how this would look let's just consider a really simple stripped down case where you have one listing so the way this might look is I want to sell my NFT right so I have one offer item which is my NFT and one consideration item we'll call it five weath okay with the recipient being me the offer right now someone else likes my NFT they don't realize that I've already listed it for five weath okay they put out an offer a bid on the NFT to buy it and they offer six weath so the way it would look for them is I'm offering six weath one offer item one consideration item this NFT recipient is me so now person number three searcher comes along and realizes that there's this mismatch they call match orders they supply both of these orders and they give a fulfillment saying okay order zero item zero is the NFT order one item zero on the consideration side is also the NFT these match that turns into a single transfer from the offeror a to offeror b and we do it's another match fulfillment order zero item I'm sorry order one item zero which is the six weath order zero item zero on the consideration side is the five weath those now match the way that this works now is that they get the five weath gets credited okay that's been accounted for the six weath gets spent there's one weath left you can actually leave offer item amounts on the table there's not there's not a reason that you have to spend all of the offer items but you do have to credit all of the consideration I am so we could leave it at that you could match those two orders and the original or the order be the person that made the bid just end up paying five but what would in practice what would happen is that this the person who located the opportunity might say I'm going to create a third order and this third order I'm offering nothing so empty array consideration item one weath recipient is me and then they created another fulfillment that you know matches the same one that we've just spent five from with the new one you don't even have to create a new order you can also just add on a tip to order be whatever and use that to match to so that's the idea there other questions okay thanks so haven't built anything on seaport but I've looked into it a little bit just wondering does it support like natively partial fill orders like is it possible yes single sign message with like multiple fulfillments yeah but I'll get into that a little bit so if the offerer elects to support partial fills it's specified in the order type just like a restricted order when the zone requires that so if an order supports partial fills the way that this works is that you can supply when you call a normal it's like fulfill order fulfill available orders match orders those don't do partial fills but there's also fulfill advanced orders match advanced orders fulfill available advanced orders those you give criteria resolvers basically Merkel proofs for the criteria based items as well as fill fraction a numerator and a denominator and the the heuristic is that every single assuming that the order supports it every single offer item and every single consideration item is going to get that fraction applied to it and then once the order is fulfilled it's just going to update with the fraction say here's how much it's been fulfilled the rule is to avoid any kind of weirdness around rounding errors is that every single one of those fractions has got to be exact it there can be no remainder after applying the fraction so in general when you're constructing an order that supports partial fills from the get-go the easiest way to do it is to start with a single quantity right I have some ERC 1155 tokens that I want to sell for one ETH each right I want to sell 10 so I'll now just take the one ETH multiply that by 10 take all the fees that were already calculated multiply those by 10 so it'll be a nice even fraction that's applied the math behind that on the contract is also pretty cool the uses the Euclidean algorithm to ensure that there's if there's an overflow we can all be rounded down to the greatest common divisor but that's that's a different topic yes there's partial fills and and once the basically once the fraction the fill fraction is applied and all the criteria resolvers are applied and it's all the exact same flow as with the standard stuff yeah hey there can you talk a little bit about extra cheap signatures and when they should be used about what signatures extra cheap I see that's a parameter when you're creating an order and I think you use EIP 2098 in that case oh yeah yeah so 2098 is the 64 byte signatures so it's a standard ECDSA in Ethereum has three parameters right VRS and turns out that there's there's a parody to the V right it's almost always 27 or 28 right and there's basically a signature malleability concern there where you have two exactly identical or the the signatures are different but they result the same they recover to the same signer the trick is basically to say what if we just always flip the parody right so you can take any 65 byte signature and you compress you flip it so that the parody is always I think 27 and then you also can because when the parody is that 27 then the S value won't use the most significant bit so then you can compress V and S into a single word you basically take what was once three now it's just two words so you cut down on a word of call data in standard ABI encoding which you know you're looking at what 130 bytes or 130 gas for those bytes and just a minor optimization that that you can employ that's the idea nice thank you great questions everybody hey hi so assume I'm trying to do like a searching strategy right so to help users with gas you may take like signed orders right and those are not visible on chain so for a search here to like look through all the possibilities of orders out there that I could possibly fill with a match order where would I get a list of all the orders that are not on chain like is there a HTTP API that I could call so this this really it delves into less of how does C port do it and more all right what about the marketplaces they're built on top of C port right we work at open C we have an API if you have access to the API then you can read from the API and and get a sense of yours there are also other marketplaces they're built on top of C port you might want to be pulling from those but it does get more complicated to find all of that you can listen on chain for the validate events right which is one way to do it you can listen in the mem pool there's another way so but there is I think it's it's definitely an area of active investigation to figure out how to best democratize that search okay yeah I guess two questions on my end one great one is the C port support swaps of NFTs today absolutely so when you look at an offer consideration the items ETH or native tokens ERC 20, 721, 1155 any combo of those C port is totally fine with the exception is the fulfilled basic order method does have more opinionated subset of possible orders that it's going to support but yeah C port was built with this idea of barter like NFT for NFT as a first classes yeah I guess the second question I have might be a little bit yeah of a comparison question so we are now integrated with like 0xv3 for also a private marketplace I'm just curious I mean maybe can speak to like some of the differences between C port and 0xv3 does any yeah yeah so first off 0x is really cool they are definite innovators in the space 0x is more geared around single NFT like buy an NFT sell an NFT and it's actually very good protocol for that C port is more geared around how do you how do you grow out from that there's less less opinionated on this what the exact structure of a listing looks like basically for the exact reasons that we were just for discussing is a top one another thing that is different is that C port is totally unowned and permissionless there's no special notion of like a protocol token or a protocol fee that could be turned on it's just meant to serve as a permissionless piece of public infrastructure on chain so that is a difference and but yeah big fans of what the 0x team has been able to do thanks over here I was wondering if like currently on open C using C port do they utilize any like interesting zones currently or do you have to like define that yourself as like a someone who like creates a listing on open C so I can't speak too directly for open C I'm I'm one of many but what I can say is that for at least a couple of months after C port first went live it was a brand new protocol used a lot of assembly and and so we kept guardrails on we used a global plausible zone and required that all orders that were sent to open C had this zone set on them and it would allow for us to basically hit the panic button and just cancel every single order if there was a problem with the marketplace it's now been long enough and there are enough interesting use cases for zones that efforts are underway to really open that up other other chains off of main net don't currently use a zone so stay tuned stay tuned on that and I will also say that if anyone is authoring zones or working on them get in touch let us know we'll definitely it would go a long way to help see what zones people are coming up with and and that will definitely inform the discussion and efforts we're integrating with C port and we're having issues with signature verification where recovered signatures match the original signer but orders fail interesting okay and it's it's been unsolvable for me so what are reasons this could be okay so if you have if you have an order that's signed and the signature is valid right like you can recover the signature and it works there are a number of potential things that you could look into the first would be checking the order validator right that's that's going to scan through and give you a number of potential problems when you go to try and fulfill it and that's actually it's a very important thing if you are maintaining listings and offers you have to ensure that you're not putting listings out that aren't fulfillable right so that's one thing to try another see poor has this notion of a counter so every single offeror has a counter that's tracked independent of all of their orders and at any point you can just call increment counter and that serves as an eject button where all the orders that are signed with that counter are now invalid interestingly though you don't supply the counter as an explicit argument it's an implied argument so if you have two identical orders except one has counter zero one has counter one they'll have different order hashes but the call is the same so that's one potential area that you can run into issues the last thing I will say is that cases where there's something really sticky it's just like confusing and not not making sense I would really encourage you to go to this discussions board both for it's a great forum to lay out all the information and also for others to then benefit from figuring it out and so I'd encourage you to do that but yeah signatures are are notoriously finicky to work with and it every every developer that's that's had to work with them that there's always a sense of relief when you finally get your workflow figured out and and the signatures are working because it can be quite opaque why things are going wrong the counters though they only get incremented when you cancel an order so it's actually not related to canceling when I call cancel on an order that cancels a specific order and that's actually one of the only times you do explicitly provide the counter so it's saying here's a particular order that I want to cancel when you call increment counter you don't provide any arguments you just call increment counter and it cancels all of your orders that were signed with that counter yeah two distinct things thank you other questions okay how are we doing on time all right well I guess we've got we got another 10 minutes maybe we could all workshop oh you want to give another question yeah yeah I think this might be a little bit unrelated to the C port but more on the API so any any plans on your end to I guess make it API more enterprise great maybe like higher TPS and so on we are we're just focused on C port but definitely get well we can put you in touch with the API team maybe we could workshop an interesting zone something that that would add some new capability to the C port anyone got any ideas something you'd like to see yeah I'm coming a bit late so I suspect this is always already been raised but is it posts how about a zone where it's only possible to make sales to certain people or I suppose certain addresses or maybe certainly in less addresses that's very possible yeah and that actually reminds me of an interesting advanced technique that is used for private sales so you if say I want to I want to sell just a specific NFT and you are the only person that can buy it what does that look like right how would I set that up one kind of interesting way of doing that is just to say all right single offer item my NFT consideration item one is ETH to me consideration item two is my NFT to you right so I basically just set it all up but now if I wanted to go and call these implied mirror order and you know just fulfill orders on that it's not gonna work because the the offer item from me needs to actually match to the same order right the consideration item on that same order so you got to use match orders for that and you would then match it with an order from you that just says I'm just offering the ETH and there's no consideration item right so I'm basic if if I were to just take that order and sign it then it's effectively a donation right but if I fulfill it alongside this other order now the two of them together make a complete picture so that's for just a single private sale but for say I only want to sell my NFT if you're on this allow list that's easy enough you have a zone where you just supply okay here is a Merkel proof that says that the Fuffiller the caller is in the root right they're one of a set of people or I could check and see like the caller has a balance of this particular token if it don't want it to be a token gated thing we're only someone that owns this token can buy it from me or something like that well that's all actually it's pretty straightforward to do with his own a so with like developing new zones and building just generally on top of seaport like a new marketplace do you see it as like like what's the what are the steps for doing that is that like create a UI that signs messages and then create like a your own database and API to serve those messages do you see that happening as like the pattern as this scales out or like develop the zone and then like work with OpenSea to have that zone integrated her maybe like a mix of both well we knew that the place to start was with the smart contract right the marketplace that's it's the hardest and riskiest thing and most expensive to get audited and vetted and all of that so started with that the contract and now that that's in place really where we go from here is is anyone's guess but I think that if it really depends on the application if you have a particular flavor of listing that you want to see supported in other marketplaces then I think the most expedient route to do that would be to go ahead and put it together and then shop it around and sort of like I mentioned earlier you know I would we would love to to see what people are working on zones they're creating and that would really help expedite the process and help standardize around certain zones that do specific things really well for creating a brand new marketplace from from ground up I think that's it there still is very much a traditional web to component to it that would need to be would need to be undertaken at this stage but I imagine that that too will become more accessible to all soon is my help yeah so you spoke a little bit about private trade private sales recent just now I imagine that OpenSea is not spawning new contracts for zones every time someone does a private sale can you walk us through the flow of a private sale and OpenSea today yeah so so there's no zone required on private sales that's basically just taking the standard order and normally you'll see an order with it's like the basic order you'll have a single offer item that's either the the tokens that you want to spend or the NFT that you want to sell and then you'll have one consideration item the first one by convention like if you use the order validation helper thing the first consideration item is almost always going to be something coming back to you the offer right and then it'll be followed up by usually fees like here's a fee to the marketplace here's a fee to the creator that's the standard order that you would see but in private sales one way you can do a private sale is you deviate from that standard a little bit and you just say I'm actually going to include the the recipient the person that I want to sell this item to as a consideration item on my order that makes sense so it's like literally you need to get this or else you can't take it from me yeah that's the idea I guess like for like a zone idea is that like I think when I was reading the like OpenSeas like Wyvern contracts like there was support for just Dutch auctions and Excel or fixed price sales and they had like a comment in it saying like they wanted to maybe do something more advanced or like English auctions or something like that right and I remember watching one of your like I guess it was like an East Denver talk or something like that and you said that like something like an English auction or that could be possible using the zones so I should this is actually another advanced technique that we haven't really touched on that you reminded me of and that is every item you can specify a start amount and an end amount so when you do that it will look at the start time and the end time on that particular order and then it does it a linear interpolation and we'll just pick out okay here's the current amount based on where we are along the the timeline for the order so oftentimes like when you talk about a Dutch auction what that or a reverse Dutch auction what that really is getting at is this is a it's a some listing where the price is going down over time right where the price is going up over time it's not necessarily auction per se now auctions there's a couple different ways to run them and it really depends on what you're trying to optimize for and what your trust model is oftentimes what it really comes down to is like I have a reserve price and I want that reserve price to be met and I want that reserve price to be secret too right so like one way to handle an auction assuming you have an auctioneer that is a someone you trust is you set the auction the runner of the auction as the zone on your order zones generally the way that we would think of them is that when you have a restricted order that zone you're gonna call it and say is this a valid order if it is then it'll give back a magic value saying this is good go ahead but another way you can do it is that that zone can actually call seaport if they call seaport that's also them if they're the ones that are fulfilling the order that's also them giving explicit approval per se right their message sender so you can basically sign a listing that you here's my my reserve price that's the consideration item to me I'm gonna give that to this this auctioneer whatever the marketplace they're gonna keep the order secret and then they have to be the one to fulfill it right it's a restricted order and they'll apply a tip on that based on the difference between the reserve price and the actual price there are also constructions where you can do stuff like the commit reveal pattern for hiding the reserve price you generally have to bond up front I mean it gets it gets complicated depending on whether you're optimizing for the privacy of the the person that's what that's trying to auction the item or if you're trying to optimize for protecting the bidders you know if you don't want the person running the auction to pull out of the auction and cancel it and pull their yoink their assets or something their items there's there's a number of different variables to control for but that's one thing that I think would be really cool to see more work on is leveraging zones to run different kinds of auctions yeah all right that's time thank you all for coming and can't wait to see what you built