Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Unpacking the Open Intents Framework with Josh Rudolf of the Ethereum Foundation
Recorded: March 21, 2025 Duration: 1:02:49Space Recording
Short Summary
Espresso's inaugural hackathon marks a pivotal moment for developers, focusing on interoperability and collaboration across chains. Key figures from the crypto community discuss the importance of partnerships, trends in intent-based bridging, and the need for user-friendly solutions, all while emphasizing the growth of the ecosystem.
Full Transcription
Oh, we are live.
My name is Jill.
I'm one of the co-founders at Espresso.
We have had the pleasure of collaborating with this group
and many others on all of the open and intense work
that has been, I would say, really
shepherded by Josh here at the EF.
We're happy to be joined by him as well today.
We decided to get together at this conversation
because we are collectively running a hackathon
right now. It's Espresso's first hackathon welcoming developers to our community and our platform.
And one of the tracks within the hackathon is all about intents. And what we've learned is that we
get a lot of questions from developers on just what this is about, really how interop works
across chains under the surface. A lot of amazing developers who are really deeply familiar with
smart contracts have not delved into this space. So if you're in that category, you're in the right
place, this is what we're going to be talking about today. We are also going to talk about this at
like a slightly higher level as well, of course, which is why going to talk about this at a slightly higher level
as well, of course, which is why we should care about this
to begin with.
But I'm really excited to dive in with this group.
So maybe to kick off, I'll call on each of you
to just give literally just the briefest of introductions,
just your name, what company you're with.
And then I would love for each of you
to share the last thing that you did across chain,
whether that was as a user or as someone who's building
kind of from the developer side, either way works.
So Spencer, can I kick it to you to get us started?
Yeah, sure. I'm Spencer.
I'm a product manager at off- chain labs focused on interoperability. Last thing I did cross chain was probably
withdrawal from hyperliquid.
Withdraw to where?
More specific?
Back to Arbitrum.
Cool, back to Arbitrum, of course.
Cool, Nam, do you want to take it away?
Hey guys, my name is Nam.
One of the co-founders of HyperLin.
And yeah, super excited to chat about Intents today.
What was the last cross-chain thing that you did?
Last cross-chain? I think it's a lot of like, I don't know which chain, but in my, I guess effort, we have to move a lot of like funds to a new roll-up, and then we always have to find, oh, what is the right bridge to do that?
So it's probably some gas money just to like be able to deploy contracts on a new chain. Oh my God, moving gas money around is,
yes, it's like too much of all of our lives. Cool. Kanishk, do you want to take it away?
Absolutely. Hey, everyone. My name is Kanishk. I'm a DevRel Ad Across. My focus is mainly helping developers learn intense, learn and draw, and obviously hack at the hackathon.
The last thing that I did on-chain was beg my friend
for gas and then pay him back.
So that was a fun discussion we had.
And I was like, can you send me $2, please?
But I was basically in.
It is funny how gas is always a very common theme.
I love it. And Josh, have a for yourself.
Hey, y'all. I'm Josh. I work as a PM on the research team at the EF.
These days, I also focus on interoperability.
I'm really excited and grateful for all the people who have been working on Interop for much longer than myself,
everyone on this call and many others who have allowed me
to now hopefully help coordinate and accelerate things.
But yes, I cannot take credit for all of the great work
that's been happening for a long time there.
Yeah, last cross-chain thing was probably
an in-app swap in a wallet that is currently using maybe more of a trusted
solution. Hopefully we can get to more of a trust minimized solution. But yeah.
I love it. I'll share for myself. One of the last things that I tried to do across chains
was I had some money on Polygon from a failed attempt to experiment with Polymarket, but I'm based in the US and
I couldn't get around their firewalls. Good job. And I was trying to move some money to
base to participate in Echo sale, which is like a crowdfunding platform. And I couldn't
do it in time to participate in the sale. And I was very sad that I missed it. And I
was like, I've been here for 10 years. How am I still so bad at this all of that to say I think that
you know we are all feeling the benefits of all of the work that has been done on
cross-chain activity making it easier smoother cheaper faster but we're also
all still feeling the pain points there's still a lot of work to be done.
And yeah, if you are, you know, if you are a developer working in this community, then we
welcome your efforts. And we'd love to get you involved in contributing to better cross-chain
experiences. But now maybe we can start with you. And can you, because Hyperlane has been building in this space, Crosschain, for many years.
I actually don't even know when you guys got started.
Maybe you can share that too.
But can you share a little bit of how you've seen things evolve, both around intent specifically,
but also the role, like like messaging standards play in that,
maybe take us back a few years
what the state of affairs was for cross-chain interop.
And then we can work towards today and how we've gotten here.
But before I do that, Hadrien,
because you're back on stage now, we've been missing you.
Can you give us your very brief intro
and your last cross chain experience?
And then we'll kick it over to Nam.
So, hello, I'm Adrian. I work at Open Zeppelin working on the Solidity team,
developing smart contracts for everyone to use and having some experiments trying to build cross chain smart contracts.
And so, yes, my last experience was trying to build adapters and basically do test transaction between,
I think it was Sepolia and Arbitrum or Bayes and Arbitrum
doing L2 to L2 communication using the standard interface
we're working on.
How did it go?
It went fine.
I mean, we had a lot of local testing,
but at some point we wanted to go on a real test
net and show it worked.
Awesome. Cool. Well, a much more sophisticated going cross-chain experience than mine was, certainly.
But yeah, love to hear it. That's awesome.
Okay, Nam, do you want to take us back in time into a little bit of the history here? Yes, happy to.
We actually on Tuesday was our three year anniversary.
And so, yeah, three years ago is when we started kind of like on this journey.
And I remember, like at the time, everybody already felt like, oh, my God,
why are you starting another project?
Like, do we not have enough of those?
And, you know, it is I think it is funny to see how we've, I guess,
come a long way in even more interop efforts all across.
And I think I tweeted something online two weeks ago where I was
like, I think we will see even more interop than we see today.
And I think, yeah, definitely happy to share a bit of context
of why we think that is the case.
But yeah, we originally started, and then we actually
still are primarily a message framework.
So the basic idea to allow smart contracts
to send messages around.
And I think that has always been around
by like the original roll up bridges,
like what Spencer's working on, on the Arbitrum stack
has very much been messages bridges.
But I think this idea is that like,
we just like way more chains, right?
Like with different kind of trust assumptions,
verification mechanisms.
And so this kind of concept of like having a framework
that can abstract these different things
has been pretty much our focus.
But one thing as we've kind of talked about
with various stakeholders and for us,
that's primarily like long tail chains, right?
Like chains that let's say use orbit stack
for like a caldera to kind of like deploy a new roll up.
Like I think what a lot of hackers are doing in a hackathon,
we realized that I think messaging really only
gets used so far.
And at some point, people are really
asking for a way to move liquidity.
And so you can obviously use lock-in and token bridges.
You can use the underlying roll-up bridge.
But I think in this more and more fragmented Ethereum roll-up
ecosystem, it becomes something that's very much a big user need
that especially these newer, longer tailed chains
are asking for.
And what we've noticed, basically,
honestly for a while, but especially last year,
is like, oh man, there's nothing that they can get
out of the box permissionlessly.
And so that's when we and Bootnode started working on,
kind of, I agree with you all, Kyle,
the open and tense framework to just give more tools
to these chains, to these developers,
to give them that part of experience,
which helps with like onboarding users
or like moving across these chains
and not having hopefully the experiences
that the one that you experienced
of like not being able to do it
just because the infrastructure is not there.
Yeah, totally, totally.
No, I think the developer experience
around all of this stuff is a really important topic of conversation that maybe the last couple of years has not gotten as much airtime, but I'm glad to see all of that changing, especially with all of the work that everyone at least that I'm aware of, to really build around Intents.
Can you just give a brief overview of sort of how Crossworks, how it leverages Intents,
and then maybe if you also want to touch on some of the challenges from a developer perspective
that you've seen with it today? A hundred percent. So, you know, just as Nam explained,
it started off with, for us,
at a place where we realized the fragmentation
with Ethereum was becoming an issue,
not just for developers, but for users.
And overall, the ecosystem was not able to scale
and accrue liquidity across
when they were trying to go to other chains
and trying to access other protocols and projects.
So in this particular sense,
we set out to obviously build ERC7683 with Uniswap.
And we're trying to make sure that we are able to essentially provide a framework
in which outcome is the focus instead of the path of execution.
And the user does not have to think about planting the seeds of, okay,
my money will go through this point and then this point through this relay.
And all of that should be abstracted away in the network that is able to take care of
you in the most cost effective, the fastest and the most streamlined way.
So all these values aligned very nicely with the ecosystem and we were able to build across
like so.
Now, touching base on how developers have been feeling, how users have been feeling, the response in general has been extremely,
extremely good from what I can tell.
Developers love building on a cross.
We've got this cute little SDK that you can try out
that can give you three functions.
That's all you need to call.
And you've got a working bridge
that leverages the same infrastructure as a cross itself.
Yesterday only, I was talking to the espresso team and we figured out a way through which
Espresso rollups can get liquidity from whichever chain the user's liquidity is sitting on.
So that was a really big win for us and it was so nice to see that
it's so easy to figure out things with Intents itself because that particular solution
where Espresso rollups are getting liquidity from other chains using a cross didn't just use a cross,
it also used message passing with hyperlane.
So that was a huge, huge win that we realized
the whole ecosystem needs.
And we'll be working more and more
towards it throughout the duration of the hackathon.
So yeah, that's a very small history about a cross,
very small detail about what happens
when you want to execute things on chain, and finally what we did yesterday. about across very small detail about what happens
when you want to execute things on chain
and finally what we did yesterday.
Awesome, I love it.
Okay, so I suspect that we may have some folks tuning in
who are listening who are still like,
what the hell is an intent?
Like, what are we actually talking about here?
I even I was definitely in this category
going back a couple of years.
I remember listening to a full talk at modular summit two years ago about intense and it took
me a while to wrap my head around like what the jargon here is really referring to.
Spencer, can you maybe break it down in plain English and layman's terms of what we're talking
about when we talk about
intense or intense based bridging, however you want to come in at it.
Yeah, sure. So when I think of intent based bridging, I think of myself expressing a desire
to move a token from chain A to chain B, not caring about how it gets done as long as it gets done.
about how it gets done as long as it gets done and expressing that intent to move this token,
have someone like a cross come in, front the liquidity for that token, and get me to my
destination as quickly as possible. I knew you would crush that question, Spencer.
And that brings us, I think, a little bit, again,
higher level, but also creates a way
for us to go a little bit deeper into the architecture here.
So when we talk about someone like across coming in,
I think it's important to acknowledge
that there is a lot going on there under the surface.
So across, of course, is kind of the front end
and the shiny abstracted layer that we all
get to interact with as users.
I do so several times a day.
But there is, again, much more going on under the surface.
So people might have heard of solvers.
Kanishk, maybe I'll ask you, can you talk a little bit about what's going on under the
hood, what role solvers play?
Absolutely. I think this is a very good question. Can you talk a little bit about what's going on under the hood, what role solvers play?
Absolutely.
I think this is a very good question.
So thank you so much for asking this because when we talk about intents in general, solvers
take relayers, solvers, fillers, whatever you want to call it, take a lot of the risk
of the execution and take it away from the user.
So the focus here is that you as a user come onto the platform, you express an intent and
say, Hey, I have $10 on base.
I want to put these $10 over to Arbitrum because I want to do XYZ activity, whatever the end
use case is, as the user suggests.
So in this particular scenario, all you have to do is give that intent to a relay.
Now how do you do that?
Well, you use a cross, you can authorize the spokeful
contract to take the money from you. And then the relay essentially fills you the across
network, the across protocol that we've designed, then pays back the relay. So as you can tell,
the relay takes the risk of chain reorbs, the relay takes the risk of any kind of mishap
that can happen in this situation. While all the user has to do is come in and say,
hey, give me money on this chain. I'm giving you money on that chain. It is also the relayer's
responsibility in our particular system to make sure that it is very, very fast in doing
so so that the UX is maintained. This is a core focus that we've had throughout our
development cycle. And essentially this is what a relayer is. They take the user's request, they fill the user's request,
and then they wait to get repaid on chain.
I hope that was a succinct explanation.
But if anybody is more interested
and they want to dive deeper,
I'm sharing a link in our chat,
but we can probably pin it later.
Thank you so much.
No, perfect.
Hadrian, what would you add?
What is Open Zeppelin thinking about
in terms of what's going on under the hood behind a product like Acros?
Well, I mean, it's really interesting because I think all of the complexity and all of the interesting parts to me are the parts that the user don't see.
And that's, I think, the strengths of the intent system. The user asks for something, looks some fun on one side and asks for someone to fill the
request on the other chain. And at that point, and this can
happen super, super fast, because as can you say, like,
the solver is taking all the risk. So if the solver wants to
go super fast, doesn't even have to wait for finalization on
the source chain. And that's how you get your money almost instantly
wherever you want, provided there is a server that
has a liquidity, obviously.
But that's only when the interesting part starts,
in my opinion.
And that's the part I'm really interested in,
because at that point, the user goes away.
But that's really when the solver
needs to prove what happened on this destination chain.
And that involves proving state transition,
proving that whatever the user requested
happened the way the user requested it.
And that all went fine, and that you got finalization.
And then you prove that back to the store chain to get the fund.
And so there is a lot of mechanics
of moving pieces that happen that are hidden from the users.
That's really the part I want to focus on and that hopefully users will never see.
Yeah, no, spot on. Thank you. And I'll just take this as a moment to just explain very briefly what
Espresso does because you queued me up so perfectly. But exactly. So today solvers take on actually quite a bit of
risk that then does not get passed on to the end user. And for the most part, these systems
still work quite well today. It's kind of okay for solvers to take on a little bit of finality risk,
because very frequently they are taking that into account in their pricing and kind
of their business model. And they are also taking a look at, you know, who is sort of
making the promise to them before things get finalized. And maybe they have a very high
degree of trust in a roll up like base or Arbitrum. But as we scale to hundreds of chains,
I think that this is going to become more and more of a problem.
And so Espresso is a fast finality layer that is backed with economic security and as a BFT
consensus protocol that offers a much stronger confirmation to solvers so that they have to take
on less risk than what they do today. And so that's a little bit of how
all of our different projects, I think, start to fit together.
I think that one misconception that I see a lot
is the idea that, oh, there's all
of these different interop projects.
What are they all doing?
Why do we need all of these different projects competing
with each other?
But actually, for those of us on this call right now, like we're all building
different parts, I would say of the same singular end user product.
And that to me is one of the great pleasures of being able to work on interop.
Being able to work in this space, um, is that we get to be very collaborative
is that we get to be very collaborative across all of these different folks.
across all of these different folks.
I would love to hear, Josh, from you, a little bit of that work from your angle,
because you really, I think, are sitting at the hub of many, many different projects
with all of the work that you've done with the Open Intents framework.
Can you share a little bit of the motivations behind that,
how it's come about, the joys and the pitfalls of it,
wherever you want to go?
Sure, yeah.
No, it's been more joy than not.
Yeah, I've been really happy and energized
to see how much just sort of open collaboration, good faith
engagement by a very diverse set of groups
with divergent business interests
that are all coming together,
not in this sort of like ignoring reality
or ignoring business interests kind of way,
but because we're finding common ground
and we're finding where the incentives are aligned
and where we do need to collaborate
to get to the best solution and taking a very sort of pragmatic approach to this rather
than ignoring where those mismatches may be. So just one note that at least I think that's
how I try to approach it and I think everyone on this call approaches it with a sort of
pragmatic mindset and approaching it with that collaboration is great,
making big announcements are great,
but we do need to ship things as well.
And so finding that right balance with Interop,
it needs to be done collaboratively.
There's really no other way, at least when
it comes to sort of ecosystem-wide trust
minimized or trustless Interop. And when it comes to sort of ecosystem-wide trust minimized or trustless interrupt.
And when it comes to the Open Intents Framework,
more specifically, again, this is an effort that was underway
before I joined.
But I was very happy and excited to be able to play a role
and maybe just helping to accelerate things
or play the EF coordination kind of role.
So yeah, I guess I can say more specifically that for people that are not familiar with the Open Intense Framework and the OIF,
and maybe Nam can jump in as well here, but at a high level, again, it's about unifying the unification efforts and providing
intense and related infra as a public good. It's a little bit counterintuitive because I think,
again, generally when you think of standardization efforts and these large collaborative things,
you think it's going to move very slowly. the default is that maybe it's unlikely to ship anything, which I think is true and is a challenge for us as well. But again, when it comes to these sorts
of ecosystem-wide interrupt initiatives, I think it is the best way to approach these things.
And I'm very optimistic that the Open Intents Framework will allow us to
get to a better solution even quicker. That's the goal. The goal is to allow us to move faster than we otherwise would.
More specifically, to have a framework, like the name says, that allows for easy modular
deployment of this fast bridging intent-based infrastructure to all Ethereum chains.
So of course, the main chains that everyone knows about, but also the long tail
of chains that will continue to come online over the coming months and years. It needs to be easy,
seamless, quick, pain-free to get intent-based, fast bridging, other modular components of this.
This includes things like resource locks. This includes things just generally other components that will make solvers lives easier.
So it's more than just pure intents, but that's sort of the word that everybody knows.
And again, just making it sort of like modular, easy, and fast to get this sort of fast bridging infrastructure to all Ethereum chains.
Yeah, I love it, Josh. And I think it's a very optimistic view
of where we're going.
And I think that we need more of that in Ethereum land.
I don't know if you all are able to see my screen,
but I'm attempting to share this XKCD cartoon
that asks how do standards proliferate?
And you know, you start out with a situation, there's 14 competing standards, and then someone
comes along and says, this is ridiculous, there's 14 standards, we need to develop one universal
standard that covers everyone's needs. And then pretty soon the situation arises that, oh, great, now there are 15 competing standards.
Many of you have probably seen this.
I'm curious, Josh, maybe I'll call on you to start,
but please everyone jump in.
Just if you can talk through any of the pain points
that we have experienced along the way
of debates that have happened
and then how we've resolved that to align on
what's come out of the Open Intents framework because I think that as others at Espresso have
been deeply involved in this I have been kind of a mere bystander but I've been very impressed by
like you said Josh how actual progress and shipping shipping is coming out of the work that is voiding the XKCD cartoon
fate.
Yeah.
Yeah, I would say that that fate is not guaranteed
that we can avoid that fate.
But I'm hopeful that if we keep going on the trajectory
that we have been and keep being mindful that that is the fate
that we want to avoid, that we will have a decent chance here at least.
And it's a worthy effort in any case.
And yeah, I should give a shout out to the Espresso team in particular, Ellie from your
team and many others have been huge and sort of bringing the right energy, knowledge, expertise,
collaborative spirit, all of these things.
Yeah, to allow us to
keep moving things forward.
Everyone on this call, many others who are not on this call from other teams.
I guess the TLDR is that it's for sure a challenge when you're doing these sort of standardization
efforts.
Not that I've been involved in many prior to my time at the EF. But based on what we've seen so far,
I don't think anyone would be surprised
that there are disagreements along the way.
There are certain designs that certain teams will push,
because it makes sense for both their business objectives,
but also because oftentimes there
is no clear right answer here.
We're all trying to solve things that, in many ways,
I don't think have been solved before.
There's not a playbook that we can go to.
We don't want to reinvent the wheel.
And when we can look to existing things and existing processes,
I'm very much for that.
But I think, in a lot of ways, what we're trying to do here
is solve new problems.
And we have to solve them in new ways.
So yeah, there's no real easy solution.
Again, I think it's about just it goes back to communication,
which is hard for humans.
But the more that we can continue
to bring that sort of pragmatic mindset to the conversation,
then yeah, that's how I at least try to approach it.
And I don't have a better solution, I guess, at this point besides that.
Spencer, maybe you can hop in as someone who's building specifically in and around the Arbitrum ecosystem, I think primarily, you know, you guys have obviously developed around the intense framework as kind of your trying to build something perhaps a bit more
insular within your ecosystem. It's a little bit more siloed. Can you talk a little bit about
those considerations and the philosophy behind this for the Arbitrum community?
Yeah, so thinking about the OIF, we came out with our Universal Intent Engine before the OIF initiative started.
How these two things overlap is that we might use components in the OIF, we might contribute components to the OIF,
but all these standards floating around are just standards until someone uses them.
So we intend to lead the way. If no one else is going to look at the OIF and deploy things there.
We'll deploy our own opinionated version
through the Universal Intent Engine.
And hopefully, by being the first to actually take action,
it will catalyze other ecosystems actually setting up the same thing.
We looked at Interop, and there is an obvious decision there of,
do we optimize for Insular Interop,
like some other L2 stacks, or do we try to fix Ethereum first?
We prioritized fixing Ethereum first because if we can collaborate as Ethereum
and get Interop everywhere, that's a major win for ETH the product,
which is the whole reason we're here is for ETH the product.
So let's make that work.
Yeah, I love it. I think it's great.
Anything anyone else would add about sort of the journey along the way of aligning around a singular set of standards?
And the journey is obviously ongoing. We're not, you know, it's,
I like to say interop is full
because there is so much good stuff happening
that gets us very close to that.
I think once it's all implemented,
it's not actually fully solved yet.
Getting back to your original XKCD comics,
there are 14 centers.
I think we're not in this situation in particular
because usually when there are 14 standards. I think we're not in this situation in particular because
usually when there are 14 standards out there, it's often that 14 independent companies all came up
with their own standard and tried to take what they were doing and trying to force-feed that
onto the rest of the ecosystem. And I think here we're in a very different situation because
And I think here we're in a very different situation because the few companies that
are pioneering the internet systems are working along with the other actors that are trying
to do that now.
And they're all working together on making it standard.
I think everybody understands that there is a common benefit to having a standard here.
And it's not company fighting against each other.
It's a community building something together.
And that's why I think that this standard is more
likely to succeed than any other in that space.
Yeah, maybe I think to add what both Adrian and I think
Spencer said, I think really the rubber
meets the road for standard
when you can actually use it easily, right? Like when there's actually something to be done and not
just like a spec that like everybody loves to talk about. And I think the, yeah, I think the very
fortunate case like how you said is that like we're in some ways in the early phases of like building
out intent infrastructure. And so I think something like the OIF has a much better chance at succeeding
than maybe other parts of standardization
because there's a lot less entrenched interests, which
I think helps as well.
I think to the point of standardization in general,
I think we know that our industry is
heavily financialized.
And obviously, there's a lot of incentives going around which kind of makes standardization either easier or harder.
And I think one thing that I sometimes say is most disagreements in crypto are really just like a difference in time horizon.
And I think if your time horizon is sufficiently large, then I think you recognize that collaboration on infrastructure like something like the open intense framework or even like for other parts of the interop
stack are just like super necessary. And I think you can actually very easily tell, but
obviously everybody has their own incentive, but you can also very easily tell who kind
of like builds with a particular long range horizon in mind when just assessing like,
hey, how independently can this be used from
the party that is pushing for a particular standard?
I think it's one thing to say, yeah, my API, my standard is just independent.
You could use it.
Versus if that company vanishes, what would happen?
I think that's a pretty good litmus test for the most part.
Yeah.
Sorry. No, go ahead, Kanishk, please. I was saying that's such a good litmus test that
you just mentioned that if all of us stop existing for a second, of course not the EF, but then in
that particular scenario, what will happen to intents, right? Which is really nice to see because we've tried on our part to keep the ERC7683 as
modular as possible.
And we have this small demonstration
in our documentation where we show you
how this works in production.
And moving forward, it would be really nice
to see how teams can adapt them to their own chain standards,
their own implementations of whatever networks they are
building, especially
with the new ones coming in and see how Intents can sort of adapt and bring and drop there
as well from day one in case they don't have it in the stack.
But yeah, thank you so much for pointing out that business test.
I really like that.
Yeah, I was I was going to say the same thing.
I think that's spot on.
And if I can just sing the praises of Ethereum for a second, I'm very
bullish. But I think that this is exactly right. What Nam just said is that we are all
trying to build for a very, very long-term future. I know that there is almost kind of
a meme of like Ethereum is building to be World War III resistant. And I think that
that's right. And I think that that serves Ethereum and its developers
and the community around it really well in the long term,
even if it's painful in the short term
because we're not taking shortcuts.
I think that the whole roll up scaling roadmap
is an example of this, of trying to build
with the right architecture at the outset,
even if we're going through this kind of painful maturation
phase right now where we're dealing with fragmentation.
But again, fortunately, everyone is thinking very long term
and coming together to solve this.
I'd love to get into a little bit more of the nitty gritty,
so just talking through some of the existing
proposals and tools that exist for builders to start experimenting with intents today.
Spencer, maybe I'll kick it back to you to talk a little bit about the Arbitrum Universal Intents
engine to start us off. Yeah, so I think there's three components that are broadly agreed upon.
off? Yeah, so I think there's three components that are broadly agreed upon. One being a message
standard, something like 7683 out in the wild. You have this other notion of an escrow contract
or a resource lock. Uniswap's done a great job of publishing the spec for the compact. I think that's
a great starting point for anyone who's looking to build with Intents to satisfy one component of an entire engine.
The other part is something we call the cross-chain broadcaster.
There's a lot of options here.
You can go with RIP 7755, which uses storage proofs to pass messages.
We also have the cross-chain broadcaster, which is a little less general and focused
on like one smaller part of the message passing.
The cross-chain broadcaster spec is out there
and it's something that people can build
and it's a trustless way to pass messages
between any EVM chain.
And it's specifically designed to work
with any sort of L2 architecture.
So it has this idea of a pointer contract,
which allows the chain owner to actually specify
where certain things are stored.
It's obviously very slow,
but that's kind of the trade-off with trustlessness.
But there's definitely room, especially in this hackathon,
to speed up that process with
espresso pre-confirmations, or maybe you do something with a cross there. But if we have
these three components out in the wild and actually being built upon, I think we can see
some really interesting use cases for cross-chain token transfers, but also cross-chain smart
contract interactions. Yeah, hell yeah, really excited about it.
Adrian, do you want to jump in with any of the things that you're focused on cooking on maybe
a mention of how ERC 7786 will fit into this future?
Yes, sure. One second, my baby just came in. It's a bit noisy.
Oh, as a new mom, I can fully just came in and it's a bit noisy.
As a new mom, I can fully relate to this.
There's always some background.
So, 778.6 is an effort that we are actively working on at Topaz Appian that tries to standardize.
And again, we're in this issue of having 14 standards and building the 15 ones.
This is our real case here.
We are trying to standardize what
is much lower level what the users don't see, which is that this communication between between
crushing and obviously there are many ways to doing that. Storage proofs are one way and like
there are many providers out there. Hyperlane, XLR, Layer 0, Wormhole. I could name any number of them plus,
there are also all the L1 to L2 native bridges
that they're to provide.
All of them allow passing messages between chain
and all of them have different interfaces
and they're all in production right now.
So it's really a case of we have 14 different standards
out there that developers can build on top of and each one has their
advantages and their drawbacks and their limitation
but in the end we are in a fragmented space and if you wanted to be like a
universal intent system across all
blockchains, well at some point you need a universal resolution mechanism for the solvers and
and that's where our work is placed,
is basically we're trying to allow developing
any cross-chain application that can message
between any blockchain,
by having this universal standard
for cross-chain communication.
If we succeed, it will actually be a case
of removing 14 standards to just
have one.
I'm way less optimistic on CentOS 86 than on Intents themselves, but hopefully we get
there.
Yeah, awesome.
Nam, what about from your side?
What tools are you either working on already have out in the wild for builders or are feeling particularly optimistic about?
Yeah, like I think as you mentioned, we are one of the 14 in that sense.
Right. And actually, I would say the difference is a little bit maybe with some of those 14 is that we've recognized that like, hey, it makes no sense to build,
honestly from our perspective,
a verification mechanism because there's just going to be too many.
You just won't be able to compete when let's say,
OP brings out superchain interrupt to compete
between base and unit chain.
The best mechanism will always be the native interrupt.
I think what you have to build is basically
an abstraction
over all of these different verification mechanisms,
like whether that's storage crews or let's say CK-like clients.
I would say we have had three years
of that experience of trying to find the right abstraction,
trying to find the right developer tools over that.
That being said, I'm still very much in favor of trying to standardize something as a broader ecosystem
and have been very involved, I think, on that front with all these groups and hoping that whatever we put out there,
it's always best to just make things easier for developers.
And yeah, definitely happy to share with folks who are trying to standardize kind of like our lessons learned because we ultimately all benefit from just like
having better and more in a row out there. Yeah, totally. I love that as kind of the
abstraction layers helping to prevent this fate that we've now got up on the screen.
Because I think that you're right, this is something that I struggle with reasoning through
sometimes myself, is that, okay, yes, in each given cluster where you can have even more
overlapping standards and so forth, I think that that level of interop will at least in
the short term outcompete what we can get on an Ethereum wide
basis. But then exactly building for abstraction on top of that, I think is definitely one of the
ways to go to try to solve for this. But I think that there's this kind of interesting tension
between modularity, where everyone wants to have their own very customized stack.
And I think that there's a lot of good reasons for that and good reasons to have things be very modular
and have each stack be very customizable and expressive.
And then, again, ending up in the XKCB situation of having all of these different competing standards.
This is these are some slides from a talk I gave at Youth Denver.
Josh, this was one of the slides that I had of you
bringing together the Event Board crew
with many other logos, of course, that should be up here.
But maybe I'll just call on you to share a little bit
of what you're feeling optimistic about
in terms of the tools that
you're seeing out there for builders to use today, maybe from any of the projects that
are up here or just from the OI app initiative in general.
Yeah, I think the thing that makes me most bullish is seeing all of the tools that are coming online and seeing different and new functionality that it unlocks and seeing it actually being
able to get into the hands of users, which I think we often, at least I've been guilty
losing track of, is there a path to getting this into the hands of users, into the hands of developers?
And so I think the thing that makes me most optimistic
is seeing the tooling that has been being built for a while
now, but is actually getting into the hands of developers
and users.
I'm optimistic that the OIF will be a part of that as well,
of course.
But it's not the silver bullet.
It's not end game interop.
I think even the most bullish OIF person would acknowledge that,
that it's going to be a very valuable thing.
But it's not the silver bullet or end game interop.
So to me, we need it all.
And yeah, and we need to maintain that focus on actually getting this into the hands of developers and users.
Yeah, and that's a big part of I'll just chill it for just a second. That's a big part of the motivation behind what we're running right now with this hackathon, the building brew hackathon that has input from all of you guys on this call and many others as well, is trying to make this
a reality in the hands of developers and builders. And so, again, I hope that for those builders
who are tuned in here, you're getting a little bit of the history, a little bit of what maybe
is still yet to come, and just a lot more context about how this works under the hood.
So jumping into that, I want to talk for a second just about limitations and challenges that still exist.
I think that there is still a lot to be built in terms of solver infrastructure, in terms of the message
passing layers that support all of these intense based bridges and so forth.
I'll just share for a second because some people tuning in might be wondering what Espresso even is.
I'll just share for a second the way that I think about this and where Espresso is coming from.
We are very focused on making a better experience specifically for solvers. I sometimes talk
about us as actually being more like solver infrastructure than something for end users
to be able to have much stronger confirmations to rely upon. So maybe I'll try and share my
screen again here for a second. But if I think about cross-chain composability
across Ethereum today, it's like we have this amazing architecture of scaffolding that allows
me to do things like bridge from two different chains in one second on something like a cross,
but it's all hinging upon something that is still very centralized, which is generally
a pre-confirmation coming from a single sequencer.
And again, Espresso is really about creating better security and better guarantees around
that so that bridging can be done by these solvers in an even faster, even more efficient
way because they're taking on less risk
because they're using a BFT network
that has economic security behind it
instead of just the word of a centralized server.
And so if you're participating in the hackathon,
then that is kind of fundamentally what you are getting
as you integrate with Espresso.
I think that this is
a very important aspect of what the future of interop is going to look like, but of course I
do because that's what I'm building here at espresso. I'll share one more thing that I think is
a good kind of heuristic for how to think about this. So here we have someone having completed one second bridging
with a cross.
Again, this is something that I do almost every day
as I'm doing things on-chain.
It's an incredible experience for a very low fee.
But what's going on under the hood
is you have solvers sort of taking
on all of these risks of long L1 finality times
and centralized sequencers potentially rug pulling
or getting hacked.
And so that's a lot of what we think about at Espresso
is how to create better security
around the sequencing experience,
often called a fast finality layer.
But Kanishk, what do you think about
as you think about solver infrastructure and the current
challenges that still exist, what still needs to be improved?
I love the fact that we are discussing solvers today because while prepping for this particular
call I took some time and I went back to read all the collaterals that the world had given
And you're right, Solver infrastructure is the backbone
that is providing the speed and performance
you can do across today.
In this particular scenario, I think the biggest focus
is keeping the solver network sufficiently decentralized
so that no solver is able to take power
of the majority of the transactions
and essentially slide away all the other solvers
that are in the network.
There should always be enough competition
so that the user can get the best experience.
And at the same time,
there should always be enough competition
so that solvers have something to do all day
and they keep making their incentives.
Essentially, why does a person run a solver?
Why do they go through that whole drill?
Essentially to earn, right?
That is the end goal they have in their mind.
And in this particular sense,
we've seen several implementations of the solver itself.
Just yesterday, I was discussing with the team
where they were building an imitation
of our TypeScript solver in Rust.
Absolutely love that, support more of that,
need more of that.
But at the same time, these kinds of motivations
is what is leading the current community
to provide better UX to the users.
So to summarize all the yapping that I've done so far
is to just say that keeping the network decentralized
is the biggest focus.
Making sure the solvers have enough liquidity
and have guardrails so that when
they are taking the risk of L1 finality or when they're taking the risk of a reorg, how
do they make sure that they are safe to the highest amount of degree possible is a very,
very important discussion that needs to happen more often.
And yeah, that's majorly my focus right now with several of our teams as well as we are
pushing for more relays to come into the picture.
And if any dev wants to do that during the hackathon, hit us up.
It would be so cool to see you fight and build your own relays in your own
languages and get the, you know, get the community and the ecosystem moving forward.
But yeah, that's what I would feel.
Absolutely.
I love it.
Nam, go for it.
I was going to say, I think on solvers,
like I don't know, like Lefi had like last year,
always had a good post that basically said,
right, all the way down, it's just solvers all the way down.
And I think one thing that I feel like actually,
as across a solver marketplace has become very competitive,
which I think is great for across,
it's great for across as users.
I think we've kind of, I think sometimes forgot about that.
And like, as part of our exploration
and our work on the open intense framework,
like the whole goal was to give this to long tail chains,
right?
Like I think it's great for like OP and Arbitrum
to have across work really well.
There's a lot of volume,
there's like super tight spreads, which is great.
But like, if you launch like, right?
Like jailchain today,
you now have to basically do all of this infrastructure yourself.
I think honestly, it's just overwhelming.
Even for us as we've been working on
the OpenTest framework for a couple of months now,
we still have trouble of like,
hey, what is the actual experience for
a new chain to get that product experience?
I think it's one thing to talk about the infrastructure and the code,
and that's what we've mainly done so far in the open-end framework. But really, I think getting
like this kind of chicken and egg problem of like, hey, right, like on a long-tail chain,
there's basically a no-flow. So as a solver, like you're not going to invest infrastructure to do so.
And in reverse, like, right, like because there's no solver, no user will actually want to use this product.
And so I think, you know, like how do you get out of that chicken and egg problem is a very, very important question that I think it's just making it stupid easy to run a solver.
Like basically to allow a new chain that launches
to ideally run their own solver.
Because in reality, there might not be that much flow.
And there's maybe the rebalancing need
that you need today, like on Optimism Arbitrum,
because you move millions every hour.
It's going to be different than if, again, you're
launching a new roll-up.
And so I think solvers are gonna be super important.
And I certainly hope that we can continue
to basically make it easier to have more solvers
because it's not clear to me that a lot of the actors
that we see today solving, let's say,
on the big chains and across,
or even in a single chain context on things like CalSwap,
will have the inherent incentive to
basically run their infrastructure on a very long tail roller. Yeah, I'm taking notes here,
Nam, for when I launched Jillchain with confirmations by Espresso. I've got to be able
to run my own solver for it. Absolutely, unless I can hit up the good people at across Konnishk to take it on for me.
But no, I think that that's a really clear problem
space and a really clear vision that you just laid out
for what the future needs to look like as we
scale to hundreds, thousands of chains.
Eventually, I think everyone's got
to be able to spin up their own solver.
And for that to happen, we need all of the infrastructure
to be there to make it safe, fast for people
to solve across chains without taking on inordinate risk
and having to be too sophisticated.
And then also, of course, just the developer tools.
Maybe on this note, and as we start to wrap it up,
Spencer, Hadrian, and Josh, I'll call on each of you
to share what you'd like to see
built. Maybe it's in this hackathon, maybe it's in a developer initiative in the future, but what do
you think needs to happen in order to make going cross-chain a reality?
Yeah, so I think what I would like to see is some sped up version of the cross chain
broadcaster with cross chain broadcaster being, you know, like the source of truth, but sped
up a ton with this press at pre confirmations, seeing an implementation of that would be
awesome.
Also, like across said something about a like a solver built with Rust.
We have stylus on Arbitrum.
So if you want to build a Rust implementation of a solver
and get that set up on Arbitrum One,
that'll also be super cool.
Great ideas. Love it.
Hadrian, what's on your mind?
Well, so my mind is I'd love to see a resolution system
for the solver to gain back their front-end
on the residue chain that uses a variety of protocols,
maybe multiple protocols to have double confirmation,
or that uses 7.7.86 and no aggregators.
That would be fun.
Yeah, awesome. And I think we can put along the bottom here where people can learn more
about 7.7.86. I think that this is a really important thing for folks to be aware of as
they're building what the future might look like here for the interfaces for cross-chain
messaging. Josh, how about for yourself? What do you want to see happen?
Yeah, I don't know that I have anything, any great ideas other than what's already been said.
I would like to eventually see more exciting, fun applications that are sort of uniquely enabled by this infrastructure.
And so the more that we can actually get exciting things
that people want to use, exciting applications into people's hands. Yeah. I totally agree with
that. I think that sometimes I hear people say like, oh, like, this is all overrated. I mean,
specifically, a lot of people will talk about how synchronous composability so truly making all of
these different chains
work together like one chain, like, oh, that's overrated,
or even all of the focus on interop,
all of the money that's been poured
into interop projects, et cetera, oh, it's overrated.
But I think that that's a really short-term view.
I think that you never know what innovation
is going to come about from new capabilities being enabled.
And I do think that this is fundamentally a new set of capabilities to both have the scale
and customization that roll-ups give us on Ethereum and also get them seamlessly working together.
I do think that fundamentally new things are going to be built and come about.
And I think that it's just a lack of imaginations to say,
to say that this is overrated and not as important.
So yeah, I'm really excited to see of course,
what comes out of the hackathon here.
I think that this will probably be the first
of many hackathons, not just run by Espresso,
but run by this whole community around intents
that has a focus on getting more things built
cross-chain, whether it's solver infrastructure, whether it's new cross-chain applications,
whether it's new things around message passing, as Hadrian and Nam touched upon,
I think it's all going to be really important. We'll start to wrap it up here. I will let everyone go, but I've definitely learned a lot
from all of you guys over the course of this conversation, and maybe we'll just end with a
very quick round robin if everyone can share what they think the biggest outstanding challenge is, and that can be kind of a call to action.
So I'll begin. I think from my perspective, one of the biggest outstanding challenges is just making all of the risks that currently exist,
whether it's within a given roll up specifically, or as you move cross-chain, making all of those legible and educating users about
what risks maybe they're taking on or other parts of the infrastructure are taking on. I think that
we're fortunate to have been in an environment for the last few years where our systems have been
quite heartened and we haven't had a lot of major hacks or vulnerabilities, but it's just something
that I'm always thinking about is what's being hidden in the infrastructure and how can we
continue to make sure that things are actually decentralized as they say they are and as secure
as possible. I think L2B is a great example of a resource around this, and I'd love to see maybe a version of that
specifically for cross-chain.
But Hadrien, maybe I'll kick it to you.
What would be your call to action,
or what's something that's top of mind for you?
Well, there are two things that are a bit contradictory.
The first one is really focusing on the wallet
and the user experience.
I want people to sign intent in a way that they understand what's going to happen, and
that's going to be challenging, particularly for users of hardware wallets and so on.
So call to action could be ledgers, should jump on that and make sure that.
I'm saying ledger, but it's treasurer as well, like making sure that signing an intent is
something that is super user friendly.
So that's one side.
And my second one that is a bit contradictory is I'd like user to not see the intent at
all.
I'd like this to happen under the hood and solve their problem without them even noticing
it exists.
I love that.
I think that those are two sides to the same coin and both very important.
Josh, what about you?
Yeah, so maybe it's not quite a challenge, but one thing,
yeah, I would like to see is just, I guess what I'll say is just to make Ethereum
fun and experimental again. So I think the more that we can do that,
I'm bullish.
That is awesome.
Spencer, I feel like Arbitrum, the ecosystem is pretty fun.
So already on our way to solving what Josh's call to action was.
But what's on your mind?
Yeah, I think the biggest challenge
is going to be overcoming the narrative that
has been spread around, that there is no interrupt
and that it's forever ways away.
I've been able to go from any chain to any chain
in one to three seconds using relay or across
or D-bridge or jumper for a year.
This isn't like something alien or far off.
It's been live for a very long time.
So we need like public acknowledgement
from people that the experience is not that bad right now, but it's also going to get
miles better very soon.
Love it. Nam and Konish, you guys can take us out.
Yeah, I think, uh, I agree with what Spencer said. We just really have to keep going at what
we're already building. I think there's no precedent as far as I can tell for just how
much we're coming together to do this. I mean, I've only been around since 2018, 2019 or
something.
That's pretty OK.
But yeah, but I think just in those days, I think it was very much like, oh, there's all L1s and all this kind of stuff.
But like, when we are like, I think this kind of big of a group, right, like these many
diverse incentives, and we can come together, like, there's just like, it's pretty hard
to argue that there's no interrupt here.
But yeah, I think from a maybe more, you know, engineer-brained perspective, I certainly would
like people to kind of like remember
that one of the things that I think makes our industry,
I think really like the main thing
that makes our industry interesting
is the like permissionless angle
and the fact that like, right,
that you don't need to ask somebody for permission
to deploy an application or to use an application
and to kind of like, yeah, always be mindful of kind of like,
hey, what parts of the infrastructure that we're building here
kind of like do not embody that value
because that kind of like puts us on a possibly dangerous path
to just replicate and just like change the gatekeepers.
Yeah, we're not trying to replicate TradFi or Web2.
Kanishk, what about you?
What would you say?
Oh, wow, there is so much to say, but all I'll say
is that I'll build off of Nam's answer
and say that this is a permissionless ecosystem that
we're all in.
So for users, use the chain.
Go ahead.
Do activities.
Try out whatever protocols or platforms you want to use,
staking, DEXs, DPI, whatever you want to use.
And for developers, participate in the hackathon.
You've got a really cool SDK.
We've got really good partners.
We've got things happening.
And if a dev does not move now, this
is the early stage advantage era of intents.
Move now, build cool shit, and move forward from there.
So I hope that by the end of this particular hackathon,
which is ending, I think, on 31st of March,
we will see some really, really cool projects that will not
just win prizes, but also encourage discussion
in the field of interop towards what can be done more
to build better UX.
One thing that we personally saw was embedded cross-chain actions,
which is when you can pass a message along with the bridge transaction.
And when you bridge, you stake or you bridge, you deposit automatically.
Great UX improvement, and we would want to see more of those happening
towards the end of the next week.
So yeah, all the best, hackers, and keep using the chain users.
That's all I would say.
Awesome. Well, thank you guys so much for your time this morning or this afternoon, depending on
where you are. I think to me, again, this is the whole fun of building in Interop is that you get
to build with so many great people across the space. I was telling someone this morning like,
oh, I'm getting on a call with a bunch of colleagues. They were like, all these people are your colleagues?
We all do get to work together in the trenches,
even if we're representing different teams and
building different parts of the product stack,
we really are building one product.
If you want to learn more about the hackathon,
you can see the URL along the bottom here,
tinyurl.com slash build and brew.
Thank you again to all of you who are
great partners in bringing intents to the developer community.
Thank you to all of the developers who are actually out there building.
We'll have office hours every Friday.
I think that they're actually ongoing right now.
If you're a developer and you want to hop over to those,
you can check our Twitter.
And we'll have them next Friday as well,
as well as the community call for Espresso
to talk more about all of this and more next Thursday.
But thank you all so much for joining this morning.
And yeah, let's get back to work.
Let's make Ethereum fun again.
Thanks, again.
