[Music]
thank you so much for sticking through I
know everyone's hungry for lunch so am I
uh hopefully this this will be a solid
one after which you think you will need
a break um super glad that you are still
like up and Alive um sweet guys I think
to get into it um
um I sort of like wanted to talk about
this upcoming thing called intents which
is supposed to sort of like change how
we interact with chains going forward
and a bunch of
like projects are starting to look at it
in a pretty deep level including people
at Unis swap cow Swap and a bunch of
like other protocols um so I just wanted
to chat about an upcoming proposal there
and talk through some of the design
choices that have been made and why
those might not be right and how could
we potentially fix it uh this is not a
diss track this like I'm using the EIP
or ERC as like U sort of like a channel
to talk about this stuff not really uh
talking about this specific uh
implementation right I work at socket
I'm web of also go by VC you can you can
find me after the talk
but if you want to check out the exact
proposal I'm talking about here there's
a quick QR code uh I think this is by
Mark T from Unis Swap and this is what
Unis swap is going to be using for the
crossing swap stuff generally speaking
um I think we always begin this topic
with what really are intents right um
unfortunately that is something I don't
want to get into for this particular
dock right it always sort of like goes
into like something you don't want to
get into right but I think broadly
speaking you want to do something on
chain you specify it someone else takes
care of it that's like the rough mental
model you can have in mind and this is
different than transactions because in
transactions you sort of like send a
transaction on chain saying exactly what
you want to do but here you just talk
about the end goal you want to achieve
and someone else sort of like takes care
of the
execution that's like roughly how to
think about it
um so I'm going to talk about like a
particular sort of like design pattern
here um goals of this particular ERC
7683 are about how do we make it such
that uh fillers aren't fragmented this
probably doesn't make sense right away
so let me give you guys a quick like
walk through about what really is
happening here so you see a nice farmer
Emoji there that is the that is our
normal blockchain user today who is sort
of like signing something that looks
like a struct where he's sort of like
talking about what chains he want to go
between what's the input asset what's
the output asset things like that right
and he sort of like Signs this stuff and
sends it onchain to a particular
settlement contract on some Source
Network where a bunch of like these
robots these Bots sort of like look up
to this Source chain contract for what
are pending intents that need to be
filled right and then they sort of like
fill it on the destination
and then there's a Oracle that sort of
lets the settlement contract on Source
chain know that hey the request that you
had has been fulfilled by this
particular bot on destination right so
really simple um user sends funds on
Source the Bots fill it on the
destination and then the Oracle sort of
like conveys the message that you know
things are done
really I think filler fragmentation
starts here right so now we have two
structs which basically means like now
we have like two intent protocols the
only difference between the first one
and the second one is that the second
one has an extra parameter called call
data let's assume everything else is
same this is the only difference right
um due to which now we have these two
separate contracts and earlier while we
had like eight fillers solving for this
particular intent protocol as soon as we
have two intent protocols these are now
split in two right as more and more
intent protocols go live sort of like
fillers get fragmented because they need
to do more work they need to do more
Integrations and stuff like that right
super annoying stuff um this is harmful
for everyone not not exactly harmful but
like really undesirable specifically
because there aren't too many fillers
anywhere in the space right there are
there are probably like 15 to 20
entities that are sort of like operating
in this particular role and if you sort
of like start fragmenting those we don't
know where we'll end up right so we want
competition over here so we want as many
fillers as possible so fragmentation is
something we want to avoid here
fragmentation is bad for all three of
these parties it's bad for the user
because if people aren't competing
you're going to get the worst possible
price right it's um and if you don't
have like an intent standard then you
don't actually understand what you are
signing so someday you might sign
something that give someone authority to
pull all of your funds away forever
right so you know like chances of rug
pull we hear about fishing attacks with
like permit to Witnesses all the time
right so we want to like standardize on
this layer for sure it's bad for intent
protocols because we had eight fillers
you launch an you you launch an intent
protocol and you have to like sort of
bribe four of them to sort of like Port
over to your thing and then as more and
more of these protocols launch it
becomes even more more expensive because
these fillers aren't commoditized uh
they are sort of like specialized and
you have to like get into like specific
agreements with them and whatnot so
ideally you want to commoditize and have
a lot of fillers so you have high
competition if you launch an intent
protocol you have fillers for your user
requests and for fillers um they just
want access to more autoflow without
doing a lot of work so as a like just as
put on your Market maker hat what you
want to do is like if there's an
opportunity out there I have capital I
want access to that opportunity for the
least amount of work possible so I think
all in all it sounds highly beneficial
that we should like standardize this
part of the layer for all three of these
parties and that's what the CIP is
trying to do the ideal world is where I
launch a new intent protocol and all
filler start filling on my protocol on
day one with like close to zero effort
that's the idle world that's the world
the CIP is trying to take us
to um again put your Market maker hat on
imagine you are participating in one of
these intent based protocols how does a
filler decide to fill like what is the
decision Tree on their end right um you
receive an intent the the first thought
you have or the first thing your program
does is do I understand this aut type
and like how do I interact with it uh
with this particular onchain contracts
and stuff like that like really like
generic
interpretation uh second is like do I
understand how does this particular
protocol work can I fill for it stuff
like that so users and fillers are sort
of like entities on both ends and we
need to give them like a way to sort of
like communicate think about it like
sending a mors code right like you are
stuck somewhere and you're trying to
send like a morse code through to
someone so that they can come and rescue
you you want to make sure they
understand your Morse code otherwise
you're sending signals they just think
it is like a faulty bulb or something
like that right so you you want to make
sure your signal can be understood and
interpreted correctly and you also don't
want to mean situations where you're
sending something like hey um I have an
apple but what they interpret it as I
have a bum right that's that's also a a
bad place to be in so this
interpretation needs to be on point
especially in this context because we
are talking about financial contracts uh
wrongful interpretation here means you
lose
money so this is the first thing that
you think about as a filler can I
interpret this
thing okay the second thing you think
about can I fulfill meaning if the user
is saying hey I have some a over here um
if the user is saying I have 100 a over
here give me like 200 a on this chain
this is something that is simply not
possible or like why would you give
anyone free money unless you're getting
more free money down the lane why some
airdrop or something so you after you
interpret you just make sure you can
fulfill what the user is asking for um
basically sort of like making sure you
understand the terms and conditions and
you are like opting into
it all right so once you interpret you
understand the terms and condition now
now you are like okay uh how much am I
going to make on this thing and do I
participate on this thing or not so now
you start calculating profit loss and
all of those things so this is like how
a market maker or a filler will sort of
like think about your intent as they
sort of like flow through this is going
to be like super important as we go
about this stuff
so I think um if you if you think about
it like why does filler fragmentation
like exist on a on a on a deeper level
so every sort of like order or intent is
basically like a shared language between
a user and a filler how many languages
do people in this room know I think I
know maybe like four I don't think
anyone in this room knows above 20 um so
I think it's like hard for us to like
think that uh fillers will know 20 25
different like intent protocols because
those are also sort of like shared
languages um and as I mentioned before
right these are like Financial contracts
and misunderstandings have a financial
cost attached to it if you sort of like
assume that this person wanted a million
dollars but you send $10 million you are
now down $9 million right so uh
misunderstanding here has a financial
cost so you want to make sure you're
interpreting and your share language is
tight um yeah I think as a filler in
this space once you have your strategy
once you have your Capital you spend
most amount of your time sort of
understanding how different protocols
work and how you integrate with them and
stuff like
that um now we are finally getting to
the EIP itself right if you think about
it it is just a translator everything in
sort of pink is standardized by the EIP
and everything in green is sort of open
for developers to build on so as a user
you send a cross in order this settler
contract it sort of like translates it
into a resolved Crossing order which is
standardized so that all fillers get the
same resolved cross in order so this
thing acts like a translator sort
of what's inside a settlement contract
like the thing in the middle in the last
slide it receives a cross in order it in
it sort of like has defined interfaces
to receive the order but then it's open
for developers to interpret it however
they want and then Dev can do like
whatever they want in the settlement
contract and then they sort of like emit
standardized events across the board
right uh which which include the resolve
cross in order that the fillers trust as
like source of Truth
almost um from a filler point of view
right consider this intent protocol one
that is 7 7683 compatible right so there
is a crossan order that goes in and you
can see a result cross in order order on
the other side that exactly
matches now I built another intent
protocol that is also 7683 compatible
but the devs did something on this one
what they did was
now if you look at the cross in order
and the result cross in order you will
notice that the destination chain ID has
been manipulated so in the crossing
order the two chain ID was 137 versus in
the result Crossing order the
destination chain is 420 because the dev
did something what they did was they
interpreted incorrectly so now the
filler thinks that he's supposed to fill
on chain 420 but actually the user
wanted funds on 137 so now the filler is
in in a in a tough spot even if he
executes the intent he will never get
fulfilled or never get his money back uh
this is basically because you I think
the the protocol is like too generic and
gives developers or like this settler
contract too much power and fillers
don't get any assurances of like what
exactly can happen in in the middle over
here uh so yeah the the core issue is
fillers can't trust data from like these
unauthenticated contracts they have to
go and sort of like audit read each of
of these settler contracts uh these
these contracts in the middle these are
called settler contracts in the ERC they
have to go and understand each of them
and only then they will accept data from
it so ideally we like the goal was to be
able to work with just standardized
resolved orders which you can find on
that bottom there resolved cross in
order idea was like all fillers will be
able to work with this but not really
people have to like fillers have to
understand the result cross in order as
well as the settler contract for them to
actually start filling this stuff right
so we are sort of like again in our
present world where fillers are
fragmented by like different intent
protocols which is the world we trying
to
avoid so I think like uh getting to
potential Solutions right otherwise I'm
just like complaining on the stage for
the last like 15 minutes uh some
potential solutions to this is that we
sort of have this like giant black boox
in the middle called settler contract we
sort of like break it down into smaller
modules modules that provide sort of
some guarantees to fillers on whatever
settlement that they want to uh operate
with right so we sort of like break down
this like big giant blackbox that
developers can do anything with into
smaller standardized
modules um one such module could be a
standard escro implementation idea is
like imagine the smart contract really
really simple smart contract you put in
funds with a key and with a time lock
and you attach an oracle with it now
funds can leave this lockbox either when
the timeout happens or when the Oracle
asks uh to sort of like withdraw so your
trust model as a user is like very well
defined and as a filler as well you know
if the funds have reached the lockbox
they are going to be unlocked for the
user in 2 hours but you can unlock them
VI the Oracle for the next like 2 hours
or like whatever the time uh limit is um
and this gives you like really strong
guarantees now and you don't have to
like care about what the settlement
contract does as long as funds reach the
lockbox and you have the ability to
build a right key I'm I'm planning to
write a little bit more about this
potentially another EIP building on top
top of
7683 but I think generally what I wanted
to convey with this entire sort of like
topic was uh intents are going to be
super important intents are going to be
the way we interact on chain intents are
going to be the thing that you see on
your metam mask when you sort of like go
and sign something so it's super
important for us to sort of have a
shared language around it and for that
shared language to be accurate um I'll
be collaborating with a bunch of people
in the space find me elsewhere and super
happy to chat about it but yeah that's
basically uh it thank you so
much good stuff good stuff by Bob so we
got a few questions if you want to ask
more questions you can scan the QR send
them up and they will um show up
automatically um but the first question
uh that'll come up slowly uh on the
screen is to ask is that should
cross-chain intents more explicitly
include execution of arbitrary call data
on the receiving chain on the level of
the ERC
spec I think like highly debatable um
and we should sort of like debate about
it um I think this as a use case
generally makes sense um I would I would
be in favor but I think there are
Arguments for not doing it as well so I
don't have a super strong
opinion okay next question can we ever
move away from the reputation based
system for solvers fillers do a cross
socket Etc currently actually slash
their fillers or punish
them I think the cool thing about this
stuff is that it's quite different from
all the consensus based models that we
have seen in inter before how INR used
to work before was you would send money
into a smart contract you would have a
bunch of validators and those validators
would be your truth Oracle in some sense
and then they would give you funds on
the destination so you would trust this
consensus or the this like Valor set to
give you funds on destination and that's
when like slashing and staking all of
that became important because if not
they would run away with your funds but
why this thing is cool why in why
intents are cool is that you don't have
to trust the validator set anymore and
there is no need for like uh slashing or
anything like that you you send your
funds they will either get fulfilled in
the next two hours or you'll simply get
your funds back and this is assured by
smart contracts onchain so it's pretty
pretty cool in that General
sense okay so is it not possible to
create the translation code for the
different intent protocol
languages I am I am bearish on it um I
feel like standardization in this like
intent world needs to happen like bottom
up rather than top down because the
application SP is like as wide as
basically any smart contract ever built
so I find it like super hard to sort of
go top down when standardizing and
talking about intents um I think my
current best bet would be having some
sort of like intent DSL like think evm
but for building intents something like
that sise at that generic level maybe
that makes sense but I would I would
honestly like go bottom up build like
standardized escros build like
standardized proof systems and sort of
have these Legos available for
developers to combine and build their
intent protocols instead of having like
a standardized intent and everything
else below that is a
blackbox all right one more question
that just came in instead of the lockbox
couldn't we have a user signature on the
intent and an offchain mechanism that
verifies that the intent output is in
intact via that
signature yeah I think the purpose of
logb Bo is like slightly different um
purpose of logbox isn't to sort of like
prove that uh you got exactly what you
wanted on destination that's the job of
the Oracle Oracle is your Truth uh
finder in this sort of scenario uh I
think Oracle is just to give Assurance
to uh fillers and users that if funds
enter this particular contract they will
exit only in these two conditions and
based on that you can sort of like uh
simulate stuff and have a guarantee that
if funds are entering the this contract
this contract is not poisonous and you
can interact with it pretty much like
how you do with erc20 is today uh even
with erc20 is you can have like weird
poisonous ec2s um rc20 is that charge
fees on transfers but because we can do
simulations on it you know that you know
like if you send 100 usdc your balance
is decreasing by 100 and someone else's
balance is increasing by 100 so you can
see like there's nothing poisonous there
I think if you have something like an
escrow there you can Sim and see that
hey funds are reaching my escrow with
the right key so no matter what is
happening with the settlement or with
the with the settler contract I don't
have to be worried that it's poisonous
or something like that okay probably the
last question just popped up if solvers
take the risk of finality how can we get
high security in insurances with cross
chain transfers priced at a few cents is
it
sustainable super solid question I think
it is not sustainable able if you don't
have a lot of fillers that's why we need
a ton of fillers if you have more
fillers we have more competition then I
am quite bullish that we'll have uh
people with capital fighting for pennies
and our our Crossing transfers can
remain like fairly
cheap cool