See all Celestia transcripts on Twitterspaces

Silence.

Hey, Uma.

Hello.

Thanks for joining, we'll wait for the others.

Yeah, sounds good.

Cool to see some familiar folks here. David, Alex. Hey, Nick.

Hey, what's up, guys?

We'll wait for Chris and Zachy. Cool to see C-Node in here. We have John. Hey, Chris, thanks for joining.

Thanks for organizing.

We'll just wait for Zachy.

I think we need some kind of like elevator music just to fill the space.

This is more 8-bit than any elevator I've ever been in. Sadly. I mean, that's great.

Wait, does it come with... Is that like programmed into spaces? Like, can you just do that automatically?

Yeah, you can. I didn't know you were actually making

that up there.

But I...

No, no, no, no. I mean, I actually think it'd be great. I just like that. That song. That's all.

Hey, so Zacky just messaged. He's going to be on momentarily.

Okay, great. Do they have any other samples? Maybe we can find a tune that really fits the intense topic of the day.

Yeah, let me try.

Uma, how are you doing?

I'm good. Chill afternoon.

Come on, Zaki. Come on, Zaki.

Uma, you're coming to module summit, right?

Yes.

Nice. Were you there last year?

I was not. I'm excited to see it.

Same.

Henry, welcome. We should maybe let Henry cameo. I feel like there is some overlap with the stuff that Penumbra is doing. So I hope Henry sticks around. Should we just start without Zachy?

Like, do you think he's going to be here soon?

Yeah, let's, like I invited Henry in here. Why don't we just get started? I'll plug in Zachy when I see him.

Hey Henry, how's it going?

Good. Sorry, I don't mean to crash. I just was looking to follow along, but you know, great to be hanging around.

You picked the right thing to crash. Okay, yeah, let's just get started. Oh, there's Zaki. Okay, great. All right, I'm gonna kick things off.

So everyone's talking about Intents, but I think there's still a bit of an information gap. You know, it's like the early stages of people figuring out and understanding what they are. And, you know, the 3 speakers that we invited today all gave talks at Research Day in May. And if you haven't watched those talks, I really encourage you to do so. And I think, I don't know if they coordinated this or not, but I would say that they successfully nerd sniped everyone that was at the conference on Intents.

And something that was kind of something that people were already talking about became really the topic of the hour. And so I'm really excited to have these 3 speakers on with us today, because they each have a really good view. And luckily, we also have Henry from the number who, I guess, just joined. And hopefully, we can include him in parts of this conversation. I first encountered the idea of intense when I picked up a copy of the Noma white paper at Cosmoverse last year.

And I read it on the flight home, or rather I tried to read it. And I remember the idea of intense stuck out to me as something that was very novel and made a lot of sense, but I only understood it at the surface level. And then when I tried to go deeper, I got completely lost. And so I've been learning a little bit more about intense over the coming, over the last few weeks and months, as I think everyone else who's probably on this Twitter space have been as well. But I think the goal of today's Twitter space is to answer the question, you know, WTF are Intents And like, why do they matter?

Like, what do people need to know about them, especially all the builders in the audience? And so, yeah, I couldn't think of a better guest to have on to answer this. So why don't we go ahead and do a round of introductions from each of you, and then we can dive into the meat of this conversation.

Cool. I can go.

Don't be shy.

Zucky, longtime cosmonaut, longtime blockchain builder, co-founder of Sommelier, yeah, 1 of the people. I gave a nice like 10 minute intense talk at Research Day which I think is fairly digestible. Like what the fuck are intense talk.

Yeah I can go next. I'm Uma. I'm 1 of the co-founders of Sucinct. We're a company focused on more secure and more general interoperability. And I also gave a talk at Research Day talking about cross-chain interop, bridging, and Intents and how it all comes together.

And Zaki was actually 1 of the big original inspirations for my even starting thinking about Intents.

Aw, that's really sweet. I didn't know that. Yeah, it

was all from your group chat, telegram messages about Intents and being excited. And I was like, oh yeah, I should look into this.

And then we have the OG nerd sniper of all, Chris.

Well, that is a title I do not deserve. I credit myself only with abstract philosophical nonsense. And then later on, other people assign coherent meanings, and I just get to claim that I was right all along. It's very convenient. Yeah, I'm Christopher.

I've worked previously on Ivc for the Cosmos project, and I now work on Anoma, which does use the word intent, although I guess I'd like to like, you know, we in no way aim to assert a monopoly over that word. You know, we've been using it for a while because it's a helpful design concept for us, But I think 1 reason the intent meme is so popular is that it ends up being kind of a way to describe commonalities between a lot of these systems and what they're trying to do in perhaps different specific ways. So, you know, we just want to contribute to that discourse.

Amazing. Okay, so let's jump in. I want to start with the most basic, basic question, which is what are intents? What would a good definition of intents be? And what problem do they solve?

I'll take a shot. So my, my, okay, so I like to start with what problem they solve rather than what they are. Because I feel like the best, like that's the clearest explanation of what an intent is. It's like, why would you need this? Like, hey, you know, millions of people are like sitting there with their Meta masks, clicking through transactions happily and like using blockchains.

And it's great. You know, when I like when we, you know, 3, 4 years ago is like there were like hundreds of people using blockchains and now there's millions. That does seem like progress. But like a lot of this to me came from, so Similia is this sort of app that's designed, is this framework or protocol or application for making DeFi easier to use, especially like complex DeFi things like providing liquidity on the decks, running like a leverage strategy, that kind of stuff. We try to make these more accessible.

And I think we've like succeeded assuming someone can actually get into 1 of our smart contracts. And that seems to be like the hardest usability barrier that we encountered as we were building Sommelier. Is it's, you know, you start out with a user and the user's like, I have some coins somewhere. They're like, I have a coin on a centralized exchange. I have a coin on an L, on EthL1.

I have a coin on, I have some coins on L2s. I have a coin on, I have atoms. I have USDC on any number of chains. The answer to the question is like, okay, cool, I have these things and they're like, I want to use your app, I want to get the benefits of having my money in real yield ETH. You know turning ETH into more ETH.

But like people are like how do I do this. All right. Now depending on where you are you might have to like send your money to like a wallet on chain. You got to send it to the right chain. You got to have the right type of coins.

You might have to use a DEX or a centralized exchange to swap this. You might have to bridge your coins between chains, you have to use the right bridge to end up with the right asset, you might have to use IBC inside of Cosmos, like any of these, you have all these different answers. And Basically, there's been a bunch of problems with that. 1 is just like how do I navigate? It's amazing to me that anyone successfully does this.

I was helping last night someone from the ETH community who wanted to buy a bad kid on Twitter. He was like, how do I buy a bad kid? He's like, this is the hardest problem with computer science. And I showed him some apps and stuff like that. But he just wanted to buy a bad kid.

And he had ETH. And he was like, how do I do this? And it was a totally unsatisfactory answer. We have meme coins where large numbers of people come on. They hear about some meme coin.

They want to buy it. It's only available on decentralized exchange. And like they get they lose money to MEV bots, they have to know about gas. It's like, you know, this is to me like, oh, like we built all of this amazing infrastructure, but like this is the usability story that we presented people with, and it's like clearly a fail. So, okay, Zucky, this is the problem.

The problem is we don't have good enough UIs, we don't have good enough UI frameworks, I mean, we don't have enough services. We have all these missing pieces. And so we tried to build that for Sibelia. We tried to build routers to route people into our contracts. We spent lots of money on this.

They kept losing money on slippage. It was like it's been a never ending nightmare. There are certainly better routing frameworks from teams like Enso coming out. But like it's still it's pretty difficult. And then like when you add the cross chain piece to this, it becomes like an unsolvable nightmare.

OK, so that's the problem statement. The problem statement is, all right, we built all these amazing blockchains. You know, they're scalable, they're fast, they can handle large transaction volume, but no 1 could use them. How do we solve this? And the idea is that we could build infrastructure where people could say, I am willing to trade X for Y.

