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
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