# Advanced Seaport Techniques

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 52:55
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-YLWnaSymFHA
- YouTube: https://www.youtube.com/watch?v=YLWnaSymFHA

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/6/advanced-seaport-techniques/index

Seaport is a marketplace protocol for buying and selling NFTs. While it powers OpenSea in a horizontal capacity, Seaport is open source and allows marketplaces to share a pool of liquidity – enabling project-specific, bespoke vertical marketplaces. Since launch, it’s helped spur innovation across emerging NFT verticals, including ENS names, in-game purchases, etc. This workshop will explore advanced techniques and use cases for the Seaport protocol.

Speaker(s): Zero Age
Track: Developer Infrastructure
Keywords: Seaport,Marketplace,EVM

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] this is Ryan we're with openc 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 uh 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 C Port listing or offer the first is the offer and that's all of the items native tokens erc20 EOC 721 1155 but you the offerer are going to spend then on the other end you have the consideration which is everything that you or others are going to 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 a it's a contract that you can approve to transfer your tokens so you set your approvals on the Conduit and from there uh 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 you 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 yeah signatures are not just standard ecdsa they're also support for 1271 which is is valid signature Seaport will give the offerer 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 cash but 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 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 12.71 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 offerer 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 then 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 more dynamic or you got a question so this is not zones this is if you have a contract that is going to serve as an offer 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 his 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 provided 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 Port 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 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 Wes or they're all die or something like that then you can call this other function and performs a more optimized fulfillment less call data you just need to supply a subset like give all the additional recipients which spells out um usually it's used for fees and uh on top of that the basic fulfillment methods have a slight deviation where if the offer is the item is a erc20 token or native token then it will be used to pay for all the non-nft consideration items so you don't have to take everything you can minimize the number of transcripts that are occurring that's a common theme with uh you'll see uh 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 item these all have the exact same item type they all have the same uh 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 uh 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 going to match those with this item this item this item on these orders on the consideration side then that whole group gets distilled 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 um get them all to all fit together in a neat little puzzle piece big big thing to be aware of with this is that if there's a problem after you supply all these fulfillments it's going to 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 the whole batch will come crashing down it'll revert so definitely this is this is the power feature and uh the first thing you want to reach for if you're looking for searching or um 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 except the type is restricted now the Zone gets to decide whether or not the orders good or bad and in addition you can always extend the consideration array you can always add items as the fulfiller 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 a 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 root and this Merkle root 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 that a creator of an nft updates their metadata they go and they update the zone registering that hey this particular Merkel route is actually now this other one right and you can't match the tokens that have changed another potential use case is for compromised nfts you might have an nft that gets stolen and um you don't want to be able to trade it anymore and that's one potential use case for his own 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 um I believe ens has a similar thing you register ahead of time and say I want to fill this then you wait some period of time and then you reveal you include as part of the 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 commit I'm going to 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 uh 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 uh 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 um and it's a quick way to say oh this order 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 um maybe a warning or a not right error right so it'll check uh on chain registry for uh 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 a as nfts and erc20 token something like that all kinds of interesting stuff and if you're trying to just piece together the potential uh things that can go wrong this is a great resource so how we doing on time all right I think we can open it up for discussion first off if anybody is currently building on top of Seaport and has a a sticking point or a question by all means let's let's hear them yeah here let me bring Mike over at the moment but I do have a question it's great yes um so certain nfts have royalties associated with them and 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 layer whoever's building on top of it um 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 five percent and I'm like okay I sign my listing now the Creator goes and changes that to 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 array you can't add them to the offer right you can't decide that the offerer is going to spend more than they originally agreed to that's that's a very important and variant not to break but um you can always say oh yeah I'll I'll give out something extra you combine that with call it a 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 going to be able to fulfill it is to supply the correct updated information that's sort of the gist cool 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 which you wrote something along the lines of like if a Searcher identifies an opportunity there it is so search your identifies an opportunity you can take whatever leftover item amounts and match them to a new consideration item to 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 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 arbitrager to take and it's not clear to me what this means for 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 what okay with the recipient being me the offerer right now someone else likes my nft they don't realize that I've already listed it for five what okay they put out an offer a bid on the nft to buy it and they offer six web so the weight would look for them is I'm offering six weft 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 uh 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 offerer A to offerer B then we do another match fulfillment order zero item I'm sorry order one item zero which is the six weft order 0 item zero on the consideration side is the the five width those now match the way that this works now is that they get the the five weft gets credited okay that's been accounted for the six weth gets spent there's one wealth 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 items so we could leave it at that you could match those two orders and the original or the 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 it's an empty array consideration item one with recipient is me and then they create another fulfillment that you know matches the 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 b or whatever and use that to match to so that's the idea there other questions okay thanks um so I haven't built anything on C4 but I've looked into it a little bit uh just wondering uh does it support like natively partial fill orders like is it possible yes single sign message with like multiple fulfillments yeah I'll get into that a little bit so if the offerer elects to to support partial fills it's specified in the order type just like a restricted order when the Zone uh 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 uh fulfill available orders match orders those don't do partial fills but there's an also fulfill Advanced orders uh match Advanced orders fulfill available Advanced orders those you give criteria resolvers basically Merkle 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 to avoid any kind of weirdness around grounding 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 eighth 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 um the euclidean algorithm to ensure that there's uh if there's an overflow we can all uh be rounded down to the greatest common divisor but that's that's different topics yes there's partial fills and um 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 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 um the 64 byte signatures so a standard ecdsa in ethereum has three parameters right v r and s and um 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 resolve to the same uh record they recover to the same signer well 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 parity 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 API encoding which you know you're looking at what 130 bytes or 130 gas for those bytes and uh just a minor optimization that that you can employ that's the idea nice thank you great questions everybody hey hi so I assume I'm trying to do like a searching strategy right so uh to help users with a gas uh you may take like signed orders right and those are not visible on chain so for a Searcher to like look through all the possibilities of uh 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 ah so this this really um it delves into less of how does Seaport do it and more all right what about the marketplaces they're built on top of Seaport right we work at openc 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 Seaport 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 mempool there's another way right so um but there is I think it's it's definitely an area of active investigation to figure out how to best um democratize that search okay thank you I guess two questions on my end uh one great one is uh the seaport support swaps of nfts uh today absolutely so when you look at an offer consideration the items eth or native tokens erc20 721 1155 any combo of those Seaport is totally fine with the exception is the fulfilled basic order method does have more opinionated uh subset of the possible orders that it's going to support but yeah Seaport 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 um yeah of a comparison question so uh we we're right now integrated with like Xerox V3 for uh awesome for private Marketplace so I'm just curious uh I mean maybe you can speak to like some of the differences between C port and Xerox V3 does any yeah yeah so first off Xerox is really cool they are definite innovators in the space um 0x is more geared around single nft like buy an nft sell an nft and it's it's actually a very good protocol for that Seaport is more geared around uh how do you how do you grow out from that there's less um less opinionated um on this what the exact structure of a listing looks like basically for the exact reasons that we're just discussing is a top one um another thing that is different is that Seaport 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 um and but yeah big fans of what the Xerox team has been able to do thanks positions over here I was wondering if like currently on open seat using Seaport do they utilize any like interesting zones currently or um do you have to like Define that yourself as like a someone who like creates a listing on openc so uh I can't speak too directly for openc I'm I'm one of many uh but what I can say is that for at least a couple of months after Seaport first went live it was a brand new protocol used a lot of assembly and and so we we kept guard rails on we used a global plausible Zone and required that all orders that were sent to open sea 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 um efforts are underway to really open that up other other chains off of mainnet don't currently use its own so stay tuned stay tuned on that and uh 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 um see what zones people are coming up with and um and that will definitely inform the discussion and efforts foreign we're having issues with signature verification where recovered signatures match the original signer but orders fail interesting okay and it's I've 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 uh listings and offers you have to ensure that you're not putting listings out that aren't fulfillable right so um that's one thing to try another Seaport has this notion of a counter so every single offerer 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 um you can run into issues the last thing I will say is that cases where there's something really sticky that's just like confusing and not um 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 to do that but um 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 uh 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 uh how are we doing on time all right uh well I guess we've got we got another 10 minutes maybe we could all Workshop oh you wanna you have another question yeah yeah um I think this might be a little bit unrelated to Seaport but more on the API so any any plans on your end to I guess make the API more Enterprise grade maybe like a higher TPS and so on uh we are we're just focused on Seaport but um definitely get we'll we can put you in touch with the API team um maybe we could Workshop uh an interesting Zone something that uh that would add some new capability to the seaport anyone got any ideas something you'd like to see yeah um I'm coming a bit late so I suspect this has always already been raised but is it Poss how about a Zone where it's only possible to make sales to certain people or I suppose certain addresses almost certainly in this addresses that's very possible yeah um and that actually reminds me of an interesting Advanced technique that uh 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've 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 going to 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 fulfiller 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 where 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 hey um so with like developing new zones um and building just generally on top of Seaport like a new Marketplace do you see it as like um like what's the what are the steps for for doing that is that like create a UI that signs messages and then create like your own database and API to serve those messages uh do you see that happening as like the pattern as this scales out or like develop the zone and then like work with openc to have that zone integrated or 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 the contract and now that that's in place really where we go from here is is uh 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 they're creating a brand new Marketplace from from the ground up I think that's it there still is very much a traditional um web 2 component to it that would need to be um it would need to be undertaken at this stage but um I imagine that that too will become more uh accessible to all soon is my help so you spoke a little bit about private um trade Private Sales just now I imagine that openc 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 in open seat 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 offerer 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 if 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 um like for like a Zone idea is that like I think when I was reading the like Open Seas like wyvern contracts like there was support for just Dutch auctions and pixel 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 uh so I 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 option what that really is getting at is this is a it's a sum listing where the price is going down over time right or the price is going up over time it's not necessarily an 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 um 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 um 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 going to give that to this this Auctioneer whatever the marketplace they're going to 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 um person that's 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 you want their assets or something their items um 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 uh can't wait to see what you build