I have some USDC and I want to buy Pepe, and I'm willing to trade it for at least, I want a minimum of this much Pepe for my USDC, they would be able to sign a statement and then if and some off-chain actor figures out how to get Pepe into their account, provides a proof like over a bridging protocol, you know something that is identifying your knowledge proof, something like that that is available with smart contract. Smart contract says, yep, as promised, you provided this much pepe, you can claim the user's USDC. And the idea is the user doesn't need to know about gas. And then we can construct these things correctly. Maybe the user gets a refund for some of the MEV that they created.

That's what kind of a simplified description in my mind of what intents are.

Was that financial advice, by the way, buying Pepe?

No, I have no idea about what meme coin. I am bad at trading meme coins I don't know how. I do believe that that is a legitimate use case for a blockchain I do believe that that like I think we should like meet our users where they are. And if our users cannot buy their Pepe and that's what they want, we have failed them.

Absolutely. Okay, so it sounds like that's a really good motivation for Intents. It sounds like you see it as a way to solve a lot of user experience problems that like coming from a completely different angle than the traditional approach, which is like, you know, we need to build better wallets, etc. It's like, well, actually, just build a system where the users actually don't interact that much with the guts of blockchains. And someone else does it on their behalf.

Wait, part of the

problem is that that's the same.

Just to like quickly say this is it's like I get, I become frustrated with the idea that ultimately you're describing a wallet that basically knows everything that a market maker knows. It knows about tracking prices, it's tracking gas, it's tracking arbitrage opportunities, it knows fair prices for things. And I'm skeptical of anyone's actual ability to build that.

Okay, so Henry, you sound like you want to say something, but I guess I was gonna move.

I was just gonna jump in and say like, there's sort of your comment, I think draws to this question of like, okay, what is a wallet, right? And 1 of the things that I think is kind of interesting to do in this ecosystem is like, imagine you're like looking at it, and you just kind of like defocus your eyes. And like, let things like blur a little bit and see like, what are the areas where things blur into other things? And how could the boundary like, there are all these, if you take any component of the system and zoom in on it, there's going to be a bunch of complexity there. And if you like zoom in, you can say, oh, it has the XYZ internal parts, right?

But it's an interesting exercise to kind of like, let your vision blur, like lose sight of what are the boundaries between these different things and how could those boundaries be possibly reconstituted? Right? Like what, what is a wallet even? And could it be that if you build this whole kind of like intense settlement like system, where, oh, well, it turns out that means you're effectively like building in like the capabilities of a market maker, maybe that actually just is sort of a part of this like bigger like wallet assemblage.

Interesting. I mean it sounds like the I mean it's the common through line there is that we need to kind of like, take a step back and re-evaluate some of like the base assumptions of like how we want to build blockchains and like what the different components do and should be responsible for. I want to ask, I want to turn over to Chris and Uma to also take a stab at describing what are intents and why they matter.

Yeah, I can also take a shot at it I think Zaki motivated the reasoning for him getting into thinking about this really well And I also had a really similar experience. So it's a saying we're trying to do like interoperate better more secure interoperability And we are fundamentally right now building this like really secure messaging protocol. And for myself to operate our protocol, we need to like run relayers across a bunch of different chains. And I would say as like a fairly sophisticated user, I would dread managing all my balances across all these different rollups. And that was me as a fairly sophisticated user.

There's all these problems around which bridge should I use, which is the fastest, like where do I go for each different chain. And then I think moving towards this app chain world or app roll up world, the problems get so much worse because it's unrealistic to expect any 1 company to maintain all these integrations. So say you have a bridge aggregator coming out. Well, how are they going to maintain this really long tail of integrations. And it feels like fundamentally something's something's broken here.

I think in terms of defining or starting to define what is an intent, I think we've talked a lot about the problem. And I think the fundamental problem is today transactions are very declarative. So if you think about something like, I want to buy a particular coin on Uniswap for this price that's saying, I'm going to specify the venue at which I trade, I'm going to specify which chain I traded on, and I'm going to specify like my other parameters. And in this like very multi-domain world, say you're trying to get like the best execution price across a variety of venues. As a user, Like you shouldn't need to specify like, oh, I want to do this much of a trade on this roll up and this much of the trade on this other roll up because the liquidity is like better for these reasons.

And so I think an intent is where a transaction is like declarative and specifying like all this stuff like what then you want to do stuff on how much you exactly want to do. An intent is like saying, you're specifying what you want your outcome to be. So basically, like, I have some coins now. And I want these other coins, like I want my Pepe coin. And someone else basically figures out the best venues, the best execution, the timing, wherever that is.

And then they do all that stuff for you. They're a sophisticated actor and then they help fulfill your intent. So I think going towards a definition that's, I guess, not very mathematically precise, but more philosophical is transactions are declarative and the onus is really on the user, whereas intents are users expressing what they want the end state to be, and then other people figure out how to get there.

It's interesting that I feel it sounds like a lot of the people who are most bullish on on tense or have encountered them are the people who worked most closely with cross-chain systems. And like, we can talk about that more later on. But it's interesting to notice that pattern, you know, I feel like maybe people who only, you know, live on 1 chain don't, don't experience these pain points quite as acutely. Chris, do you want to take a stab at defining intense?

Yeah. So, you know, I think Zaki and Uma did a great job going over sort of the practical UX reasons why you might want to think about system design this way. And I am a big fan of what Henry mentioned, you know, zooming out and blurring your eyes, or so to speak. So to do a little bit of that, I mean, personally, I guess I came at the concept of intense originally, from just thinking about what coordination systems do and the, you know, the like OG coordination system that we all exist under the aegis of is natural language, right? And if you think about like, in the Enoma, 1 of the Enoma papers, which contains lots of mistakes, please don't treat taken as canon, but I think we use the example of hunters trying to encircle a deal a deer, which is maybe not something many of us do in this conversation, not vegetarian, but like in principle, If you are trying to encircle a deer with other hunters, what you need to communicate with them in order to coordinate your action is a bunch of preferences and plans, right?

You need to communicate all of these internal states that aren't visible in the external world which you all observe. So you're communicating something about internal states and in particular you're communicating what you want and kind of what you are able to or plan to do. So that you want to like kill this deer or this other deer and that you're able to shoot this arrow or you know move in this direction, your current position is X, right? Stuff like this. So typically those in just English, as far as I know, would be referred to as intentions or something like this or a shortened version of intents.

And So that is how I got the word, at least personally when I was writing with it. You know, I think different, the intense can seem probably nebulous and abstract and maybe even like marketing. And I'm sure that sometimes it is that, as all words are. But to me, to kind of generalize over what people seem to be using the term to refer to, I would say intense or credible commitments to preferences over the state space of a system. And there are different systems with different state spaces, right?

So like Ethereum or Ethereum plus some roll-ups or, you know, Celestro or some Cosmos chains, you can kind of define the boundaries of the system in different ways. And then to say, to view that system from an Intents-centric perspective is to say that, okay, Intents defines some preferences a user has over the state space of future possible executions of a system. And then what we want to do in matching intents and settling is to find ways that we can satisfy multiple users' preferences that also satisfy the constraints of the system itself, that the signatures are checked or the linearity we want to be enforced is enforced, and then settle those appropriately such that we can make a credible promise that the user's preferences are respected, right? That if they said X and Y and Z in an intent, that the system actually does X and Y and Z or it does something that satisfies the preferences they've described or nothing. Right.

So we want this kind of correct atomicity guarantee. And I mean here not atomic in the sense of like atomic multi-blockchain or something that is related, but a distinct concept, just atomic in the sense of either the intent is settled and the user's express preferences are respected or it's not. And you can, Enoma, I guess, takes a view of this definition that also includes privacy. So our definition of intent is something like commitment to credible commitment to preferences over the, you know, also over the state space of the system, but where the state space of the system here is kind of redefined to include who knows what, right. So it's almost a commitment to information, future information flows in the system.

