Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Infinite Layers: Designing Expressive Intents featuring @khushii_w @apriori0x @knwang
Recorded: March 31, 2025 Duration: 0:47:35Space Recording
Short Summary
The discussion introduces new projects like Predicate, Kalani Network, and Anoma, focusing on innovations in policy infrastructure and intent-centric systems. Emerging trends include the convergence of Web2 and Web3 transactions and the potential of intents to address MEV issues. The conversation also highlights the underutilization of intents' capabilities in current applications.
Full Transcription
All right, welcome everyone. We're here on a Monday to talk about something that's kind of
interesting, something we've never really dived into before. And we have a lot of diverse guests
here that are working on some really cool stuff to chime in. They have a lot of domain expertise.
So here we have today with us, we have Cushie from Predicate, we have Kevin from Kalani, we have a priori from Anoma. So if you all want to do quick introductions,
then we'll dive right into the topic. And maybe we'll start with you, Kushie.
Yeah, absolutely. So my name is Kushie. I lead strategy at Predicate, where we're building policy infrastructure. So we basically set up the rails for application developers and users to set rules on the types of transactions that they want to interact with their application. And so that's what we've been working on for a little while. We integrate with protocols, with DeFi applications, and all sorts of other applications.
Kevin.
Hey, this is Kevin, co-founder of Kalani Network.
So you can think of Kalani as the solving infrastructure,
and then we're not just one solver,
but we are the decentralized network
that allows solvers to join and collaborate.
So in a way, you know, you can think about this
sort of like, you know, a marketplace
where you can access different solvers.
And, you know, as an infrastructure,
we allow solvers to also work with one another, right in other words it's not just a place where you come in and
uh express the intent and someone to compete but they also collaborate to be able to solve
um to resolve intents
Awesome. I go by a priori. I work on Anoma. I work right now. I'm doing some product discovery
work. Anoma is a intent centric distributed operating system designed to satisfy everything
from intent to intent. And we'll have more information coming soon on some interesting product designs.
Okay, great. So our topic today is around designing expressive intents. But before we
even get to what that means, let's maybe dive into a quick definition of what intents are and
kind of how people are using them now and then potentially some of the thoughts
around how they might be used in the future and anyone that wants to take this feel free to chime
in it's like who's gonna speak for definitions yeah definitions i mean i i'll use like a really
simple one uh because i think uh i i've used like the other ones too much.
So I'll just say an intent is a way to express what it is that you want without having to worry about how to get what you want.
So you can think of an intent like when you talk to your LLM, you have this intent, which is your prompt,
and you give it some kind of like constraints or instructions,
and then it tries to predict what you might want based off of what you give
it. And then it gives you a solution.
And then you can kind of like iteratively say whether or not you like the
solution or not. So maybe that's not like a specific, uh, crypto definition,
but I think that's kind of conceptually.
Yeah. And it might be good to talk about some of the use cases.
Like what, what would this be used for in an application?
Sure.
So if like today you wanted to express an intent, you could use an application like
cowswap, for instance, where let's say that there are different types of ways that you
could express your order.
So you might have a preference for a particular limit order.
You might have like a TWAP preference.
You might have a preference for a particular limit order. You might have like a TWAP preference. You might have a speed preference. So you might just want a market order and you kind
of just sign a message and some solvers go and they compete first and they try to do either a
ring trade or coincidence once. And then based off of their findings there, they will also then look
to see if there's any kind of private liquidity via some RFQ or other private liquidity that they
have access to. And then they will also look and see what type of routes to on-chain liquidity
are available. So you as a user don't necessarily need to care about all those things, but those
liquidity sources are available to you just based off of the fact that you went to that venue to
express what it is that you wanted. And then the other popular place where they're used today
is in these cross-chain liquidity networks
or sometimes called in-time based bridges,
where a user can say that they want to move funds
from arbitrum to base and a solver or a filler
will go ahead and fill them on base,
wait for some kind of timeout period,
and then be able to go and collect their funds
that they had escrowed on the source chain.
And in terms of implementing these sorts of systems, there's probably a handful of different approaches.
So I'm curious, like for both Kevin and Apriori,
like for your teams and your companies,
maybe to kind of go over a high level overview
of your own designs.
Yeah, so I can get started here.
So for Kalani, we implement the intents
based on a primitive we call automatons.
And then, wait, am I the only person in the show now?
Nader, I think you're muted.
Oh, yeah.
Sorry about that.
I think, okay, here we go.
Hey, Kevin, sorry about that.
Yeah, yeah.
When an individual is talking, sometimes it'll just jump into a solo layout.
Oh, okay.
I'm sorry. It's being Oh, okay. I'm sorry. Okay, I'm back. So for Kalani, we implement this, our intent model
around the primitive, on-chain primitive, called automatons. Automatons are,
you can think about them as long-running intent. They allow, because we're a very solver-centric sort of infrastructure, we think about,
you know, how solvers can let users know
and then how solvers can let other solvers know what they can do.
So they can be sort of runtime integrated
into their solving intents.
So we have this primitive we call automaton.
The automaton is essentially like a long-running intents
that a solver can express.
This is the sort of thing that I can do.
And then they can also express
what would I like to hear from, right?
So we call this a sub-pub-sub sort of mechanism because as a solver, you probably want to hear from, right? So we call this a sub pub sub sort of mechanism
because as a solver, you probably want to hear
about the things you can do, right?
Or the servers you can provide for other solvers.
So for us solvers publish Tomatong to say,
hey, you know, I'm able to, let's say,
I'm able to trade USDC and USDT, I can be providing this liquidity on these five chains.
And because I'm doing USDC and USDT on these five chains, I can also do cross-chain liquidity on those five chains, but around USDC and USDT, for example.
Then I'm going to let other solvers know this is the sort of thing I can do.
So I publish this as a automaton or long-running intent and say, hey,
you know, this is the kind of thing I always want to do, right? So I'm not going to keep,
you know, pushing orders into all the, you know, intent venues and whatnot.
But you can look into this and then you understand, oh, I could be a counterparty when you express this sort
of intent, right?
Or you want this to be part of your field structure
or your solution.
So that would be the primitive that we expose for other solvers.
primitive that we expose for other solvers.
I'm having to dive deeper here as well.
But yeah, it is the right level.
And I guess for Anoma.
Yeah, sure.
That's a great explanation.
Thank you, Kevin.
So initially, Anoma started out with the vision paper
where the problem du jour was coordination. And the
idea was to design a system, large scale system of coordination without a unidimensional
unit of account to allow participants to factor many variables in digital expressions or their
values. So the question is like, how do you get there? And so over the years, as the team
was doing research and building,
what they came to realize is that what they're trying to build is this notion of a distributed operating system. So there are a lot of parts that go into that. And to relate more so
to like the blockchain context, there are basically two parts. There's a counterparty
discovery phase, and then there's a settlement phase. And so you can think of these as both kind of being like off-chain and on-chain.
The difference between what you have like with the protocol like Ethereum is that all of these
off-chain components are actually brought into the protocol, so you can reason about them.
And so in this way, we have a state model called resources, which is kind of a generalization of utxos and with resources you
can load in some custom resource logic which acts as constraints which allow you to constrain the
type of execution that you might do over those resources you could also load in a preference
via the preference function to describe exactly what it is that you want. So there might be some solutions, some solutions which are like not quite binary,
which might like range from zero to one.
And you might have some satisfaction preference along that axis
and just like a simple way to think like the data structure,
you can think of it as like an unbalanced transaction.
like an unbalanced transaction.
So in terms of, I would say, user experience,
it doesn't really affect how an application
or a user would interact.
This is more all, I would say, implementation details
around how the system is kind of implemented in general?
Yeah, that's right.
I think for building a world-class UX, the user needs to be mostly ignorant of
all of these details.
And that has a lot to do with great product design, also user stories and kind of a vision
for maybe where the future of the space is going.
I'd be curious actually what Kevin's thoughts are on like ideal front ends and um kind of the interplay with uh llms or different things like this
yeah i mean uh we've thought a lot about this too i think uh the the ideal front ends i mean
there's users and then there are fun developers and those are not the same. So the users ideally just don't have to worry about the underlying infrastructure at all.
And then the front end developers should act on behalf of the users, where the developers should be choosing,
if it is more about payments, then, you know, what's the underlying payment currency?
Maybe they usually just swipe a credit card, for example.
And then whether it's using USDC or, you know, these other dozens of stable coins, that's really, you know, the front end developer's job to say, hey, I will do the integration between the fiat rails to crypto rails using this currency. I'm going to use this.
If you need to go crosschain, then pick a specific vendor with hopefully trustworthy
or have some sort of economic backing, maybe use eigenlayer, for example.
So that's really the front end developer's job, to make sure they protect the users,
because otherwise they lose users.
And then they will do a lot of integration.
They will do, you know, what Intent Protocol here can do
is to make front-end developer's job really easy,
because Intent Protocol essentially
gave them an abstraction to say, give me all the parameters that you want to facilitate this transaction.
And then whether it's maybe there's a basket of currency you deem as trustworthy that you can
potentially use to facilitate this transaction, just all depending on runtime, who has the best
liquidity and who can give the user the outcome.
Maybe there are multiple security vendors
that you're willing to trust.
Maybe for the specific crosschain, for example,
there are only one vendor that can do this,
but they will not always be the same vendor,
may not be able to carry out all these transactions.
So you can specify, not only fancy what you say
that's a constraint, right?
So across all dimensions, you can specify constraints,
whether it's about security, whether it's about liquidity,
whether it's about latency, right?
You can say, hey, I really need this
to be done in two seconds because that's what it was.
So the front end developer can then
use intent systems to set out all these parameters.
And then you have the actual vendors, right?
So if you use a rule, for example,
this is the front end developer to say, hey, go to San Francisco
within two hours.
And then the actual drivers come and say, hey, I can do this.
And I will raise my hand and want to be part of this process.
So that's the solvers.
The solvers are the actual deliverer.
I guess they produce the actual outcome.
So they will help to generate this outcome for the users
as specified by front-end developers.
So in terms of UX for the user, it's about essentially cost and speed and I guess expressiveness
of like what you can actually accomplish.
And then for the developer, are they calling, are they invoking these through client-side
applications or from smart contracts?
or from smart contracts?
And I'm sorry if that's a dumb question, but that's the first thing that I'm thinking about.
but that's the first thing that I'm thinking about.
Yeah, again, this is happy to hear everybody else,
you know, opinion here.
Like for us, they just sign a message, right?
So they just help the user to sign a message.
And then the message should include
some sort of authority to spend money
because at the end of the day,
it's not going to be paid.
And then the payment has to come from users,
nobody else.
And then from there, what other, what's
the schematic of this message?
Where did they send it to?
I mean, this is the specific intent protocol's design.
And the ideal expressive and general purpose
general intent protocol should be allow anything to be
that can be expressed to be expressed now the tricky part here is to balance the expressiveness
and you know uh contractability right so you have to balance it enough so that you can express many
things but then the more you are constricted and you know expressive then you may
not be able to solve it may not be able to recognize this and solve it so that's the balance between the
two right so the intent system will help the front end to strike the balance to say you know
here's how you should express it it's as general purpose as you want but hey software can also understand what
you're saying uh so that you know they can actually do and you know do the job
so i guess to move on um i guess posing a similar question to cushy in terms of your implementation
around policy infrastructure and design i'm curious to get a high level overview there
infrastructure and design. I'm curious to get a high-level overview there and what went into
making the decisions to build it in that fashion. Yeah, absolutely. That's a great question.
So the way that we've built our policy infrastructure at Predicate is we wanted
to design it to be censorship resistant. And so we've built a network that's built on eigenlayer and it consists of a
network of operators. And that network has multiple sides to it. So we have our operators,
we have applications, and we have information providers all within this network. And the way
that all these parties interact together is the application set policies, which policies are just
a set of rules on the types of users and transactions that they allow to interact with their application.
Then those policies are enforced by the operators in the network.
And the way that they do that is they fetch the policy that exists on chain and they check to make sure that the transaction details that the application gives them adheres to the policy that was set.
And if it does, then the transaction is allowed to proceed.
And sometimes those policies can use information providers, which is another element of that
network.
And those information providers can be APIs.
They could be on-chain data.
It can consist of a wide variety of things. A few of the
information providers that we work with often are folks like TRM, Elliptic, Crystal, Cube3. These
all provide different forms of information that you can embed into your policies so that you can
use things like AML risk source, identity attestations, you can use geolocation data, like you can use all of these
different data sources within your policies. And then there's also some stuff that's built entirely
on chain. So our team has built a social graph, which allows you to track basic flow of funds
compliance. And then we've also built a geolocation system that allows you to choose what jurisdictions your users can exist in. And so that network exists
so that when an application sets a policy for their application, Predicate doesn't have any
control over what that policy says or what users are allowed to interact. In fact, it's entirely
built and enforced by this network of operators.
And so we chose that design intentionally
in order to build a system
that is maximally censorship resistant
while still allowing for expressivity
on the application side.
Got it.
I'm not sure if you have frozen or not, but I think my screen is frozen, but I can still
think. I wasn't sure if you're finished there. Yeah, a very unfortunate position for my face
to be frozen into. So what you all have built is kind of like a new, I would say, primitive or a new, I would say, like,
abstraction, maybe. So like, can you kind of go into a little bit about what you all
just drove you to kind of say, Oh, this is a problem that needs to be solved. And we have
a solution for that. And we're gonna actually go and like build that and make that a company.
Yeah, absolutely. So something that we realized that we predicted almost over a year ago at this point was that in order for traditional financial institutions and regulated capital to come on chain, there would need to be rails for that regulated capital to exist. And it started out with permissioned blockchains where capital was siloed into these environments.
But that capital wasn't allowed to exist with the permissionless decentralized applications that exist on public blockchains.
And we're seeing now that issuers of that capital and holders of that capital want to interact with the applications that exist on chain because blockchains allow primitives to exist that didn't before. And so now these
traditional financial institutions want to gain access to the yield that exists on chain, to
real world assets, to stable coin systems. And if they exist in these permissioned siloed
environments, they can't actually take advantage of the benefits that come with blockchain technology.
And so what we ultimately wanted to do was create the rails that allows regulated and open permissionless capital to exist on the same applications. So if you have a Morpho application for lending and borrowing, you can have a pool
that consists of regulated capital as someone wants it to be. But then you can also have a
pool that consists of fully permissionless capital all on the same application. And when those rails
exist, then you ultimately increase the amount of capital that exists in crypto altogether,
ultimately increase the amount of capital that exists in crypto altogether, allowing the ecosystem
to flourish. Super interesting. I think when this starts becoming like used a lot more in practice
and people start actually building really interesting applications, it'll probably
become more of like a well-known idea. But at the moment, it still seems kind of like
somewhat new, correct?
Like in terms of like, yeah, got it.
Okay, awesome.
Now, speaking of apps, I want to dive into apps a lot on both ends, I guess, but maybe I'll start with Kevin and Apriori.
What types of applications do you see developers building with intents that are kind of uniquely
enabled or just maybe enhanced by this
technique versus some previous techniques? Yeah, I think from my point of view,
Intense will allow, I mean, there are two legs of this, right? There's the Web 2 side of things,
and there's Web 3. So if we zoom in a little bit more like Web 3 native,
I think it's likely to be more immediate.
Intense will allow developers to build anything
that currently lives off-chain,
that will be sort of living or, you know,
close to blockchain, right?
Close to blockchain addition software, essentially,
for markets.
Those, today they exist,
but then they're either centralized
and have certain trust assumptions.
You have to be able to use them and so on and so forth.
Or the market structure of them operating is not ideal.
the market structure of them operating is not ideal.
So for example, give you an example.
So for example, give you an example.
With the intent, people can build a off-chain auction
network that will take order flow from applications
and then optimize the execution or the unction settlement
for the users or the wallets and whatnot.
And also guarantee alignment to make sure, you know,
this is a piece of Waterflow middleware that's, you know,
that can be directed by the app or by the user or by the wallet, right?
So this sort of thing today, you can build them, but it's very bespoke, right?
So you work with a specific
vendor and then uh you know you build uh maybe a te environment and then that's it okay so then you
have another app going to do the same they have to build another one right um whereas i think with
the intent you should be able to i mean this is where the column thesis right you should be able to, I mean, this is where the Kalani thesis, right? You should be able to have, if you could have these systems that are credible, neutral,
and reliable, and in a way verifiable as well, then other applications can just build on
top of it, right?
So this is composability theory, then you say, hey, you have this already, but I want
to tweak some problems.
I want this auctioneer to behave similar way,
but then a little bit different.
Can I spin out a virtual copy of this
and then optimize for my app?
And then whereas the liquidity, I want it still
to be sort of unified liquidity market.
That's more efficient.
So that's the thing I think with the intent
people will be able to build.
Uh, yeah, but anything, anything that live currently off chain, I think, uh,
can be directed by Intense.
So that's where the, where I see things are moving.
Yeah.
That was a really good answer.
I'd say, um, that's a good dichotomy, I think, between Web3 and Web2.
But I would say if you think about crypto applications, it's really just maybe four types of primitives.
Payments, swaps, leverage, yield.
And I think as people every cycle try to build new applications, they're around these
kind of primitives. And you already saw this cycle with hyperliquid success, or even with
pump fun on top of radium. It's very successful. This cycle did start to see some more traction,
I think, with social, which was interesting. You had experiments like Frentech and then you also had things like Farcaster.
So I think there could be like four or five, six, use case seven that are coming in the
future. But at least for now, like the Web3 apps that exist, there's still like a handful
of them. And so I think Kevin hit the nail on the head. One of the things you can do
is design more expressive auctions, especially when you get into the realm of the things you can do is design more expressive auctions, especially when you get into the realm
of having things with programmable disclosure where some information is private and some
information is public. You can do some cool mechanisms and design things there. So I think
DEXs are one area where we can continue to see a lot of innovation. I think borrowing and lending
protocols as well, we can see more innovation there. I think intents for DAOs or intents for
blockchains, so to speak, different service
commitments and things that services they might be willing to provide each other, whether it's like
ordering, storage, or compute. And then, yeah, I mean, I think the golden idea would be any of
these Web2 type of setups where you kind of have a marketplace and you can build these different
applications on top of this marketplace. So whether it's like riders and drivers, whether it's like job seekers and employers,
things like this, buyers and sellers of different kinds.
So beyond finance, it sounded like Kevin was maybe touching on just like general bringing
real world Web2 applications
or maybe functionality.
How do you feel about some of those use cases
beyond some of those just like DeFi
and like financial related use cases?
Yeah, I think, I mean, this is the grand thesis, right?
So I think whether it's Web 2 or Web 3, the common theme here is whether we want to transact with another person, with a blockchain, with liquidity, and so on, so forth.
These transactions are going to be intermediated, right?
It's going to be increasingly intermediate.
is going to be increasingly intermediate.
On Web 2, those transactions are intermediate by agents,
by AI agents, where you essentially
transact through AI agents.
And you accomplish what you want to do through AI agents.
You use bytecoding against some MPCP servers
and give you some agents, and then you transact with them,
and automatic integration, and so on and so forth.
And on Web 2, on Web 3, it's the same thing, right? So you, this is sort of
manifest in MEV protection infrastructure and, you know, transaction supply chain,
increasingly intermediate and then crossing into specific situations as well, where relayed
and solver, intermediate transactions, right. So with that grand picture, you need a counterparty.
You need intermediary, just another word to say counterparty.
And then so, whatever you want to transact with the counterparties, you have to give them some tasks to do, and you have to trust that they can do that for you.
So this is essentially the premise of intent.
You give them what you want to do, and because the reason you want a counterparty is because they can do specific things you can't.
So you cannot tell them specifically what they should do, because then you can just do it yourself.
So you cannot tell them specifically what they should
do because then you can just do it yourself.
They possess skills to do things you cannot,
which means you give them not the algorithm.
You give them the task that's verified by the outcome.
And this is what attempts really are, right?
And then the specific differences in Web 2,
it depends on maybe it's been on reputation, maybe it depends on attestation services.
You know, if it is, you know, for example, eigenlayer is going to set between Web 2 and Web 3, maybe it's cryptonomics and
whereas Web 3, you know, you can use the blockchain infrastructure itself for on-chain verification as part of that outcome verification.
So what I see is this is convergence.
What is web two, web three?
It's how moving towards this general market,
it's a different market structure
when it's more peer to peer,
where it's more discovery based,
where you have abundant of counterparties or
AI agents that can potentially do things for you, and then you can decide who you want to work with
based on some criteria, and then you have to express how you want to check work that is completed.
So the short answer to what you're asking is potentially everything. So it's just depending on
the expressiveness of that system,
it's depending on the verification system
that the agents can provide to you.
And I mean, really from there, just,
you can do Web 2 to Web 3, you can do Web 3 to Web 3,
you can do Web 2 to Web 2 through Web 3.
I mean, this is just i mean that's
the grand uh picture here love that hell yeah that was really that was really helpful for me
um so this is probably the most important question for a lot of people watching it is for me because
um it's hard for me to often like understand the nuance between different implementations of
things that try to
solve similar problems. So we're going to talk about chain abstraction. What are the main
differences between like what intents do versus what chain abstraction is? Can you kind of give
someone like hopefully a good explanation of like the differences, the trade-offs, maybe why one is
better than the other, maybe it's not better than the other, maybe it's more just about trade-offs, maybe why one is better than the other. Maybe it's not better than the other. Maybe it's more just about
trade-offs. So yeah, I'm curious to hear
this from both Kevin and a priori.
whoever wants to take the stab first, I might
ask a priori since he
didn't speak last.
I think chain abstraction, it really depends on who you talk to in terms of like what a definition of chain abstraction is i think the folks at
particle have a very opinionated version of chain abstraction uh where it's something like uh the
user never has to worry about bridging again um so they're able to have all of their assets with one balance for each asset. And they're able to, from a single user face, log in without
necessarily having to have a self-custodial wallet in the traditional sense, like a MetaMask.
They can use their Google account, for instance, and they can then, from that interface trade across chain as if they're just using one chain.
Other people have labeled chain abstraction more as kind of like a movement,
understanding that users should be put in the position to have a great experience
and they shouldn't have to worry about what denomination of ETH is on what chain
when they're moving assets from Arbitrum to base.
Other people have thought of it more as like an application design pattern, like if you look at
Socket. So for instance, the idea being that the application doesn't necessarily need multiple
instances deployed on every chain. They can have their own VM, they can have their own execution
environment, but they do have some settlement ability on multiple chains.
So I think it really depends kind of how you define chain abstraction and what problem you
think you're trying to solve there. But I think intents fit really nicely with it in the sense
that intents just give you this tool to express what you want. And depending on the architecture
of the application or the architecture of the system that you're using and the intermediaries that are solving these intents,
you can get different outcomes based off of what you want.
So I think the two kind of go hand in hand.
But again, it probably depends on how you would define or what your perspective on chain abstraction is.
And I don't think there's an agreed upon clear canonical definition.
Yeah, I will agree i think you know for
change abstraction protocols uh you know if you look at uh you know particle near and then one
balance right these are you know big proponents of change abstraction that's a concept but they have
quite different implementations of what chain of abstraction is.
So I will offer maybe a lot more like detail or technical
sort of practical framework for to understand intent
of chain of abstraction.
I think chain of abstraction protocols, you can think of them,
keep you remote in trouble, right?
So I have an analogy of intent and chain of abstraction where it's remote controlled and crystal controls, right? So I have an analogy of intent and turn abstraction where it's remote controls and crystal balls, right?
So turn abstraction give you remote control, right?
So users can basically use a turn abstraction protocol
to remote control and say,
hey, I want to do some transaction on this other chain.
I want to just do it, right?
So you click a button and then even you're not on that chain,
but then your assets on different chains,
but it's remote control, you can click
and make something happen on a different chain, right?
Whereas what intents are, intents are,
imagine you have crystal balls.
What you're saying is to say, okay,
I want something to happen in the other chain,
but then give me a crystal ball that shows it's already happened.
And once it happens, I can pay you on here.
So one is, so like from systems or architecture point of view,
where it's like, I'm going to push away computation
that happens somewhere else.
Once you say, OK, pull something back,
pull a proof back to me something that's happened.
And then to here, then I can express my logic here.
So that's my mental model,
is remote control and crystal balls.
If you find it interesting, I can also give you a link.
But that's more like an engineering,
like a low-level understanding of the system's explanation of it, right?
So you can do the same thing in both ways,
and they also have protein-cons as well.
One is probably more liquidity-efficient,
the other one is more IB-better, and guarantees and so forth. There are low level things.
Got it. And I'll ask one more question that maybe we've
already touched on here and there a little bit. But it also
has a vein of like what we just spoke of. What are the main
differences between just a traditional bridge
versus what like people say train and chain abstraction is
uh there is a lot there is no clear uh definition of of what chain abstraction is
like you said before, so maybe there's some overlap there.
like you said before so maybe there's some overlap there
Yeah, I can take a step here.
So first of all, there's a message passing protocol.
So those are essentially Oracles.
So they are attestation providers or validators,
as some protocols say, and then they
can tell you some event that's happened on the chain.
And then they will attest and then pass it to another chain B
and then say something happened.
So you can think about that at all.
And then you have these bridge protocols, like you said.
These are use this sort of cross crossing Oracle system to move assets around.
So if we stay on the crossing Oracle side of things,
and then we, again, we use this
chain abstraction versus intent protocols,
then the chain abstraction protocols
essentially use this Oracle to say,
I'm on chain A, right?
And then I'm going to generate a message,
or I'm going to use the Oracle from chain A to chain B.
If a user is on chain A, you want
to use the Oracle from chain A to chain B.
That's kind of chain abstraction protocol.
I mean, they're all a little bit different,
but in the end, that's how they use the Oracle or the bridge,
the underlying iterability protocol.
Now, if you say the user's on chain A
or the money currently is on chain A,
I want to use the Oracle from chain B to chain A,
that's the intent.
That would inevitably lead to the intent
sort of protocol direction.
Because you're trying to, like I said, crystal ball, right?
You're trying to grab something that's happened somewhere
and then you pull them to local to say,
here's the condition that whether
the user leaves the fund or not right so that's the difference and then the traditional when you
talk about crossing bridges the lock and burn bridge it's the most vanilla form of bridges
it's always from a to b right the lock chain as an on chain a and then you put the uh you release
on chain b or a mint you know that's a. Or you go through a liquidity pool in the middle,
and then you swap another token,
and you raise it on Chain B.
That's always from A to B.
So that bridge paradigm is very compatible
with this kind of abstraction sort of mental model.
That's why I used to say some people say
you do not need to bridge anymore, right?
Whereas the other direction is from B to A, you know, from B to A,
use the word code from B to A, that's more of a, you know,
like a market making or market maker, and then you don't bridge assets,
you bridge proofs from chain B to chain A,
and then you express certain logic based on that.
Yeah, so that would be, maybe that's too low level,
but yeah, that's kind of a mental model
that could be helpful here.
No, I think that was helpful for me,
and I'm sorry to pull you off topic
slightly into that,
but that was, I think, helpful.
Yeah, in the practical,
you know, like where does this make a difference
is when you interact with a Bitcoin,
for example,
where you can only have one-way bridge,
one-way sort of,
you know, Oracle that's actually meaningful.
Because on Bitcoin, you cannot verify something
like on a very expensive platform like Ethereum
or other chains.
But reverse direction is OK.
So that is why you can design like really clever systems
that, oh, I want to have one-way bridge,
but how can I design a still system there?
Maybe you can reverse that direction to to make it happen
so in terms of how i would say maybe predicate policies um
have anything to do with how like these intent systems work or how they're connected yeah
kushy do you want
to kind of talk about how predicate kind of fits into all this? Yeah, absolutely. So the way that
I see predicate fitting within the intent system is in two primary ways. So the first is on the
side of the solvers. Solvers that are full solvers or partial solvers or fillers, however they exist in the system,
they often hold liquidity. And that liquidity, that capital, it may have some rules on who can
interact with that capital and how it can be swapped. And so solvers, when they have this
capital, they can set policies on who can use that capital, what types of transactions can be can interact with that capital,
what kind of swaps you can see happening with that capital.
And so it's basically solver side policies
where they can set policies on all of the interactions
that are interacting with their solver or that are being filled by their solver.
And so that's one of the ways.
The second way that I see policies interacting
with intent systems is on the user side. So ultimately, policies are a form of expressivity.
And for users, they can use policies to set rules and constraints and expressions of how they want
their intent to be solved. And so user side policies is basically explaining or slightly explaining
or constraining the way that the intent solution happens. And so both on the solver side and on the
user side, you can set these policies. And then when they interact with each other from both sides,
it becomes a very complex system, but also a very expressive system for all parts of that solving process.
So what would be some of the use cases or examples of when this would be a good
idea to kind of take advantage of? Yeah, absolutely. So it comes back to
bringing regulated capital into like permissionless environments.
When you bring this capital in, there may be policies on who can interact with it, right?
Like if the capital deployer is based in the United States, then they might have laws on who they can actually service liquidity for.
actually service liquidity for. And so you can see those policies being set on this type of capital
where you're limiting the users that can interact with certain jurisdictions, or you're setting
basic AML checks, or maybe even identity verification. Similarly, from a user perspective,
maybe there are specific solvers or specific systems that I trust to fill my intent. And so if I know that those entities
run solvers, then maybe I would only want those solvers to fill my intent. So if you're seeing
how banks interact with each other today, they often do this through bank-to-bank transfers,
or they'll have correspondent banks in the middle that they trust to facilitate transactions between financial institutions.
And so if we ever want these intent systems to service very expressive orders for bank-to-bank
settlements or for cross-border settlements through different financial institutions or
maybe even government bodies, then they might have specific trusted entities that they want
to fill those intents for them because
they know that the capital on that other side is capital that they're comfortable with. And so you
can see that policies end up becoming a very expressive way to decide how different parties
interact with each other and how these orders are ultimately filled on chain.
filled on chain. Got it. Makes sense. So similarly to how I would say predicate is just used in
general, it just applies to this as well, because some of those make sense for a lot of other use
cases in general. Is that right? Exactly. Exactly. Policies basically seamlessly fit into intent
systems. It's just a basket of constraints, got it okay cool well um i think we're
getting close to being finished on time so before we do that is there any big topics big points that
anyone wanted to make before we get into the last question okay good everything everyone seems to be
good if you if you do have something feel free to chime in but um so to wrap this up we're gonna do like a quick rapid fire um what are your spiciest takes
about the intense space and um so i'm gonna just call on someone i'm gonna start with kevin
uh i think everybody's moving towards intense but it but it's just people probably don't know, either intentionally or unintentionally.
I see a lot of new professionals working into this direction, but the form factor is different.
I hope that's spicy enough.
That'll work.
A priori?
I'll say something spicy spicy half-baked um i think intense are the inverse of mev i think they solve a lot of our mev problems not all of it uh because there's
some new specific types that will emerge but yeah i think they solve a lot of it. Super interesting take. Kushi, do you want to chime
in? Yeah, for sure. I think that developers are severely under utilizing the power of what
Intense can be. They're simplifying it a lot to simple RFQ systems, but there's so much that can
be done with Intense. And I feel like today's applications don't do it justice. I don't really have a spicy
take but I can just tell my perspective from someone from the outside looking in that's a
developer that works with a lot of teams that are building similar like products in the sense of like
we're building different infrastructure and application layers but isn't specialized in this.
I would say that number one one, people don't really,
unless you're like deep into this, like know the exact trade-offs and differences between some of
these different approaches, like we mentioned, maybe what chain abstraction is versus what
intents are. That would be one general take. Number two, I feel like there isn't like a clear
winner in terms of like, oh, I want to go build something and I'm going to use Intense.
Like, which product am I going to use?
And then I feel like there's a big opportunity for someone to build like the best in class API or the best in class just product to kind of win that whole space because it's still kind of up in the air.
and maybe like more education around just how to actually build using these different primitives
and like high quality educational material and maybe reference architectures and things like
that to kind of get people excited about the potential here. But that's kind of it. So I
learned a lot. I really appreciate everyone's time and everyone's super busy. And you took an hour
out of your day to come be here to either be on this with me or to watch it so thanks for your time um we're going
to be sharing links and the youtube for all the different uh projects that we kind of talked about
here in the documentation for you to check it out so that's it thanks for everyone uh chiming in
today we'll be back with another infinite layers actually later this week thank you everyone thank you
