Intents in Web3: Present and the Future | Asad Ahmed - Okto | Apriori Apriori - Anoma

[Music] hello everyone up next we will have an intense conversation between Assad from octo and our priori from anoma about intents the current state and the future State and the applications that can be built with them and everything else surrounding the space enjoy test test test it's bright up here yeah so I think let's get started I think uh we'll just start with some introduction so hi I'm Assad I'm the architect at Oto so what we do at Oto we are basically building an end to end chain abstraction stack which allows developers to build one click experiences and simplify users life so AI my name is aiori I work on anoma uh my official title is head of research relations but you could think of me kind of as like Rick ruin um we are building a distributed operating system and the key Insight here is it allows you to abstract over a variety of different uh chains or other computers that are running the anomo protocol and trated as one unified uh execution environment awesome so I think the talk today is all about intents so what we have seen in the last few years that users have been uh focused on interaction or transaction based model because where they know what they want and they're trying very hard to achieve that but we are seeing a shift towards intent based uh interactions from the user site and while building anoma you would have made certain design choices at your site we were curious to know what were the different uh choices of architecture you were considering while building an intent Centric Network and uh what made you arise to the one that you have today yeah that's a great question so I would just caveat and say that we don't have a live in production system yet we do have open source code uh with a client written Elixir so you can check out the node software and run it yourself if you like we also do have a private dead nut for our Builder program so I just want to cave out that uh for folks um I would say there's kind of two components to the enoma protocol there is an offchain component if you want to think about uh in terms of how people use the word onchain and offchain so this would be like a peer-to-peer intent gossip layer where there's counterparty Discovery uh between different agents so you could think of these agents as like solvers as we've called them and by solver I mean more so like a capital S solver so this role could Encompass something like computational search it could Encompass uh routing intents to the right application for solvers it could Encompass uh providing liquidity or selecting the optimal batch of intents to batch uh for ordering and execution and so the second part of the protocol is settlement uh and so this settlement can happen on any blockchain that is running the enoma protocol so this could be like ethereum mainchain uh an ethereum rollup or it could also be uh another chain that is running the nominative uh software stack itself awesome so to just understand a bit uh deeper on this one uh when you talk about intents and the uh the level of intents that these followers can do uh what sort of applications do you see people or sort of intents that is anoma best fit for solving for whereas uh certain use cases where anoma might be an Overkill uh or as a solver Network might be an Overkill to solve for those intents yeah that's a really good question I think um one of the nice things about the emergence of intents and shout out to all the people that have really been putting in a lot of work uh whether that's uh the folks at across uh the folks at near other folks that are are working on this cow swap Etc um one of the nice things about intents is that they allow the user to no longer have to worry about how to get what they want but just to express what it is that they want uh and this is a bit of a mindset shift for a lot of Legacy web 3 users but it's a necessary one uh if we're actually going to expand and hit some of this total addressable Market that we all uh seem to be thinking about so to answer your question a little bit more specifically um the enoma protocol is quite General so um it could be any kind of intent um it could be something like a intent for uh swap so you could think of this like a limit order it could be an intent application that has some custom uh ordering uh in variance so you have to run a particular type of auction uh in order intents in a specific type of way so that could be one use case which is uh it's really well suited for another could be um for something like a messaging protocol or something like a crowdfunding protocol or any other kind of like conditional commitment uh that you want to make that requires some kind of gossiping around and finding um a counterparty intents while they are really well understood in the inop sense in terms of going from let's say arbit from to base um they are actually a lot more useful in the scenarios where you're looking for like ring trades or Coincidence of wants uh ways to aggregate offset different sources of liquidity um and find different counterparties so they're really most useful I would say in uh multi-party applications so one of the things that we were considering while building Oto is that uh for us we took a different approach of instead of building a generic intent solver we started building our own solver Network which works on Primitives so this Primitives are called blocks and these are basically like Lego blocks that allows users to operate on different intents like trade swap uh interact with a certain protocol like hyper liquid for that matter and they can and the protocol is the solver is fairly extendable so that people can combine bunch of blocks together to build their own composable flows and build on top of it so this allows uh for us in our experience what we have seen is a lot of users are doing a lot of repetitive intents for example a game f application might might be just doing bunch of nft transfers over and over again or might be having like a delayed settlement when the game gets over so such use cases is uh more life cycle oriented where you have you have to ensure the transition goes through so we track metrices like lower latency lower computational resource so we're curious to know about when we talk about intents build on top of aoma um thinking about liquidity intents is what 7683 and other fls are also solving for uh what is spefic spefic intents that you feel that um apart from liquidity what are the other things that you feel that is very cool to build on top of an yeah I think um in terms of potentially stacking multiple actions on top of each other I mean I think this is something that people have been trying to play with for the last couple years whether they've called it like zkl or AI agents or something like this um and there's also different flavors of this in account abstraction where you have different types of meta transactions um there are different systems in place today where you might craft a meta transaction to let's say um take out a flash loan uh leverage Loop your uh die and then deposit it in a vault um these are the types of use cases which I think are kind of interesting where you can maybe do a swap and then deposit um there are some systems actually in live in production today shout out to Enzo um they make it actually really easy to integrate with your API and you could actually call that API and do something like um Do a Swap and then deposit it in in a contract let's just say so I think the actions where you have multiple things stacked on top of each other could be very interesting given that everybody has some kind of unique preference and the way that users use um defi today very often is they'll do go to one destination one front end do one thing go to the next destination next front end do the next thing uh and then they might even do a third thing and being able to extract that away and also do it with one signature and not have to have this workflow where you have an approved signature um and then a transaction signature where often times the user doesn't even know what they're signing I think in these these particular examples they could be interesting but I have more specific app examples if you're interested so I think one of the applications that we have been built on top of us is uh say uh game fire application or say something which is very useful and live today as well in Octo app is people might have liquidity across different uh chains say Solana AP whatnot and suddenly hyper liquid is something it was popping up and people were just wanted to trade on hyper liquid so one of the intents that we enabled was why don't we aggregate liquidity from different chains deposit in hyper liquid and what we requested them was just give us how much usdc worth of trade you want to make on hyper liquid and let us take care of the flow and the gas and all the life cycle management it goes behind it to ensure that user is able to make a oneclick trade with his balance spread across multiple chains I think that was pretty useful for the users because they had the intent they don't need to worry about how to actually use a protocol but we enable them to use a protocol so I think that is pretty powerful from a user but as well as a developer perspective definitely um moving on to the workflows that we just talked about stacking intents making complicated workflows happen um it seems very useful for the end user but it is equally uh difficult for a solver to come across to make those things happen and especially when we have a network like these uh verifiability becomes a true challenge there where we have to verify that things have went through as it was intended by the user so um one of the things that we have been grappling inside our in our company as well is to how do we make solvers truly verifiable and ZK might be one way of doing things but it's not there yet in terms of the resources that it consumes today to prove what you have done is right uh we resorted to make it a te based approach where we verify that the solver has done the right computation as per the Primitive that we have already defined so because we have done the Primitive we have audited those Primitives we just want to ensure that it has been done in a non-corrupt non- advisal secure computation environment so we can trust it has come across the right payloads so curious to know what verifiability at um at your side yeah that's a great question um I'd say I'll try to explain how we're thinking about solving because I think that might be helpful so today um when people say solving in ethereum land really what they mean is either somebody who is doing the onchain routing um finding the best path optimal path to liquidity so this could be something like a DEX aggregator or something like um propeller swap um or they mean maybe like a market maker that is actually taking on in in in inventory risk and also pricing opportunities with an order book uh with liquidity that might be both on binance but on chain uh or in uh some third place and then uh you also have the notion of a relayer or a filler and this would be somebody usually that takes on inventory risk of the same token but they might hold it across different chains and so when you're doing those routes from arbitrum to base uh if they become very popular they need to rebalance um and and get their tokens on the right change so they can then compete and fulfill uh the user uh intent in the next auction so how we think about solvers is very much in this decompositional way and so you you have somebody that's uh routing intents you'll have somebody who's doing computational search you'll have somebody that's providing liquidity and then you'll have somebody who's selecting that that that's batch of intents uh depending on the invariance of the auction and so in this process this could be logically one entity right this could be like a coinbase mega solver or this actually could be different entities that are competing um for these different opportunities if the economics make sense for them and I think we still have a lot to prove in terms of the economics of intents so so if you think about solvers and just say it's this one bucket position um you can think about two things I that we've spent a lot of time on we've looked at private solving uh We've also looked at verifiability so for private solving we've done some research into NPC uh also we've looked at witness encryption as well and then in terms of verifiability uh We've looked at tees and we've also built out the uh resource machine with a backend uh with a Cairo zvm but then also we have one that we're working on with a risk z ckvm uh and this would be for verifying an OM formatted intents uh on a particular chain let's just say so you could verify that the solvers do actually meet the uh invariance of the intents um by having some standardized approach uh so that could be with some abstraction that somebody built or it could be with the enoma resource machine uh that's deployed as a set of contracts on maybe ethereum AET ethereum rollups and then in the future could be other places as well but were more so focused on ethereum so when we talk about say a user intending to have an action a and suppose the solver ended up doing B so where does the verifiability come into play so for us we verify whether it really created the payload for a or not because it's Primitives but when it is a collaboration of solvers coming together trying to solve something it may have uh missed a slipage or it has maybe missed some something off a mark like or maybe did some wrong token for chance so how do you exactly match A to B whether the intent has been verified or sold or not so um intense you could think of like the way that they are actually represented as partial transactions so in order to match these partial transactions you actually have to create a proof uh so in that process of making a proof uh you can then verify that those partial transactions were matched and adhered to the invariants or the constraints so as a user when they're defining an intent onto the network they have to actually Define each of the steps uh and verifying that partial proof against it so the user um could produce uh a proof client side uh and then the solver could come with a matching partial transaction and then once as soon as whether it's like a pre-confirmation system that the solver could issue if they're offering their own liquidity the server uh the user's client would update and tell them hey we can verify that uh the solver did match this intent and here's the accompanying uh hash of the zero knowledge proof um or you could wait for verification on chain so you could wait for an ethereum block number uh at a particular height and then you could see that that proof uh was verified by the verifier contract awesome so this way you could actually um it's up to the followers if they want to have faster verification they have to pay for it otherwise you can wait for the full confirmation to happen yeah that's right this a neat approach to take uh going through the same flows I think when a user have an intention to perform say take withdrawal from a vault or the amount that I have staged move it across some other chain and deposit some other Vault this could be the fairly intense that people can build on top of it like this could be the workflow that people are building um how do you see the role of uh assets and access to wallets uh in this uh realm because uh resource lock is what people are talking about right now when they're talking about cross liquidity intents but when we actually want a solver to act upon some microtransactions that they want to do which is say which can only be done via the same wallet of the user so how do you consider this uh access to assets or access to wallets by a solver for a given user yeah you could do a couple things um you could either think of an intent like as a binding conditional commitment so this would kind of be like a resource lock so you could just delegate to a resource lock account and then a solver could know that you're not going to equivocate uh and I think that's probably at least in the near term the most practical example that we'll see you could also delegate to like say a permission set of solvers for a particular application or maybe they are a solare that specializes in like 10 applications that you like to use let's just say maybe there's some economies of scale and solving for all of them and maybe in in that it's a session where you delegate permissions for I don't know 30 minutes or something in order to execute your intent at the optimal rate let's say it's a swap or maybe you're trying to get the best lending rate possible or something like this or maybe you just want an average price fill at like a t like a particular Tech um so yeah I I think there's a couple different approaches you could take there I think you uh briefly mentioned about session delegation and time based limits as well I think this is something that uh we uh spent our hard work for the past two years building out a network that allows users to have delegated access over EAS so we have like an NPC Network which uh you can have like a session key and this session key is time bounded and dollar bounded so you can just say that up to $1,000 it's accessible across all the networks or a defined networks that you users preference about it and up to say 2 days or 30 minutes they can just give a session key to a given uh solver and then the solver can act upon it basically so I see we have some synergies out there definitely I mean if you think about these problems long enough they a lot of them lead to the same roads I also think too um one of the nice benefits of intent is again like really just focusing on what the user wants and there's a lot of different ways that wallets can help facilitate this and I think we're going to see probably somewhat of an arms race for who can build the best comprehensive wallet um that integrates things like natural language but also oneclick uh intense as well and I think that space there is wide open I don't think anybody's won that Marketplace yet awesome so I think uh we are about time I think the party notes would be that you had a private Dev devet up so would love to see uh in your experience what was the most bang on dap that you see build on devet which maybe if they wouldn't have been able to build without anoma and what do you see the future of uh intent Centric architecture sure so I'll shout out um it seem that's building on the private devet called any type um and they're building a chat application um and they are trying to focus primarily on endtoend encryption um and also starting with a very local market uh in Berlin and then kind of building out from there so trying to find product Market fit um and then scaling there's another team uh myell that's working on this concept of like a transferable account so you could like transfer portfolio of assets across different chains uh using intents so I think those are two cool uh projects awesome so we have uh on the similar lines of chat application we have something called Stan so Stan is the southeast Asia's largest fan engagement platform so they have built out completely an intent based application to engage with their fans in different games and different nfts form so I think that is a pretty cool use case that we have seen uh having product Market fit for InCentric applications awesome definitely