And that's, I guess we're kind of going after the general definition because we think that's an interesting question, but I don't think it's, you know, that's not the end all be all. I think that the concept of intent is useful because it allows you to describe the relation between the user of the system and the system itself very well, in that the user can say what they care about specifically, as opposed, you know, they care about things that they can measure and the intent can express the measurements, the outputs they care about in the system. And they might not care about a lot of details of execution, or they might care about kind of, you know, properties of those execution traces, but not the exact traits, right? You know, in a system like, oh, I don't want to front-run Henry, but as far as I understand, in a system like Penumbra, users might care about something like the fairness that all intents settled within 1 batch, however that's defined, gets like the same price, and the price is calculated fairly as the midpoint, something like this. So that's an example of a property of an execution path, but not an exact 1.

I think that would be my definition.

I like that. Credible commitments of preferences over the state space of a system. I think I got that right. I think that's a really, that sounds like a very, I don't know, complete and like specific definition. Now that we have that sort of the ground, you know, ground kind of covered the background established, I want to ask something that I think a lot of people have been wondering, and I've noticed people bring up a lot in the Twitter sort of discourse, which is, what is the difference between intents and things like account abstraction that, you know, a lot of people have been talking about for a while or things like pay masters, like, or also some people say, Oh, well, you know, limit orders are just intense.

Like, why do we need this new term? Like, how are intents different to some of the things that like already exist or people have been talking about?

I think I spoke a lot about this in my research day talk about how account abstraction and intents are related. So I think account abstraction basically is this way or it's this protocol And it can help enforce like very specific intents. So like take a really concrete example of I want a rate limit on a smart contract wallet. Like for example I only want a thousand dollars per month to leave my account. That's like an intent right.

It's not a declarative transaction. You're enforcing some preference over the state space to go back to Chris's terminology. You're saying like, oh, any state space, which like at the end of the month has more than a thousand dollars living in my account is like not acceptable to me. And then the smart contract wallet has like logic in it to enforce that intent. So I think account abstraction is just a spec for a smart contract wallet.

And in particular, like, it can enforce very specific intents that relate to the state of your account. So it can enforce a rate limit, or things like social recovery. And then it has this concept of a paymaster to help deal with intents around gas. So, hey, say you have an intention that's like, I wanna pay for gas in USDC, and I wanna reimburse someone else for gas. Well, you can enforce that in this way with like the account abstraction spec.

But fundamentally, I think account abstraction is a spec and it's a protocol in service of very specific intents. And so it's pretty limited. And for anyone who's looked at ERC 4337, I think the spec is very long and winding and complicated because basically, I think the creators took, let's say, 5 common user intentions that they want to enforce, like rate limits, social recovery, gas abstraction. And then they stuffed it into this protocol. And then they for each part of the protocol, like the paymaster or the smart contract wallet validation, enforces each of those intents specifically.

And it's not like a very general system, like it's kind of brittle. And I think if you look at all the account abstraction diagrams, it's really complicated because they kind of worked backwards from, hey, I want to enforce these very specific intents. How can I make the protocol do what I want to do in a way that's compatible with like Ethereum? So I think in that way, it's kind of ugly and like not general enough. And for example, an account abstraction, it does not help you solve the problem of, OK, I have ETH on Ethereum and I want to get the best price as much Pepe as possible trading across a variety of venues and across a variety of L2s, rollups, app chains, whatever.

I think like the biggest problem with account abstraction is that it's a single domain protocol. And I think a lot of what intents solve is actually like dealing with multi-domain stuff. So I think account abstraction, TLDR is like an intent specific app is what I called it in the talk. And I think it just doesn't solve a lot of the problems with multi-domain that I do think intents do solve because account abstraction was designed in this very single domain way. So I think intents are a very useful abstraction and even more useful in the cross-domain world in a way that account abstraction is like, I think, very fundamentally flawed.

So yeah, it kind of traction is sort of like a, a limited, like subset of, like, intense intense is like a much more general, wider concept that can encompass a lot more user experiences and is like inherently like cross domain rather than single domain. That makes a lot of sense. Anyone else have any takes on this question?

Eli Krenske made a really good point to me, which was 1 thing that it might be very familiar to like, at least DeFi savvy users is like the concept of liquidation, right? Liquidation, right? And so a liquidation is basically like you, you know, when you have like say, like a vault on maker, right? And you're like, hey, I've locked up some ETH, I've been some die. Basically, you bind that vault to an intent that says that if the price of ETH falls below a certain place, you have the right, someone has the right to take the ETH out of my vault and sell it for DAI to pay back the debt.

And like what I think has gotten people excited about Intents is that we've been like, you know, from like seeing, you know, billions and billions of dollars of liquidations happened in DeFi successfully to you know, seeing these like off-chain actors that are in the account abstraction spec to seeing like how much stuff is happening in the MEV space with like actors like inferring intents from users' transactions and then acting on them and bundling them and extracting MEV from them and all this stuff. There is this whole rich ecosystem of off-chain actors and the question is can we align those off-chain actors with like users' goals, such that like, we can make the entire blockchain UX, you know, a hundred X better.

I like that. Yeah, And in fact, I kind of like did an overheard tweet. Basically, there was like something that you had said, which is that intents turn toxic order flow into like non toxic order flow and they turn bad cross-chain UX into like good cross-chain UX. So I think that all really checks out. Henry, you were raising your hand.

Did you want to jump in?

Yeah, just to add on to something that was saying about, and also you mentioned about sort of in a cross chain world, the problem appears more naturally. 1 thing I would say about that is I think The reason is that if you're in a kind of like mono chain paradigm, fundamentally, the idea is, okay, my transaction is going to specify, here is the execution that I want to happen. And I know that that is going to all get executed at once. And what order it gets executed in, okay, people can, you know, mess around and play games with me. But like within that execution, I'm specifying that very directly.

And in a cross-chain context, you suddenly have all kinds of asynchronous execution, where some stuff has to happen in this part of the system, some stuff has to happen in that part of the system, maybe those different parts or different chains that are communicating asynchronously, and so you don't get the same kind of either this entire transaction succeeded or failed and I like locked the entire world to make it happen and so the reason that this sort of like intense predicates solution kind of naturally appears in that context, is that that's the way that you kind of recover from the introduction of asynchrony.

Yeah, the intense is sort of a way to, you don't, when you don't have atomicity, maybe there's a way, there's still a way to sort of like guarantee that what you wanted to happen does end up happening even across all these domains. Is that kind of what you're saying?

Yeah, like, you know, taking... Suppose I'm executing a transaction on Ethereum, right? In some sense, I'm like buying too much. I'm like paying through gas to stop the entire world and everything has to stop. Hold on, I'm doing something.

Pay everybody else to not do anything so that I can get the property that I want out of my transaction, but I'm, I'm, I'm paying for way too much synchronization there. I don't actually care about like, did somebody like mint an Ape NFT at the same time that I did my swap? No. But because there's no way for me to express any kind of criteria about what executions are acceptable, as a user in that type of monolithic system, the only way for me to get predicates that I desire is to pay everybody else to stop the world.

Yeah, I like that. Maybe when you frame it that way, it makes it sound just like kind of crazy that that's how things currently work. I haven't. The next question is for Chris, which is now we have an idea of like, how intense, what they are, how they're different to other things that exist. Now, like, what do we have to change in the way that we build blockchains or build the systems around blockchains to make this possible.

And I know you and I know I've been working on this for years now. So I'm really curious, what how you see that and like, what what are the pieces that are missing? What needs to change? How deep does this change need to go to really go all the way to like the very core of like, you know, how these systems work? Or is it something that just kind of add on to the surface?

Right, it's a good question. I mean, I think 1 interesting aspect of the way the intents are playing out, at least at the moment, is it seems like they're kind of, at least this frame is kind of inevitable, that even if you start out, you know, Ethereum for example was originally designed under the banner of a world computer. And I think that it's easy to actually kind of underestimate the importance of that concept. Like I think that concept framed a lot of things that happened in Ethereum, and a lot of where it draws inspiration from, in terms of building a Von Neumann virtual machine, how it thinks about politics, in terms of building a single central... Not that everyone thinks this way, necessarily.

