# Exploring various approaches to achieve effective decentralization for Intent-Based protocols

- Speakers: [Mounir Benchemled](https://streameth.org/speakers/mounir-benchemled)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-16
- Duration: 08:50
- Watch: https://streameth.org/watch/67385ce81b0f83434dae2a14

## Description

Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.

## About the speakers

### Mounir Benchemled

Founder at ParaSwap and Laita Labs


## Transcript

Fees, execution speed, and execution guarantees. So welcome to the stage, Munir. Everyone. Okay. Everyone? Everyone? Okay. I'm glad to be here. It seems like this is an intense morning, and a very intense one. Sam Munir from Lata Labs. We're known for building PowerSwap, a five-year-old protocol, and recently Portugus, that allowed us to launch parasoft delta so the first time paraswap is now in the intent space and and it's a great thing um so i guess you heard a lot about intense i believe it's now uh something that is second nature uh so i'm gonna jump directly to what are intense in the context of trading on chain. So it's basically one way of expressing an outcome without describing the details of that outcome in simple terms. So if you are a user, you want to swap a token A for a B, well, what you do, you sign an order or an intent. You send it to a backend API in general, like 99.99 of the time. But behind the scenes, there are what you call solvers, resolvers, market makers, agents, how we call them, that will compete for user flow and will bid on an auction. And the best bidder is going to be the winner. So we have two entities here. We have the user who have a desire, like I want to swap token A for B. We have solvers, agents, you name it, competing for user flow. And as I said, there is an API in between that does the whole work. Users still are mastering their key. The system is like work as an EDFI protocol, but the thing is that API, which acts as a central point of failure, if it stops working, the whole system is not useful, is not working at all. So that's a problem. And this is what we're working on in Porticus in trying to create an alternative. But the challenge is, and what we are also proposing, is a way so that we can still preserve the user experience, because if we introduce a fancy decentralized layer, let's say an app chain, well, we won't ask users now to interact with yet and yet another chain. That's not going to be great. It's not going to be good for UX. So the thing is, we keep that backend API, that centralized back-end API. But the thing is, now it's optional. So you can use it. You can run it yourself. So the user and the relayer can be the same thing. And that allows us to still give the user exactly the same experience, but still having a neutral network that can run this system of intent interactions. So the system looks like this. We have on the top left the user interaction. So it means user wants to do action XYZ. I talked about swap, but it can be I want to provide liquidity to Uniswap. I want to do a cross-chain liquidity providing on another AMM, or maybe I want to deposit my USDC on Aave and earn yield on another chain, or maybe completely abstracting that chain. I use a relayer. I can be my own relayer. It can run literally on my laptop. So I publish the auction or my intents on the network. We have an auction manager. This is the heart of the system that you're going to zoom into. The rest of the process is the same. We have a competition. The winner is going to win. Get to execute the user trade. Rest is not new. So we have multiple ways for achieving that. Unfortunately, we don't have a lot of time to get really deep. But there is the possibility of running the auction manager on an app chain. Something that's not new, we have like DYDX who are running the whole order book and the matching engine on an app chain. It's working well. The big limitation here is privacy, because we may be pre-licking MEV on the user side, but also on the agent side, on the solver side, like all the bits would be public. There are solutions yet, but here we get into more complexity, like commit and reveal schemes that can be a bit challenging as well, but it's one of the approaches. The other one is one I like a lot, is the TE, maybe, or MPC, or a combination of both, where we can have a bunch of nodes who are running on, if we go with TE, running on a trusted execution environment, so it means like a closed environment, a private environment, so we solve the privacy issue of like pre-licking of MEV, and the issue with TE is we rely on a specialized hardware, issue with MPC is a bit slower than TE. So maybe a combination of both could do the job. It's something that's still a work in progress or a research in progress. The other one is like the holy grail for computing on encrypted data that can be a perfect solution, but unfortunately, this is FHE, a full homomorphic encryption, where the nodes can compute on data fully blindly without having any idea of what's inside and getting to select, in this case, select the winning agents based on the best bidder in terms of price, gas, you name it. But the problem is FHE latency is not acceptable yet. It's way, way too slow. It can work on a batch computations and not in real time, where it's very important in the case of trading on chain and many other use cases. So that's maybe we still maybe a few years ahead. There is some work on building some ASICs, again, specialized hardware, which would become a limitation. But still, yeah, this could be the best solution at some point. But we're still a few years ahead. Thank you, guys. That's all I had. Happy to answer any questions. Thank you, Munir. All right. We have time for questions. Raise your hand if you want to ask one. You've been amazing in terms of asking questions so far. Let's keep it up. Let's keep going. Yes. All right. One, two, three. Is there a specific service which solves this intent problem usable by many DEXs, cross-chain swaps, or each build their own intent solvers? You mean on the product side or on the agent side? On the product side. Does it make sense to have a scalable product here, which is serving this intent services for many, many cross chain solutions? Yeah, for cross chain, I think it's becoming more and more like a normal thing between codes. So we're seeing more and more protocols normalizing cross-chain interactions. So if that's the question, I would say that's just a matter of time. We're not far away from having, making cross-chain is like the normal thing to do and thinking beyond cross-chain. If it's a question about having generalized purpose intents, it's something I believe less that it's going to be the case, because the complexity of each protocols makes them so different to have a general purpose solving mechanism. So if that's the question, I hope I answered. All right. Time for another question over there. So as someone who has not explored Intents yet, I want to ask how to participate as an agent or a solver in this network. Like, what exactly is a solver? Is it a piece of code or like a market maker bidding for the prices or such? Yeah, it's definitely too broad. It's always a piece of code anyways. Like someone has to write a code that will answer a user intent between code, like user desire to do something. The simplest case is I want to swap token A for B. And the one who provides the best price is going to be like coding and competing with others. Like you may run a fancy algorithm and connect it to many exchanges, the Texas buyer, of course, and running this algorithm that will answer the user intent. But it can be other things. Like nobody has a integration of Aave that will let any user put USDC cross-chain on another chain and earn a better APY. That's also a use case that can be fulfilled by an agent. All right.