Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Unpacking Intents w/ Hyperlane’s Eda Akturk
Recorded: April 1, 2025 Duration: 0:41:02Space Recording
Short Summary
The Open Intents framework was launched by Hyperlane, Bootnode, and the Ethereum Foundation to facilitate intent-based applications, particularly for new blockchain networks. ERC-7683, proposed by Acros and Uniswap, aims to standardize intent protocols, enhancing composability. The framework introduces innovations like solvers acting as off-chain middlemen, allowing for faster transactions. This development reflects a trend towards creating structured frameworks around ERCs and highlights the importance of interoperability among blockchain networks. Collaboration among major networks like Espresso, Hyperlane, Arbitrum, and Optimism underscores the industry's move towards unified infrastructure.
Full Transcription
Hey, everyone. This is Composable, a Web3 podcast that takes you deep into Web3's building blocks.
I'm Alicia, and we have Ellie as well. And with us, we have Edda from Hyperlane, who's here to
talk about the Open Intents framework. We're very excited to hear about it because obviously
Intents are super popular at the moment. So Edda, you want to introduce yourself?
Yeah, for sure. It's never not scary when you're live.
So hi, everyone. My name is Ada. And I'm a developer advocate part of the Hyperlane team.
And yes, as you mentioned briefly, we recently launched the open intense framework, it was
actually like a very collaborative effort led by Hyperlane, Bootnode and Ethereum Foundation.
effort led by Hyperlane, Bootnote and Ethereum Foundation. So it's been great to see like how
it's been received. And I'm happy to like deep dive into it. I guess like many people heard of
it, but not really familiar with all the nuances. So yeah, excited to get to that today.
Yay, sounds good. Ellie always has some sort of take. I'm so interested to hear what's the
take on Intent right now. Yeah. So let me think about what's the Twitter take on Intent. So I
think 7683. Am I getting that ERC right? Anyway, Acrosse and Uniswap. It's so hard to keep these
numbers track of. Anyway, so yeah, there is this Intense ERC-7683 that's very popular right now.
It was proposed by Acros and Uniswap, and kind of its goal is to make a lot of these different
intent protocols more composable with each other, you know, so kind of have a clean way to
like define the information that you need.
And so I think from what I understand of the open intense framework is like, you know,
that's kind of taking it one step further
and, you know, defining a lot of things
so that we can really have composability
between all of these different intent systems.
But yeah, I think on Twitter,
I'm not so sure if a lot of people on Twitter
are familiar with the open intense framework yet.
But yeah, I know
Josh Rudolph and Hyperlane, you know, talk about it quite a bit. I think that's a great starting
point. And maybe I can start by talking about like the ERC a bit and then kind of segue into why,
like, yeah, as you mentioned, like how the open intense framework kind of differs,
like not differs, but like is different. my english fails me um so so exactly as you mentioned ellie uh so across came
out with their uh standardization they built it together with uniswap erc 7638 or yes um which
you just think before and that standardizes a way to create intents so that's like a standard hey like when
you make intents like make it this way this is how the order book should look like uh which is
great when you standardize you know how things work but the kind of key missing thing and what
we try to do with the open intents framework is that okay now we have the standard here but how
can we make it easy for people to build with because if you still have the standard here, but how can we make it easy for people to build with? Because if you still have the standard, but not like ready to use code or ready to use like infrastructure,
it still kind of like introduces like a barrier of entry.
There's still you need to like create your own solver implementation, create all the infrastructure yourself, you know,
go and make like, like have your chain added to the solver intent frameworks, et cetera.
So that's kind of how the open intense framework came to be.
It's like we have all these good ideas
and how to build intents.
Like they're really efficient, effective,
and we can get to that because I feel like intense
is also kind of a buzzword, which is kind of like many people
say it, but not really like well-defined, I guess.
But once you have that ERC, I don't
think that's sufficient to create
adoption you need to like build the framework you need to like explain to people how like you can
directly use it you need to like have something that's set up easy to build like intent-based
applications and that's exactly where the open intense framework comes in because um you kind
of want yeah like as a developer i think it's important to be like hey like i want to get this
up and running in like five minutes and if it doesn't work in five minutes i'm not going to work on it
more um and that's kind of how the open intense framework came to be and um that was our goal
like at hyperlane what we try to do with like building open open frameworks is that we want
it's easy for anyone to come in and take it and actually be like oh i actually have everything i
need that's amazing i think congratulations to everybody involved in this framework because come in and take it and actually be like, oh, I actually have everything I need.
That's amazing. I think congratulations to
everybody involved in this framework because I think
it's just showing a maturity of
the ecosystem right now because at first,
when you build in Web3,
you don't even realize that there are things like standards.
Then eventually you learn about standards like ERCs.
Then you're like, okay, cool, I'm using the standard,
but what should it connect to?
How do I create a font and how do I make it in such a way that it's actually user-friendly?
So I think this framework is something that I can see becoming a trend,
like not just the open intent framework, but the idea of creating frameworks around ERCs
and all the other components in the stack. So I really like that. And I think before we talk
about the components in the open intent framework stack, it'll be good to talk about what intents are for who they are meant for
why are we talking about intents why is it called an intent yeah
uh yeah for sure actually on this point i kind of want to add a bit more on the like baking ercs
usable uh my entry to crypto well building like in crypto or Web3, was it like it
was more buzzword then, was do scaffold ETH, which was a tool which you can easily create like
applications like React based applications which have their backend and frontend. And that's how I
got to like easily understanding how this ERC like it was, you know, it was just like an ERC20
creating your own token or like ERC721 where like you create your own NFT. But it was so easy to like use this open, open tool
where I have and quickly like spin up my own react app where I don't need to connect my backend. I
have already the chains connected. And that's actually how I got to like meet Austin and all
the people and kind of started my journey. So I'm like very very a big fan of open frameworks which make it easier for anyone
to do that and to answer your question on what is the open intense framework but also just to go
back to answer what is intense is intents are a way that changes how transactions work uh well
not changes how they work but they basically allow users to specify their goals instead of
where you do today or like in a regular transaction where you're like, hey, I want to swap my tokens
on Uniswap for this rate. And this is, you know, I'm submitting this transaction with all the call
data. So you have to specify all the details of your transaction when you're submitting.
But when you think about it, most users or applications just kind of want to get to the end results.
Like, let's say you have like some ETH, you want to get some USDC.
So you don't really be like, hey, like this is the exact rate
that I want to submit the transaction on Uniswap.
So that is one way, like mostly how transactions work.
And in the intents, when you want to use intents, is you say, hey, like I have this e-tokens,
I want USDC.
And I kind of want to like pay, this is the maximum I want to pay for my exchange rate.
Can you just like, can the best actor possible do this instead of me like specifying all
the details?
So that is kind of how intents work and what they change. And you might be like,
okay, like, what does this mean actually for me? Well, this means that you don't, first
of all, as an application, you might not be aware of the infrastructure underlying where
you cannot like know the best path to get to the results you want to get to. Instead,
you kind of offload that responsibility, finality risk that seven day like settlement
period onto these off-chain actors called solvers um and it just makes it easier for both users and
applications to both build and to get like fast you know fast swaps um and i know like like there's a really good presentation that Hart made at DevCon,
where he talks about like a two second time
to like exchange as well.
And that's kind of how intents allow you,
like that's, so intents kind of allow you to get there
is that you have this two second like user experience
so that people don't leave the screen
without their transaction fulfilled.
Yeah, definitely. And they don't have to worry about which chain am I on?
Am I bridging? Is the transaction going to succeed? And you said some terms there like
settlement risk and finality time. So I know we'll get into that soon. Ellie, I'm curious,
what is your definition of an intent? No, I think that that's a really,
a really great definition. I think my definition of an intent is literally just, you know, an
intent, like whatever the user wants to do. I do think a lot of the times on Twitter,
intents usually are specifically referring to cross bridging or cross chain swaps,
cross chain swaps, which they can be a lot more than that. But that's like right now the main use cases.
which they can be a lot more than that. But that's like right now the main use cases.
I guess what's helpful for me is to like kind of walk through what happens when a user, let's say, bridges to another chain using intents.
So the user says, Okay, I want to go bridge to Arbitrum from Optimism. And they go to like across his UI, they submit this.
And like, how does this transact? Like, how does the user actually bridge in two seconds?
Like what is happening under the hood?
So yeah, like Etta said, we have these solvers.
Generally, the solvers tend to be a little bit more sophisticated.
And what they do is they listen for a user's intent on the source chain.
And then they front the user money on the destination chain.
So if I want to
bridge 10 ETH from Arbitrum to Optimism, the solver would say, I would lock my 10 ETH on
Arbitrum, the source chain, and the solver would give me their 10 ETH on Optimism. So that's kind
of how it works. And then what settlement is, is that eventually the solver needs to go back to
Arbitron,
the source chain, and get my 10 ETH that I locked up so that they're made whole. So that's kind of
what's happening under the hood. And that's why it can be so fast is because you're not actually
bridging funds. Someone is just kind of giving you the funds on the other side, and they're
assuming that they'll be able to get your funds on the source chain at some point in
the future. Yeah, I love that you brought on the steps because it kind of underlines the point of
intent is that it's not about the how, it's about the what. Like what would you like to do? I would
like to buy this asset. For some reason, this asset is not on the chain that I want, it's not
on the chain and therefore I have to bridge. But as a user, you really don't care and you don't even want to deal with the risks involved. So then you have
these solvers who are able to do that on your behalf and then achieve those speeds that I
mentioned, like two seconds even. And I think that is getting us closer to like just the typical
everyday experiences that users today are used to. But I think us in Web3, we have a lot more
tolerance for like all the steps involved, like the bridging, et cetera. But I think us in Web3, we have a lot more tolerance for like all the steps involved,
like the bridging, etc. But pretty soon when we're on board, like our parents and grandparents and
cousins, you know, we definitely have to have better experiences. Maybe a quick hot take. So
it's kind of a meme on Twitter that intents are just equal to limit orders. And so what do you guys think? Are intents limit orders
or are they more than limit orders? Let's see. I mean, I guess it is a limit order, right? Because
you're asking someone to execute something and they're probably only going to execute it at a
time when it makes sense for them, whether it's profitable because the solvers are competing.
I think I like to think of solvers like
middlemen. And I know middlemen is normally like a bad term because you think of a middleman as
someone who is trying to extract value unfairly and making things more expensive for you.
But in an intent network, an intent framework is a bit different because you have a bunch of
solvers competing. And because they're competing, they tend to give you the best transaction. So
for example, if you use a cross protocol, the fees to do a cross chain bridge is not that high.
And you'd think it's high because there's some middleman charging you a fee, but because there's
not just one solver and it's an entire network of solvers and they all want to benefit from this
transaction, the fees kind of get to as low as it possibly can be can be so yes it's like a limit order but I think
it's actually just introducing an off-chain middleman which is kind of controversial in my
mind but yeah no I like that answer what do you think Ada so um I kind of agree with that I do
think it's quite similar to how it works like you specify like your maximum limit you let like others
kind of handle what you want to do um but i i don't like i i think it's easy to make like comparisons and be
like hey like this is very similar just creates like a mental model in your head i'm sure there's
like some nuances but i think it's a fair like um like you can kind of say that and i don't think it's a bad
thing it's just like easier to explain and just add like the extra features uh to alissa's point
on like the the solvers i think it is pretty cool like to be like with the open intense framework
there is like an open source solver implementation, which I think makes it like accessible to a lot more people to like easily run
because otherwise it's quite hard to like,
you know, make your own infrastructure and run it.
But I think that's like actually a key component
of the open and transfer framework,
which might, you know, lead to having like an actual
solver market where people can freely run their solvers
instead of like it being more closed source.
That's a really good point.
I didn't even like realize that that is unlocking that.
It's almost like unlocking a new paradigm
for people in Web3,
like a new avenue to like earn,
like run a solver
because you can earn from benefiting
from filling these transactions
regardless of what the protocol is.
I don't know how easy it is
to become
a solid one across network but potentially if an application is built using the oif then you know
it should be a bit easier is that what you're saying it should be easier for like anyone to
like run the software and be a solver in that network um yeah i mean you still do have to like
run your own infrastructure but you actually have have like the base open source implementation to do so.
We'll see how practical it is and how many people actually do run it.
Like it's still like a very new framework.
So kind of, yeah, like I think with the framework, we try to build it and like see if they're like, what is the take on, you know, how the pieces are used.
But it does provide you all the like actual code base
to be able to do that interesting so i'm starting to think just based on the discussion so far that
a good hackathon project would be to build a limit order decks using the oif because i feel like that
would work really well and then i think we can talk a bit about like the exact differences between
intents and limit orders. Yeah. So since we're here, we're talking about the various components, let's just talk about it. Like what are the components of the open intense framework?
Yeah, and I actually, so one other thing which I didn't mention about why we built the open
intense framework, and I think it's actually important to mention and I should have like when I was talking before is you know like the intense
concept is out there like there's the ERC already so you might be like hey okay like why why is there
this framework and it's fair that you know it's as I mentioned you know it's easier when you have
the code base when you can actually go in and like run it up in a moment but also like today
when you want to build intent-based applications there are like some hurdles, like you have to run your own
infrastructure, or you have to partner with an intent based protocol, which is great if you're
like a chain like base or optimism, and you have that resources to be able to go and like, hey,
like, can you prioritize my chain, so that it's added, and I can easily use this intense. But if
you're like a smaller chain, and or, you know, you're just launching your new chain, now it's added and i can easily use this intense but if you're like a smaller chain and or you know you're just launching your new chain now it's so easy to run your own roll up
with like platforms like caldera uh where you're like hey i just spinned up my own you know elisa
chain uh what do you do with that like you can't just go and like partner with an intent-based
protocol it might be lower priority you might like need a lot of resources to do that um so
not only do you only have like you can either partner or you have to build your own infrastructure
which introduces too many barriers for entry so what the open intense framework does is it kind of
removes that friction over there both in terms of you don't have to go and partner uh verse and also
you don't have to build your own infrastructure you still have to run the solvers as i said but that's kind of actually not another key point which i didn't
mention before and i think it's important to kind of mention here now and to answer your question
what components does the open intense framework consist of is i like to describe as like three
pieces so there's first of, the smart contract piece.
It does use a base, ERC7683.
I'm glad that note was passing just when I was reading.
It uses a base contract, which is the ERC7683.
So you can start with that. The second component is the open source solver implementation.
And the third is the UI.
So you actually have like an out of the box ready to use UI, um,
which can get you started because you know, like front end work is, you know,
you might just want to be able to test quickly.
Obviously I see most people like migrating off the, you know, the,
the base like UI to their owns, but, uh,
that is basically like the three major components,
the smart contract based,
the open source software implementation,
and then the UI.
Yeah, I really like that you guys package the UI with it
because I think that that's something
that a lot of frameworks, they obviously don't do.
And I know myself, like I'm not a front end dev.
And so if I had to make a UI,
that would be very difficult for me to do. So I think that that's actually like really great to just have it out of
the box. Yeah. And to mention, like, it's very customizable. So I too do not like UI work. But
it kind of gives you like very easy access to be like, hey, like, I kind of want to, you know,
change the logo, change the, you know, you know descriptions etc so it makes it really um i don't want to be like hey these pieces are like set in stone and
you can't change it but they're basically like the modular building blocks where you can add on to
um your custom features and integrations etc yeah i was literally just about to ask that if you
could swap elements out so is the ui component like the, I know the Hyperlane has like a UI for warp routes maybe.
I think you guys have like some boilerplate
or template for that.
Is it similar to that?
Yes, exactly.
So I am just like also making sure to see if I can show it.
I'm not sure if I can screen share,
but it does use the Hyperlane warp UI templates.
So it's pretty much similar.
That's actually kind of why we built it.
We saw that people were very easily using the Hyperlane Warp UI when they were deploying warp routes.
And this was actually also my experience with scaffoldies as well.
We saw that people don't really want to build like a UI when they just want to get started.
But it does have like the prebuilt UI.
If you go to that website, which is linked over there,
you also see like a demo video built by boot node
where they can access it.
So you'll see that also in action.
All right, perfect.
Maybe we can talk about, you know,
who do you think is the audience
for the Open Intense framework?
I know you talked about like new chains, but like which kind of devs do you think is the audience for the open intense framework? I know you talked about like new chains, but like, which kind of devs do you think are the audience for it?
Yeah, that's a nice question. I do think like new chains launching who want to build
intent based applications are the best target audience. As we mentioned before, it's a pretty new framework,
which we launched, I think it's been one month,
maybe like one and a half.
I don't think it's been longer.
So again, the target audience
and the problem statement we started with
was if you were a new chain,
it's pretty hard to build intent-based applications
because you don't have the resources or the infrastructure. So I think it's, yeah, very like new app builders, app builders on like new
chains, app builders who want to build like cross-chain apps. So not just on one chain,
but want to build like on multiple chains. I think that's like a good target. I know that there's
the current day, the Espresso hackathon running. So I'd
be curious to see how many people build with that. I think it's ending today. So hopefully we'll see
like who submit. I'm very excited to see the results over there. But generally, yeah, as you
mentioned, it's people building on new chains, people who want to build cross-chain applications,
I guess, are the main target.
Yeah, I've had a sneak peek at the hackathon submissions.
And yeah, a lot of them use the Open Intense Framework.
And it's really cool what they have been able to build in a short amount of time.
I definitely want to see that. I haven't seen them yet.
Oh, that's amazing. I want you to explain a bit more about the problems you mentioned
that if you were a new chain it's hard for you to set up intense i don't really fully understand why
could you explain that a bit more yes for sure um so um one thing which and so i don't want to
like i think there's a great podcast with Heart and Nam, which was on the tokens.
Like, I don't remember exactly, but I think that is also a great podcast to listen to.
I'll try my best to explain.
But just want to call out that I'm mostly like taking the conversation topics.
um so the reason we built well collectively built the open intense framework is that it's
um we've seen that intents are kind of becoming popular it's makes your it makes ethereum feel
like a single chain again because you can like swap in a very short amount of time like that
two seconds which we kind of mentioned before uh but what we see is that building with intents are hard the reason
building with intents are hard is if you are a big chain or like it's easier because you can
partner with intent-based protocols you can go to like across and you can be like hey like i'm
optimism i need to like have intent so you can set up that you know access the solver networks
and kind of set up your chain and you know know, all the applications on it is easier.
But if you're a smaller chain, you know, you might not be top priority.
So you either need to like invest a lot of resources.
So you can't really like get intent based applications without running your own infrastructure.
So that includes like the solver networks, creating all the implementation,
like how you will build out like the intent structure.
Yeah, you can use like the standard,
but if you're also your own chain,
you can kind of come up with any kind of,
any kind of new mechanic you want.
Well, access you want,
well, I guess you would want to like access other chains,
but you know, you have the flexibility to do so.
But yeah, like the core problem was
because when you just launch,
it's hard to like either partner or either set up your own infrastructure. And what you want is like,
hey, like I built an app, but like no one's using my app or like I can't even like set up intents.
So that was kind of the two main issues that we saw like devspacing. And even though you have
like the standards out there,
having the standards in my opinion is not enough.
You don't wanna like create all the infrastructure
which people are building
and everyone's kind of building their own silos.
But I think it's cool with an open intense framework
is that there's so many partners like building together
like a core shared infrastructure.
So you don't need to like, you can just opt into like,
you know, you can go ahead and use the,
like it currently uses the Hyperlane ISM
for security module, but you can kind of switch it up.
You can use like another,
you can use the Arbitrum intent engine if you want.
Like you have the flexibility to kind of build
like plug and play to these different modules.
So you're just not like building your silos,
but I'm not sure if that answers your question,
but happy to that paper if it doesn't.
Yeah, no, that makes a lot of sense. I can imagine if I were to create a chain today,
so like you were saying, Alicia chain. Now, how do I attract developers to build on this chain?
They want to see user activity. They want to see volume. And again, if I'm a solver,
how do I attract solvers to come and fulfill for these intent protocols that these developers
do build on the chain. Again, like
they have to be incentivized. So I can imagine if there's a solver who already integrates it with
a cross protocol and they know how to run that infrastructure and they have the liquidity to be
able to front for these cross-chain transactions. If I want to get them on Elysia chain, but then
they have to learn how to run their solver for a new app on the alistia chain then that's going to be an issue
but if that app is built using the oif framework and then there are lots of apps built using that
framework then as a solver you have it's easier it's like you're lowering the barrier of entry
for them to then become a solver for your particular app or for a developer to actually
build an app using the erc that you mentioned, as well as having a front end.
So that makes a lot of sense.
In some ways, it's like increasing composability of intent apps, just like how you have standards like ERC-20.
It makes it so that any app that accepts tokens, once it's ERC-20, it will accept your token once it's using that standard.
it's ERC-20, it will accept your token once it's using that standard. So with this, it makes it so
that if you are a solver and you've already integrated with another intent framework or
intent-based app, you can easily integrate with another. So we're increasing composability for
intent-based applications. Exactly. So I think that's a great way to explain it. I think you
nailed it on all the points. And it might be like, okay, why is this important as well? I think that's a great way to explain it. I think it nailed it on all the points.
And it might be like, okay, why is this important as well? I think it's kind of clear that with the roll-up,
with so many roll-ups, with the roll-up scaling roadmap,
it's clear that there's so many chains launching.
There's so much friction when you want to go from one chain to another
that it's just not an okay user experience and no one wants to face that.
So unless we solve this, it's just not going to work out when you have like, even if you have like five big chains, they definitely need to talk to each other.
And I think working with Intense and the Open Intense framework is a very good solution to see where it goes.
Yeah, I'm very excited about this. People on Twitter often talk about the fact that there's
so many infra projects and there's so many user experience pitfalls. And I can imagine that this
is like a beautiful example of how you need both a good UI, both good frameworks.
And also, when I say frameworks, sorry, but like standards, like ERCs.
And also having the infrastructure side, which is a solver network part of things, working together to then improve upon the UX problems.
Because hopefully in the future, a user does not have to think about what is an intent?
Am I using an intent bridge?
They're not even using a bridge.
They don't know they're using a bridge but they are but they just are conducting a transaction
exactly so like all the people um all the like projects working with the open intense framework
i think the goal is common as you said to attract the complexities of all this infrastructure and
make it very easy for users to use and also developers
to adapt. Maybe if we can briefly go ahead kind of go back to something we touched on in the
beginning is maybe we can kind of dive more into the risks that these solvers are taking because
I think that that's very interesting and that's where we I don't know I think that that's where
all of the interesting stuff happens because there's a lot of different modules you can choose
in the open intents framework, for example, like how you settle your intents, etc. that affect
these risks differently. So yeah, I don't know if you want to, Etta, you want to give us a rundown
of like what these, like, how the solvers take on risk? Yeah, for sure. And I think that's a quite
important part, because that's kind
of how the whole intent based system works um and just to talk about what we mentioned by the solvers
take on the risk is that when you kind of submit an intent like well when you submit a transaction
it's like you would actually like specify the details but now with the intent based system
is that hey like you are just submitting a transaction and you're letting this off-chain uh specialized agent the whole solver network kind of competes to get your
like to get your transaction and to submit it so what this means is that they kind of take on the
they don't like you don't have to wait for settlement which is like in an optimum like an
um like in optimism you don't have to wait seven days for your transaction to be finalized
but instead the solver is like hey like you can pay me the fee i will take your transaction and
i will actually set like take it um i will give you your tokens and if there's a risk i will be
the one who is kind of slashed or like who is um who is affected by you know every org or something
like that um so that's kind of what we mean by now the
solvers, like you offload that risk to this other off-chain agent who has more knowledge than you,
so who can fulfill the request like much faster. But also they are like taking a fee. So this means
that they are kind of taking on a risk that in case like there's a chain org, they will be like
affected by that, if that makes sense.
Yeah, no, and I think maybe it's, it's like useful, at least for me to kind of walk through
an example of like how a reorg actually affects this, because I think sometimes it's a little
unclear. So for example, let's say a user is bridging from Arbitrum to Optimism, just like
we had before, and the user deposits their 10 ETH on Arbitrum. And then the solver fronts them 10 ETH on
Optimism. But I think the question is, how does the solver know that the 10 ETH was actually
deposited on Arbitrum? And this is where things get a little interesting, because a lot of solvers
today, admittedly, will just listen to the roll-ups sequencer. And roll-ups will give a
sequencer confirmation really quickly within less than a second, depending on what rollup it is.
But here's what could happen. Here's what could go wrong. So the, uh, the solver sees that the
user locked funds on Arbitrum via the centralized sequencer, but this state is not finalized on
Ethereum yet. So it's like, keep that in mind. Um, and then it sends the finalized on Ethereum yet. So keep that in mind. And then it sends the user
funds on Optimism. So it sends its 10 ETH. Now, what if Arbitrum reorgs and it reorgs out the
block or the transaction that the user locked their funds in? Now the user has 10 ETH on Arbitrum
and they have the solver's 10 ETH on Optimism and the solver is now out 10 ETH. So this is kind of
like how a reorg can affect solvers. And, you know, this relates to a lot of what we do at
Espresso, which is, you know, you have different levels of confirmations to trust. You have the
sequencer confirmations, which are very fast, but, you know, they come with risk because sequencers
can reorg, you know, and they can can read sequencers can actually reorg without being
malicious like a sequencer could reorg just because it crashed potentially um you know and
then you kind of have other intermediate uh intermediary uh confirmations like an espresso
and then you finally have like l1 finality uh so anyway yeah that's kind of just like a walkthrough
of kind of the choices that solvers have to make and you know what could go wrong and like why the solvers are taking on this risk. That's amazing thanks for
coming through with that example I hope people could visualize and follow everything in their
minds but I think you explained that so perfectly I'm also curious Ada when you guys have been like
you know going through the
process of creating this framework, have you been speaking to solvers and hearing their concerns as
being a solver and participating in a solver network? And if so, can you share any of them?
That's a good question. So I'm actually, I'm not sure, to be honest. I'm guessing so. I wasn't particularly involved in building out the framework.
I jumped in after I saw.
I was like, oh my god, this is so cool.
How can we work on it more?
I'm assuming the answer is yes, but I was just thinking out loud.
I'd be curious to hear if you guys have any ideas, especially like working on
the hackathon with the open intense framework for a while. But I would think that definitely
because like there is the open source solver implementation built out by the teams. However,
I'm not sure about the mechanics or how kind of that came through.
Yeah, I think on my side, my knowledge
of how solvers feel is a bit more on the theoretical side, like me just imagining,
because if it is a competition, like the fact that you are supplying, you're essentially supplying
liquidity. It's a bit different than a liquidity pool where you're subjected to how the liquidity
pool is automated by whatever algorithm, but instead you have an opportunity to decide which
transactions you want to fulfill. So like if there's a transaction where the size is way too high, you're like, I'm not risking my funds
and optimism for you. I don't know what's going to happen if the sequencer reworks. I'm like,
you know, they can decide not to. And I think that's great that they have that flexibility,
but at the same time, they have to be super fast and also they want to earn from the fees.
So if they have to be super fast, then of course,
they would be willing to trust something like perhaps sequencer confirmations because it is
quite fast, but maybe up to a limit because again, they don't want to risk too many funds in the
event that there is a reorg and that is potentially affecting their fees. I'm assuming that the fees
could be proportional to how much you transfer, but I'm actually not sure. But if that does impact
how much you make, then of course you're trying to get as fast as possible whilst
minimizing your risks. I think it's all well and good that we're making it easier for regular users
to conduct these transactions and they don't have to think about everything, but we have to think
about all the actors in the system. So we've thought about the devs, we created this framework,
we were thinking about the users constantly, but also the guys who are supplying the liquidity,
guys and gals, supplying liquidity, the solvers,
thinking about them is thinking about the risks
that they're taking on and optimizing
for being fast and secure
so they can make as much money as possible.
You know, all of it has to work together.
So that's how I view solvers.
But honestly, I would love to speak to more solvers
to actually hear from them, like what their issues are and what will make things better.
But I don't have concrete evidence right now.
All right. Maybe like we're kind of getting a little bit close to the end. So maybe a question
is, so if the open intents framework succeeds and becomes really popular,
like what do you think
intense will look like two years from now two years a very long time
so i think if the open intense framework successes and like becomes succeeds and becomes like very
popular there will be all these like small building blocks which you can also change and
add to it like for example like
the base security layer that it comes in with right now is the hyperlane ism but you can have
like multiple options right like you don't need to opt into the default or the base contract is the
base 7683 but you know my maybe you have like there another standard which kind of want to opt
into besides that as well so if it
becomes successful i'd imagine that there's like multiple building blogs and you see much more apps
using it users not really caring or like you like as a user i don't think i need to know that
it's like an intent or it just kind of fulfills my action so So I would see like more adoption of also cross-chain applications.
And it just makes it like easier to build apps. And as a developer, you have like much more
modular building blocks to kind of plug and play. And as a user, you just get like more apps which
use the open intense framework in the backend, which means you kind of get like faster
and better user experience.
What do you, like, I think this is like,
obviously my like, yes, for the future,
but if you guys have any other ideas
or I'd be curious to hear as well.
Yeah, I mean, I think, I feel very confident
that Intense are going to play a very major part
in composability, like in the future. I mean, I think I feel very confident that Intense are going to play a very major part in composability, like in the future.
I mean, I think that that's a pretty popular opinion, but, you know, they really just offer something that gives users such a good experience.
And it also gives, you know, solvers a very good experience as well, because they get to kind of choose what their liquidity is being used for.
And they can be very granular in what they choose is being used for.
So, yeah, I think Intents are going to be very big.
What I would hope in two years is that there are a lot of kind of like intent solver networks
and that they can be very competitive and really offer users very good prices.
And I kind of also hope, you know, that these solver networks, well, because they can actually
share individual solvers, because if everybody follows, you know, the same standard, you know,
a solver can go from one network to another, and I think that that's nice because it will have,
I hope is that we won't have like an oligopoly of solver networks or a monopoly of solver networks,
but we'll kind of have a lot of decentralized solver networks. Lucia, what do you think? I think that's a great answer.
I definitely agree with both of you. I think there's also a tension between solver networks
and other methods for resolving cross-chain transactions. And I think two years from now,
we'll be able to see who wins. I do think the solver network approach is very practical.
It is in use today and you know as a
like a participant in that you can choose how fast or slow you want to be whereas for example
if you were to use zk to resolve a cross-chain transaction there are limitations that currently
you know we're facing so i think that definitely because of intense we will be able to have a lot
better user experience experiences for everyone involved the solvers
the developers and the end users uh one thing i do also want to call out is i think this is
well to my knowledge like one of the bigger like ways like most l2s or like different networks have
come together to build like a framework together um which i don't think is very common and crypto overall like people build like
their own pieces of infrastructure so i think like this is kind of a nice um a nice way to unify
ethereum although like it's not like a single chain um you can kind of have these open frameworks
kind of working together so hopefully it'll also be like an inspiration for other kind of contexts,
not just like building intent-based applications,
but like other contents,
like seeing all like Espresso, Hyperlane,
Arbitrum, Optimism, et cetera,
come together to build like something together.
Oh, so beautifully said.
And I totally agree with you.
It's so refreshing to see all these protocols come together.
Like when you see the list of protocols involved,
you're like, really?
All of these people are coming together to do this?
What?
So yeah, I love it.
All right.
So I guess we can wrap up.
You know, what is a question that we can leave for the audience?
Maybe the question is for the audience is that,
you know, if you're a dev out there,
would you consider using the Open Intense framework to like quickly spin up a cross-chain app? If you're someone who would
was not considering making a cross-chain app, would this like change your mind and, you know,
make you consider actually doing something cross-chain because it's very easy? Yeah,
I'd be curious to hear what devs think. Amazing. Eda, do you want to plug anything plug yourself plug hyperlane
so we have a blog on the open intense framework and how you can start building on it it's on the
hyperlane medium um i think that's like a good place to get started uh to learn more about how
the framework works and how you can get more details.
I also want to call out to the workshops
we did at the Brew and Build hackathon.
I gave a short introduction to the Open Intense framework
and then Bootnode, who's also one of the core developers,
had a walkthrough on how it can build
with the Open Intense framework.
So I think that's a great resource
for anyone who is interested.
Yeah, we'll be sure we can link those like a great resource for anyone who is interested. Yeah, we'll be sure that we can link those
in the show notes for anybody who's interested.
Thank you so much.
All right.
See you in the next one.
Bye.
Bye.
Bye.
Amazing.