I just mean in broad strokes. But in terms of building a kind of a single group of trust and then a hierarchy of different trust domains, which all kind of settled to the root. I think that concept was very relevant to how the structure of that ecosystem and protocol ended up evolving over time. But despite that, it seems like an intense system is coming to exist on top of Ethereum or in the Ethereum ecosystem more broadly. So I think that to some extent, you know, this is perhaps dictated by you know, protocol, political economics or something like this, like people are always going to use these systems when they have preferences.

That's just what the value of coordination is in the first place. If you didn't need to agree with other users on settling your preferences together, you don't need a coordination system like a blockchain. So I think that the kind of economic structure of it is a little bit inevitable, but there can be many different, that still what actually happens and what order is pretty path dependent. In 1, for us, it's very important that like we end up with an intent implementation, as in we broadly, you know, humanity ends up with access to an intent implementation that is compatible with privacy, or that doesn't require that information is always revealed to the world, let's put it that way. And many of the current intent and limitations just don't have this property, which is totally understandable because privacy is hard, and it wasn't perhaps so clear initially that it would be such a key problem.

But I think that it's essential if we want the system to actually work. And depending on how you define intent, it actually becomes part of the definition. But so to my mind, that's kind of 1 thing that the current systems typically don't have. Of course, you know, something like Penumbra coming soon is an exception to this. Even something like, you can think of something like Zcash as like an extremely, extremely specific implementation where the intents are only, I want this other person to have more money in their account, right?

Transactions are intense. They're just intense that have like an exact constraint on the path. So I would say privacy is 1 thing that has to change. To give a, you know, I think many things like that exist in the world, like the EVM, are kind of actually orthogonal to intent-centric architecture designs, as far as I understand them. Like they're not correct or bad, they're just sort of specific implementation choices.

Like they're equivalent to CPUs, right? So you might have different programs, and those programs are written for some, you know, in some typically more abstract language that provides or promises higher level properties, and then you compile them down to specific sets of CPU instructions. And those are physical systems, they have some like, you know, very specific physical tradeoffs and costs and stuff. And I would see something like the EVM as kind of like a CPU. It's virtualized, but it plays the same, it has the same relation to an intent architecture as something like a Haskell program does to an x86 chip.

You could also make another CPU and it would execute some programs faster or slower or something like this, but it doesn't change what the programs mean and it doesn't change what has to be done in order to execute them correctly. As in, you could take a program and execute, write a compiler for a different CPU, and then it might be faster or slower, but it would still be the same program. So I think a lot of stuff is kind of like that. 1 area might be supplanted by things that are slightly faster, but isn't really sufficiently compatible that it will work at least for a while. And maybe the optimizations aren't necessarily important for everything.

Although I think for privacy, that sounds to me, yeah, not easy to make privacy VPN compatible. But the other just to highlight 1 other area that I think needs to change a lot is peer-to-peer network designs. If you look, kind of zoom out, at least this is my impression, if you zoom out of where different parts of the blockchain research literature are in relation to kind of where they need to be. I think the thing that is furthest behind is peer-to-peer network designs. You know, cryptography is pretty clear how to do general purpose programmable privacy.

It's pretty clear how to do distributed consensus, distributed systems. It's pretty clear how to do, you know, distributed database optimization, special case roles and stuff, roll up architecture and different kinds of modular scaling. And I think peer-to-peer networks have just been kind of forgotten. And Unfortunately, the state of designs is not very good when you want to think about a heterogeneous security kind of privacy preserving intent-centric world. In particular, there's this sort of dichotomous framing in the literature between structured and unstructured networks.

So structured networks are ones where you have some specific idea of which nodes are connecting to which other nodes. And unstructured networks are ones where all the connections are random, right? Like a DHT is typically an unstructured network. And Ethereum, for example, the Ethereum peer-to-peer layer, the Tenement peer-to-peer layer, basically all blockchain peer-to-peer layers in existence, as far as I know, are unstructured and assume that all nodes receive all messages. And this doesn't make sense in a heterogeneous security intent-centric world, or even just across domain worlds.

You don't want all nodes to receive all messages. You want some nodes to receive some messages, and you want them to kind of discover network topologies over time, but also maintain, as discover optimized topologies over time, but also maintain as discover optimized topologies over time, but also maintain some resiliency. So you kind of need to exist, you know, as far as as far as we think, at least you need to exist in between these structured and unstructured designs. And there just is no research precedent for this that we have found it needs to be kind of designed from scratch. That's more of a cybernetic networking approach, I guess.

I found this old thing called the recursive internet network architecture. That was someone's alternative proposal for TCP IP and it seems kind of related, but that's the only thing I found. So I think that's 1 area to maybe give some more attention to.

Well, there's a lot to unpack there, but I know that, and we should definitely talk more about privacy too, especially since Henry's here, but I see Zaki and Uma raising their hands. So either 1 of you, feel free to jump in.

Yeah, Chris, it's really interesting that you think the P2P layer needs the most work. So I guess 1 question for you, just thinking through this is, do you think a design or the proposal kind of, or discussion for a suave like structure where it seems like the design is that you have 1 network that is surfacing kind of all these preferences and intents for all these different domains. Do you think that's kind of untenable? And is the concern there that basically, like the amount of volume and throughput that would be required for 1 network to process like all of the intents across all domains is just not possible? Or yeah, I'm curious how you, given what you said about the network topology not yet, be needing to be different, what do you think of like suave?

Right. I mean, to, I guess, caveat this, I am not an expert on suave and I get somewhat different impressions sometimes when I talk to different people, so perhaps the version that I understand is not the 1 true suave. I mean, I think if Suave is kind of 1 specific place, 1 location, perhaps operated in a decentralized fashion, but 1 logically centralized location where all intents get matched and then they go elsewhere for settlement, yes, I think that design is untenable. Or that topology, rather, is untenable. I mean, I think because, you know, kind of to Henry's point, because you're paying for this, all this, like, in some sense, you're paying for this central logical centralization that you don't actually need, because many intents just have nothing to do with 1 another, right?

Many intents are dealing with completely, you know, they're dealing with different security domains, they're dealing with different parts of state, they're dealing with different capabilities, different users, you know, they just don't need to ever interact with each other, like in principle. And if you make them interact with each other by trying to have 1 central location, then you're just paying for all this like, you're paying for the intents to be broadcast to all of all your intents to be broadcast to all of the swab validators or something like this, and you're going to be limited by the throughput of that system. And there's going to be 1 like central target, even if it's operated in a decentralized way for for, you know, someone trying looking to co-opt the system to go after. Also, it just seems like, if you think about the practical implications, it just seems weird to me. Like, if you are settling intents in some specific area, like I wanna have my conference, Burning Man conference, right?

I shouldn't call it a conference, but I want to have my local event, and we're going to create our own WAM for the event, and we're going to do some intent settlement for exchange of physical food, or something like this. Why would I send my intent to some global settlement system or global sorry, global intent matching system? It doesn't make a lot of sense to

me. Yeah.

So I don't think that like, to be clear, I think SWA, what SWA actually proposes to build, you know, building maybe a faster system for Ethereum and designing it in a way or designing like ways to map the idea of an intent to the EVM, I think that's very useful. I just don't, it's not, it's not like, it's not going to be the 1 true place where all the intents go if, as I understand the economics at least, it's going to be like, maybe there's a, Swath has a nice network and kind of a nice language for intense in a way that is EVM compatible, which, you know, that seems very useful to me. And I would imagine like lots of intense going there, but not everything. And in particular 1, you know, I guess maybe a practical challenge, at least, you know, the way that we've kind of thought about things as far as we know, is that it is really hard to make long-term privacy Ethereum compatible or EVM compatible, because the EVM just didn't think about this from the get-go. Privacy is not a feature that you can add onto systems after you've designed them, almost never.

It's something you have to include from the get-go. And I think, you know, Aztec, for example, also has basically decided not to build, not try to build a private EVM, as far as I know, nobody is. So I think that's very difficult. But you know, what Suave's like temporary privacy for intent solving in SGX, I think is very helpful, and is also compatible in principle, with privacy, larger privacy preserving systems. So I hope to see kind of inter-operation there.

The only other thing I would say is that, you know, to kind of perhaps provide a tangible aspect to the part of a peer-to-peer networking that I brought up earlier. 1, the reason I think it's so important to come up with a good general protocol for peer-to-peer networking is that it would allow these systems to compose more cleanly. So at the moment there's like the Ethereum mempool and there's, you know, the Cosmos have mempool and the Osmosis mempool and the, you know, blah, blah. They're like a million different mempools. And they're all separate unstructured networks.

So like separate, if you think of the system as a bunch of circles, they're like separate circles. And then there are specific lines in between, which are sort of specific bridges or relays or nodes, like in IPC's terminology, relayers, but nodes who are copying messages from 1 circle to another circle. And that is, when you zoom out and squint, you see that this is kind of just really a Venn diagram, right? And you have all of these mempools and people are sometimes sending messages to 1 mempool that doesn't impact another mempool. And sometimes they're sending messages to 1 mempool that sending a message that does impact another mempool, right?

So you have this all this kind of partial overlap. And I think if we design the peer-to-peer networking part well, we can get a protocol that does all of this. So instead of there being, you know, 50 million mempools or whatever, there's 1 mempool protocol that handles these kind of partial overlap scenarios and handles heterogeneous security and maybe even some stuff related to privacy. And then everyone can configure that in the way that they want. They can configure that with their validator set or their specific intent acceptance criteria rules for which messages to accept from whom and how to relay them and stuff like this.

But they can agree on the protocol and that would make it much, much easier to compose these systems. So I hope that we can, you know, we aim to work with FlashBuzz, for example, on 12, and anyone else who's interested in this question on standardizing it at this layer.

Yeah, I think the P2P layer of intents, And I really like the abstraction you mentioned about these shared or partially overlapping mempools. I think that's not often talked about, so that's super interesting to hear.

Wow. We're getting very, very deep. And this is extremely interesting. I feel like this is probably the leading edge of all like research on this area. And I think there's so many unanswered questions and so much like knowledge in Chris's brain to like mine.

But I wanted to go back a little bit more high level again, just because I think there are some other details about how intense work that maybe some people listening, including myself don't have like a fully clear picture of. And I just want to get those like covered as well, which is I know that like in these intent architectures are there are some like new concepts that don't exist in the standard blockchain world. So there's like this concept of an actor called a solver. There's also, you know, these proofs, which, you know, I think Zaki alluded to, of, you know, it can be a proof of optimality of your trade, or maybe it's a proof that, you know, something happened on a different chain so that you can settle those intents. And there's also sort of this notion of like a credible commitment that Chris was talking about earlier, like what does that mean?

I kind of want to, I don't know if anyone can sort of unpack a little bit more of these details and maybe do it via an example of maybe that cross-chain trade. What is happening? Who are the actors in the system and the different moving parts?

I'm happy to take this, but I also don't want to talk too much, so I would be happy to yield to somebody else if anyone else has thoughts.

I mean, I have a super simple example. Maybe Nick, you're kind of looking for something that's maybe more relatable to the things that we have today. I think, for example, a cross-chain RFQ looks a lot like a proto-intent system. So, you know, I'm a user, I have some ETH on Ethereum, I want some like, I don't know, OP token on Optimism. I broadcast that desire to the world.

And then I kind of request a quote and then someone else is like, who's a sophisticated actor or market maker, is doing a transaction on Optimism to send me my OP tokens. And then they're like taking my Ethereum that maybe I've like locked up in some contract after there's a proof they've sent me the OP tokens and maybe they like participate in some auction for the right to like fulfill my quote. And then we already have people like doing this today. There's RFQ systems. I think they're generally auctions.

I'm not sure like whether they're conducted on chain or not. And generally, they seem like a little centralized. But I think that's just like a very concrete example of how a proto intense system working in the wild today to make things like more concrete.

I like that Henry Henry's raising his hand or go ahead Chris actually whichever 1 of you guys

no no Henry

oh well no maybe Chris should go because I was gonna give an example that is kind of a different flavor okay

well I was just going to going to address specifically the solver part of the question, because I think it's helpful for understanding the intent frame. In general, if you take intents to be some kind of preferences over the state space of a system, most of these systems are quite flexible. And so in the general version of the kind of intent matching problem, the problem is in NP, right? The complexity class NP. So it's a sort of search problem where you have verifiable solutions, the intents of course define what valid solutions are, but you don't have polynomial time algorithms in the general case for finding solutions, at least not so far as we know.

If p equals np, everything breaks and we can all go home or do something else with our lives or something. But for now, it doesn't. And there's part of this problem that is like kind of unbounded search, right? And unbounded search is something that you do not want to do in replicated computation, right? You want to have someone do the search and then verify the results of that afterwards once you've found some solution that satisfies the requisite criteria.

That you can achieve the test, right? So in our lexicon, at least from a nodes perspective, solvers are the entities doing the search. They are not, you know, so they have some choice perhaps over execution paths. They can come up with execution paths that satisfy the criteria of intents over those intents, define those criteria. But mostly what they're doing is just search.

If you define your fairness criteria clearly or something like this, or your welfare maximization criteria clearly, then solvers are kind of done, quote unquote, or so to speak, or they're like they're entities who you're paying for specifically doing the search, like you're paying them for compute in a way that at least we tried to design things so that solvers are basically fungible, like you're creating a market for compute and maybe you want some resiliency properties, so you're overpaying a little bit or want a few solvers to submit solutions or something like this. But because you can verify the results of that compute, you don't need to trust the solvers at all. If you're not disclosing information to them, and sometimes you might be disclosing information to them, and then this equation is a little bit different. So it depends on what rules end up overlapping. But in the purest definition, solvers are just doing the search problem.

So how do I know that the solver, let's say I say I want to trade, you know, this thing, how do I know that the solver actually gave me a good deal and achieved a good price? Or, you know, obviously, I can verify that like the state, the outcome is, is like within what I stated, as I as like my boundaries, my constraints, But what about the other aspect of it? Is that just auction mechanism that kind of guarantees that?

Right. I mean, there are different, you know, at least I don't think there's a like universal mechanism here that gives you the best properties in all cases. I think there are different specific mechanisms that give you different properties. So an RFQ system or a kind of order flow auction system is based on auctioning with Intents, basically based on running an auction. Another thing you can do is just, the nice thing about intents is that they're cheap.

So you can like send a lot of intents and gradually change the price over time or have a price curve and an intent that goes down as a function of time. You know, you need some sub reference clock, perhaps signatures from a validator set. And then you can just like, especially if you don't know the price, this can be helpful. You can say, you know, depending on your time preference, you can say like, I'm going to start with this price, high price that I like a lot and then gradually lower that price and see who picks up my intent. That seems like it's almost certain to happen in kind of a dark forest world where a lot of liquidity is private.

Then you can also do something where you basically restrict the role of solvers to only compute by having first a commitment to ordering as an intent, typically encrypted in some fashion, are ordered and then they are decrypted and then solvers search for solutions, but those solutions are required to satisfy fairness criteria. So these fairness criteria might be something like fair market clearing price or a batch AMM. They might be something like Pareto efficiency improvements for a sort of slightly more general version of the problem. They might be, you can have other welfare metrics, like you could make your welfare metrics localized to some community and then it would be like improvement along the welfare function defined for this community basically. And in this case, because you separate the roles, So the validators or something are ordering intents while they're still encrypted.

So they don't have any information on them. Then there are threshold decrypting them or windows decrypting them. And then solvers are just searching for solutions that have to satisfy the strict criteria, including processing all of the intents in that batch. So solvers don't have a lot of freedom to optionally include or not include things. Henry, you

were gonna give an example too.

Yeah, so this example is like a little different. For Penumbra, I guess we have a different sort of approach towards the same goals in that we haven't really started off with like, here is the overall vision. It's sort of like, let's try to solve a problem and then stumble backwards into a good idea. And we actually end up having sort of like 2 different intent systems. 1 of which is actually not even, like never touching a chain, never doing anything.

And we use that just to paper over the complexities of having a like UTXO like system for managing notes or doing other stuff. If you imagine making a transaction, even just like a simple send transaction, if you're in an account-based system, you can say, OK, like debit X tokens from my account and increase X tokens in this other account. But if you're in a shielded system, you have to be saying like, I'm going to consume these little state fragments that are recording this balance, which are effectively like shielded UTXOs. And so actually like planning out your transaction involves doing UTXO management. And that sucks, like not even from a like usability perspective, but from like a dev UX perspective, right?

If somebody is trying to write a front end, they don't actually want to be doing, for the most part, fine-grained management of UTXOs. And so we ended up kind of basically building a sort of proto or a trusted intent system where someone can specify, here's like a high level description of what I want this transaction to do. And our own like sort of client stack can translate that into, okay, here's a specific transaction plan. Here are the specific notes you're going to consume. Here's like, you know, the change notes that you're going to make to yourself to make the whole transaction balance and so on and so on.

And I think this is sort of an example of a thing that I mentioned at the beginning of like sort of blurring your eyes like seeing this sort of fractal nature of reality and distributed systems where if you think deeply about any 1 component of any of these systems it ends up actually having a lot of similar problems you know in inside of that micro scale as the full system writ large.

Hmm whoa, yeah, that's sounds like you guys are really thinking about this in a deep way and the way that it will affect users. And I think you're baking in a lot of like very, very cool approaches to solving these problems. I think so we're kind of up on the hour here. I think we're gonna go maybe another 15-20 minutes or so. So I want to start like, wrapping things up.

1 topic, I mean, I want to talk more about privacy and MEV and stuff. 1 thing I want to make sure that we also just touch on quickly, selfishly, is sort of the overlap between overlap or not overlap between intense and modular blockchains. Because at Celestia, we do believe that this modular blockchain architecture is going to be a big way that we scale these systems and onboard more applications and solve a lot of the core problems of blockchains. And it sounds to me like there is like intents are another really big part of solving these problems. And so I'm curious on like the overlap.

And I guess for me, the thing that really jumps out is that a modular blockchain future is 1 where the number of chains really proliferates and it seems like intents are very necessary in that kind of world where, you know, like Umu was saying, if there's, you know, just even just a handful of rollups, it's really hard to manage all of your accounts and wallets and balances and all that stuff. If you're also if you're interacting with a bunch of different chains, like, you know, these apps are living in different domains, and you want to like compose them from a UX perspective. You know, bridging is 1 thing, but even just the user experience of trying to interact with all of them at the same time, even knowing like what bridges exist and what liquidity is there is like, basically, it becomes so complex, like the, the complexity just explodes. And I feel like you need to offload that complexity to more sophisticated actors. So at least that's the way that I'm, I see that this overlap, I'm curious, if you like what what your guys perspective is there.

And last but not least, another like small tidbit that I want to touch on is like, what, you know, intense is definitely something that's not built into this last year data availability layer. I don't think it's really necessary for something that is just so simple as just like, hey, I want to post this blob of data. But I'm curious if there's any reason that you guys would see for having some kind of intent like thing within a lazy blockchain like Celestia.

I think something you said earlier about cross-domain people kind of arriving too intense and like there being a reason for that is I think having this super modular stack solves a lot of problems. And I think it has a lot of pros. But then the cons are also created because it is way more fragmented, and users have to keep track of a lot of different things across a lot of different rollups. And then intense is kind of this way of solving that. And, you know, keeping what helping keep most of the pros and then also getting rid of the cons.

So I think that's why people in the cross domain space think a lot about intense. And I think that's why it comes up in this like, with the rise of the modular stack, I think that's why this has also become more popular to talk about because the problems are only now being created by having so many roll ups.

I'm curious if Zucki, yeah, go ahead, Zucki.

Okay, so I think like, 1 of the things that has become an increasing part of like my framing of blockchains is Probably there are only 2 layers of blockchains that are like actually accrue value. 1 layer is like we sell basic commodity, like we sell data availability, we sell like you know execution in a shared state with a bunch of other things that, you know, are valuable. And then there's like, you know, my my my joking phrasing of it is like artisanal, organic, non-toxic order flow. These are like the These are the things that are valuable in a blockchain. And Celestia is canonically a vendor of a base commodity and potentially a shelling point for shared state execution that might be valuable.

And then the real goal that we all are trying to build to is to build the farmer's market of artisanal, organic, non-toxic order flow.

I'm loving this analogy. I'm sorry.

Yeah, so I mean, I think, you know, like my general view of this is, you know, we're going to see, you know, like the other, you know, the other thing that has to be, like, I guess, re-emphasized is intents are not a future concept to a large extent. Intents are already here. You have cowswap, which is this, you know, phenomenal mechanism by which users sign intents to perform a swap and solvers. I probably first talked to Martin Kopelman about CalSwap in

2017.

This intent idea is not remotely new. And, you know, like visionaries have been working, you know, visionaries in the space have been working on it. Oneinchfusion is another example of an intent system. You know, even something like the OpenSea order book, which is based on Chris's prior work on Project Wyvern, is an intense system. So basically, many, many, many people who have used blockchains, also Mevshare from Flashbots, another great example, And they're doing the programmable privacy thing that is kind of like another frontier of it, which is like, it's done in a centralized setting, but you can, not all, everyone who is trying to figure out, to essentially bid on your order flow, can see your entire order.

They can only see some aspects of your order. And so we just keep seeing proofs of principle. And I think these proofs of principle, and yeah, I could go on. There's so many examples. We have these things that we do in Cosmos where we like delegate or like a user signs 1 transaction but actually multiple steps have to occur asynchronously across multiple blockchains and like you give that to the IBC reware.

So we just keep building systems like this. Intents are already here. Intents are going to be a big part of successful systems built on top of the modular architecture. And ultimately, you know, the goal of like intense systems is to like, really elevate that like, you know, organic order flow.

Beautifully said, Chris.

Yeah, I guess, yeah, I'd second both of those sentiments. I think, to me, another maybe common intuition in the concepts of modular blockchains and intense central design, Also related to Henry's point earlier about kind of seeing intense centricity fractally or sort of in different parts of the system. I mean, I don't work on Celestia, I don't know everything about it, but as I understand the idea of modular blockchains, it is to kind of separate out the functional components that different parts of this distributed system are providing such as data availability, maybe or long-term storage or compute or sequencing or execution, and come up with interfaces around those components that kind of define them in a sufficiently general way that you could put together these different building blocks, which are compatible with the interfaces and get lots of different configurations of system. So it's like, you know, block, legal blocks for blockchain, something like this. That's how I understand it.

And I think that there is, you know, a 1 thing that is you really want to make sure you do if you're trying to build a composable system of primitives is define interfaces that specify at the right level of abstraction, that are not too specific, as in you don't want to define interfaces that include details about how some subcomponent does something, because that restricts the freedom of people implementing that subcomponent by preventing them from doing something. But you want to include interfaces that define the properties that you want the subcomponent to have, right? So you want a very declarative interface, like prologue style. I think there's actually direct precedent for this in unrelated research literature in something called denotational design by Kunal Elliot, who's like a really, really long-running and skilled programming languages researcher, did a bunch of work in Agda and some other stuff, that has kind of a more mathematical formulation for what it means to design a system this way. But it's like at every layer of, you know, you have sort of a DAG of definitions, for example, and at every layer, you define what you want the underlying primitive to do from the perspective of an observer, which in this case is like the code that is calling it.

So for example, with data availability, the way like, you know, architecture thinks about data availability is that, you know, someone who is seeking data availability, wants some data to be stored for some period of time, where that data will be retrievable subject to some trust assumptions, right? And the person, the consumer of that interface has basically like a data availability intent. Like they want to get data availability in a way that is compatible with the things that they've stated. But they might not like, they might not care about exactly how it happens as long as it's compatible with their preferences. They might be fine with Celestia doing it or some subset of the Celestia validators doing it, or they might want Ethereum to do it, and they might want the data to be stored for 15 days or 30 days or something like this.

So they are like 1 side of the market, right, for data availability. And on the other side of the market, the providers, as Zaki put it, of this commodity would be, you know, like Celestra, for example, the Celestra validator set, the Ethereum validator set. I mean, most blockchain systems that are actually running can provide data availability for a fee. Many of them are not designed to do it, but it's readily available in some sense. So I think that if you architect a system in this intent-centric way, you know, we're trying to kind of come to a pretty clear methodical definition.

We can even input into Agda or something like this, which actually checks that our design accomplishes this, but you end up with like intense centricity at every layer. And I think that that's really like, not maybe not exactly the same thing, but but a prerequisite maybe for the kind of modularity that you might want out of a modular blockchain system. That's my understanding of the relation.

I see. So you're saying that there could be sort of an intent layer even for each service to some degree, like even data availability. And so it makes it kind of like hyper modular in the sense of like, there's multiple, there's so many different options for data availability. And you just sort of set your parameters of like, maybe security threshold or like, yeah, you said the duration, etc. And then you put your intent out there And then someone else is like, oh, OK, well, this is the right solution for you.

And they sort of like bring the supply and demand together.

Yeah, I mean, sometimes you won't you don't necessarily always need like a distributed market over the network. I mean, in Henry's example of a transaction plan, you the intent matching is happening like on Gore machine, in 1 trust domain and with exactly who the counterpart is, but you still want this kind of interface because it allows the user to kind of say what they want at the level of specificity and abstraction at which they want to say it, and allows the system to do some work on behalf of the user figuring out how to do that. In the case of the transaction plan API, as far as I understand, selecting which nodes to use to consume a transaction, for example. So I think the interface pattern kind of holds generally. Maybe another way of articulating it is that I think designing things correctly in this way, for example, ensures that Enoma and Celestia will be compatible without even trying.

Like if we design things in this way, you design things in this way, maybe the modular blockchain way, or when I talk to people from Celestia, I talk about dependency inversion or something like this, I get the sense that we have very similar ways of thinking about modular design. So I think that if people agree on a clear way of thinking about systems this way, you end up with, because you have thought about how to define the interfaces in this sort of maximally general way for the function that's being provided, such as data availability. There's a 1, there's kind of 1 unique maximally general way. Like data availability is a thing and you can parameterize it in certain ways, like who's doing it, what your trust assumptions are and how long the data is stored and what the data is is just an input to the function. So then you end up with compatible interfaces magically.

I didn't need to go talk to Celestia. And I think that's very, first, sort of permissionless or kind of a coordination of an ecosystem of people who are building different components. Coming up with a way to have compatibility that doesn't actually require the people to talk to 1 another is really powerful. It's like a huge sort of boon to our ability to build systems that compose with each other.

Cool. So we got to wrap up here pretty soon. So I have 1 last question, and then we will wrap it up. And that is that Zucky gave an outline of a few of the systems that are live right now that already have some sort of version of Intents implemented. I'm curious to hear 2 things.

1 is, what is the current state of Intents, like the different projects building them. So this is like a chance to shill a bit about Onoma and also Penumbra and other projects that are out there and like Swab, for example. And then I'm curious to sort of project a little bit into the future, let's say like 3 years from now or so, when the whole intense architecture and actors and this whole, I guess, stack is built out more robustly and people are actually using it like what does it look like and like what kind of world will we be living in and even you know I'm curious like as a user what does it look like do I just kind of like do I even you know open up my wallet and like am I switching chains Or do I just have this like master view of like, all my accounts across all chains, or I didn't even realize that there's different chains. And I'm just like, you know, saying, saying things and they just magically happen? Like, is it 1 portal?

Like, what, what does this actually look like? Through like, you know, in the future, if, if this all works.

Couldn't remember if it was directed towards me. I sort of vaguely remember it being towards me.

It could be anyone. I think I want to hear everyone's take.

Okay. I kind of view, my suspicion is that like, Intents are like the capstone of like, the last, you know, 10 years of blockchain, like infrastructure building, is basically like my point of view on this question, which is like, you know, We've had a lot of problems that seemed insolvable, consensus, data availability, bridging, what should your smart contract be written in, what language, all of those things. Lots of progress and privacy. All of these things like actual like concrete progress has been made of. But I think like the last, you know, especially this like, you know, the pandemic period, right, where we had all these people come onto blockchains, I think to me, it was very informative, just like, oh, okay, like, where is this whole system going to break down.

And so yeah I think the intent world is ends up being I think there are like I don't think people will do everything with intents. I don't, you know, I'm not, I think the full, you know, you do everything with intent. Like sometimes it's just not going to be worth it. It's just going to be, especially if you're just like, if you have like 1 of 1 kind of things, If it's like, I want to breed my crypto kitty, it's probably just easier to specify the transaction. There's only 1 path to do it, you're dealing with a singleton object.

But the future wallets will be able to abstract over so many workflows that confound users today. And the workflows that are the most popular workflows, like token swapping, buying NFTs, all of these things. Like, you know, in an intent world, you don't need to know whether or not the NFT you want to buy is on like OpenSea on ETL1 or Solana or Stargaze, which I think is like 1 of the things that the intent world is going to do is it is going to abstract over and like commoditize a lot of the differences between ecosystems. Like people were Like people will have their sports teams, they'll have their favorite thing, they will be communities around tokens, but if you're a user, you're gonna be like, yeah, I open up a wallet, it speaks this intent language, like I see an NFT I wanna buy, I buy it, like didn't have to know anything about what blockchain ecosystem it was part of. It's like, I saw the picture, I could buy it.

Anyone else?

Yeah, I think the state of Intents today, Zaki actually talked about it, it's already here. There's a bunch of apps, I think, that already service these very app-specific Intents, whether that be DAX aggregators or 1-inch Fusion with RFQ, which I guess is a DAX aggregator. And so I think there will continue to be more app-specific intents. And I think in particular at Sucinct, we care a lot about making interoperability better and making the interoperability UX today much better than the current bridging UX. The current bridging paradigm is super broken.

And I think we want to create a future where users don't even know what a bridge is. That's a concept that will be long forgotten. Things will be happening behind the scenes and they can just take the actions they want to take. And I think like the step to building that is going to be have another kind of proto intent or bridging specific intent system. And I think that's what we're kind of working on and thinking about right now.

And hopefully as we're all building these different app-specific intents, we can also talk more about a more general abstraction. So it's not like everyone's building their own intense language and settling these intents or having solvers for these intents in a centralized way and there's a more decentralized platform and more decentralized order flow auctions to help solve these intents. And there's going to need to be some coordination there if there is going to be like a more general solution that everyone can coordinate on. And I think the general solution will have a lot of benefits, including decentralization and more competitiveness for the solvers. And so in the end, it also is important for users too.

I like that. Henry or Chris, do you guys have any thoughts on this?

Yeah, I mean, I agree with everything Sakunuma said. There are already intense systems. I think that some parts of those systems are inefficient in ways that maybe don't matter so much. And some of them are inefficient in ways that matter a lot. Like the peer-to-peer part of those systems is just really inefficient at the moment, you know, when they're sort of used for intense because it wasn't designed with that in mind.

I think the, you know, the nice thing about, you know, thinking about systems in this intense centric modular way is that if you if we kind of do it well, it ensures a certain kind of future compatibility. If we build these nice, well-abstracted intent-based systems for bridging, for example, or state machine verification, stuff like this, then we can have our current batch of blockchains, which have a lot of valuable state, right? They have assets and different smart contracts and things that people value, and they will want the future world to be able to reference that state and kind of build upon it. And that I think, will be, you know, rather possible by starting to build these kind of proto or more specific intent systems and progressively making them more general or able to interface with those systems in more general ways. 1 thing that we're working on in Arnoma that we hope will help with this is a good sort of general abstract definition for intense.

So like the equivalent kind of to like the Turing machine is like a nice abstract definition for what a computer does. And it, you know, very few actual computers implement Turing machines, like they don't literally have a tape, that would be ridiculous. But they do something because Turing machines are sort of universal in this way that is relevant. They do something that's equivalent, like you can translate between different specific implementations of this general thing. And we're trying to come up with such a general thing, but for intent systems, which includes sort of privacy, or it's kind of more general, a cousin, which is, I think, better described as information flow control.

So you could think of that as an intent language, yeah, and also sort of a model for what, like a way of defining what it is that an implementation of an intent system must do in order to be correct. Just as Turing, you know, you can implement something that will like faithfully execute a program, program for a Turing machine if it simulates the tape or something like this. And then you can specialize your special machines for different specific programs written in different specific ways. And I think that will continue to happen. Like there won't be some, you know, maybe some things can become over time more and more compiler problems instead of sort of human design problems, the optimization frontier will move to algorithmic choice.

But there are still going to be lots of specific different things will just move, you know, or can move towards more general things over time. The only thing that I'm like, specifically, kind of still a little bit worried about is that I think it is difficult to make systems, in some cases, difficult to make them compatible with privacy. Or if you are, if you embed, you know, transparent verification as a implicit design assumption into your proto intent system, it may not be compatible with privacy preserving systems. So I think that, you know, thinking about that at this stage is perhaps important.

Yeah, I love the idea of creating a definition that is sort of like universal kind of like the Turing machine for intent-based systems. I thought about that a lot in the context of modular blockchains, too, of how we try to break down these different functions. And you need a minimum set of these functions of data availability, you need ordering, you need some kind of socially agreed upon validity rules to implement a blockchain, essentially. So I love that. And I'm interested to see how that goes.

We're kind of up on time so I just want to, you know, I want to open up for you guys to give some last closing thoughts before we wrap up. So Henry, maybe you want to go first. And anything that you want the audience to take away from this conversation about Intents or about what you guys are building at Penumbra. Go ahead.

Yeah, I mean, I don't want to show too hard. I don't, you know, I think we're building some pretty cool stuff. If people want to check it out, I would definitely recommend it. But the thing for this context, I think the thing that I think people should take away is that intents are already here in all these sort of different manifestations. And also that it's really interesting and important to look at systems both in a component by component approach as well as a holistic approach that lets you ask, like, okay, what are actually the boundaries between these components?

And the reason I think that's important is that if you think of this sort of full stack concept of protocol development of like from a user, like how do I trace a user's OODA loop as they're decide like they're seeing what is going on in the environment, they're deciding what to do, They do some actions, they observe the effects of those actions. That flow, you can trace through some system. And as you trace that through, you'll discover what, you know, the actual scope of the protocol is. And through that whole stack, at each individual layer, you see intense systems already in place. And the thing is just to sort of like take this sort of like raw material, it's like under the marble or whatever and flesh it out and chisel away the pieces until we get this sort of beautiful future.

I love that. Anyone else? Closing thoughts?

Um, Yeah, I guess my, my closing thought is. I do think that, like. This does represent, like, a pretty big change of, like, over, like. What, like, you know, layer 1 protocol designers have, like, considered their, like. Priorities and importance.

They're like, okay, we need to have transaction privacy, we need to build encrypted mempools, We need to build ways in which users can read what the effects of the transactions that they're signing are going to be. I think there's been like a, it does represent, I think the reason why this thing is interesting is because of the shift in priorities, right? It's like a shift in priorities as like what is the most important piece in making blockchains that solve actual users' problems.

Chris or Uma?

Yeah, I mean, I would second both of those sentiments, particularly Henry's, which I thought was beautiful. And maybe he won't shill Penumbra, but I will. I think Penumbra is the like, you know, an amazing example of a sort of near-term privacy-preserving intense solution kind of optimized and designed around 1 specific use case of private trading or privacy preserving trading, but designed to such a level of precision and kind of careful reflection on what it is that that product does and for whom and, you know, the OODA loops of the users, etc, that it ends up, you know, being this kind of specific incarnation that illuminates the more general concept, right. So I'm very excited about that, both using it and kind of seeing the whole through the lens of the part in this case. You know, to me, I guess I think to echo on Zaki's point a little bit, 1 reason that I find Intents helpful or that we found it helpful in our design questions is that they provide a good way of framing the general problem of what is it that these systems are supposed to be doing?

Like, what is the problem that blockchain solve? Right now, intents don't provide, they don't provide a like specific answer to that question, right? They don't answer the question of, you know, do I want this asset or do I want this other asset? Or as I think as Sam Hart put it, the thing about intense is that you assume that users know what they want. Well, yes, I mean, if users don't know what they want, maybe they know it to only a certain level of precision that could be modeled.

But if users don't know what they want, that is just not a problem that economic systems solve. So I think a general concept can be helpful, actually, because it illuminates what a system can't do, if it's if it's sort of sufficiently general, or what like all systems of this sort just can't do, like it finds the boundaries very clearly. So, you know, I think that, as we think about things in this intent-centric way, it can give a useful lens to which parts of the stack are perhaps underprioritized from that perspective. Like I guess today I sort of made the case for that peer-to-peer networking as being as a part that's been sort of underprioritized from this intent-centric perspective. I think that VM design is another part that's been kind of underprioritized from this perspective, you know, the talk I gave at Research Day was a little bit about that.

I think that, yeah, maybe maybe thinking also about what privacy means in an intent centric world. And, you know, whether maybe, you know, to me, I'm not sure privacy is actually the right word for what the systems are doing. But I think examining that question was also important and kind of helpful, using intents as a lens through which to understand these different components of the design problem, as Henry mentioned. So I just hope that, you know, if we think about the components clearly, and kind of, you know, as as an ecosystem of people working on these many different specific projects, which implement different specific parts of some potential intent centric future stack, that we kind of keep talking about things and come to a good, you know, good sort of social consensus that achieves the kind of appropriate distribution of labor across these different components of the whole problem.

I just wanted to say quickly that like, when I like initially started, like when I was thinking about this initially, I really questioned whether or not the privacy component was essential to the success of an intent system. And like whether or not we could roll something out that would like meet some like practical use cases without having some form of privacy involved. And I like have mostly run into the wall like really challenging problems when you don't have privacy. Your ability to like, you want to reveal when you're doing an intent, like, hey, you don't want to reveal, like, here's the most I'm willing to pay, because if you reveal the most you're willing to pay, you will always have to pay the most. And so, like, you know, this is the, these are the, so, like, if you want to have, like, to have not highly interactive processes where a user's device has to be online and interacting with its counterparties and adjusting its bids and offers and pricing and stuff like that, like pretty much the only way to build non-interactive systems is with privacy.

So, really, really become convinced of the importance of privacy in building intent systems.

Very, very interesting. And I just want to say that since Chris won't show Noma, I will also just plug. I know that you guys are launching Nomada soon. And so people should definitely check that out. Uma, do you wanna offer any closing thoughts?

Yeah, I feel like we've been over quite a lot, so I don't have too much more to say other than I think the most interesting thing to me here is like the intersection of kind of the research and theory community, like lowercase r research with like actual focus on UX, because I think that is like 1 of the biggest problems in crypto. And I think I just hope I feel like with Intense, it's been this really good shelling point where those 2 groups have met and people who normally don't talk have started engaging. And so I think at a metal level, yeah, that's something that's cool to see. And I hope more of that keeps on happening.

OK, well, we covered a lot today. This ended up being longer than I expected, but I think it was hard to avoid that because there's just so much to unpack. And I think intents are going to be such an important topic going forward and across the whole industry. And so I'm really grateful that we had you guys here to explain all of that to us. And I think there's a lot more conversations to be had clearly.

And so I hope the conversation continues on Twitter. And also I want to say that we will be definitely having a lot of intense content at Modular Summit this year in Paris. So I encourage everyone, or people should look out for that. I'm loving having a lot of speakers like the 3 that are here. And yeah, I'm looking forward to continuing the conversation in Paris with all of you guys.

So thanks everyone for coming and we'll see you next time.

Thank you for having us.