Reimagining the AMM with 1inch Aqua | Tanner Moore at ETHGlobal Tokyo 2026

Hello everyone. Let's get started. My name is Tanner. I'm a Technical Account Manager at 1inch, and today we're going to talk about reimagining AMM with 1inch Fusion. So, today we will discuss the current DEX exchange landscape.

What is Fusion and how it is reimagining AMM design. Tools we built to simplify Fusion development. Going beyond conventional AMMs with 1inch Fusion. Benefits for liquidity providers, traders, and developers. Finally, we will briefly touch on our 1inch bounty programs .

So let's get started. We will look at an example of how we are all used to perceiving AMM today, using the simple example of Bob, a liquidity provider who wants to generate income from his Ether and USDC. Eventually, he will find a DEX where he can deposit his funds. Let's say this is a wrapped Ether/USDC pool on Uniswap V2. He will deposit his Ether and USDC into it.

Now the Ether and USDC pool will hold his funds, and he will be able to withdraw them later. On the other side, another person will appear—a trader. Let's call her Alice; she has Ether, she will find this pool and say, "Okay, I want to exchange my Ether for his USDC." Or on a USDC pool. She sends her Ether to the pool.

She receives USDC and remains satisfied. Bob also receives a small amount of USDC as a commission, which was actually his main goal when depositing funds - to depositing funds - to generate income. And Bob is happy too. But, as we all know, there are many more pools and many more DEXs than the one in our example. There's Curve with its liquidity providers, SushiSwap with its own, and this list would be too long if we tried to cover everything.

At the beginning of the DeFi era, a familiar problem arose: where exactly should Alice go to exchange these tokens? And, as many of you know, since you've been here a long time, this issue was solved many years ago with the help of aggregators. 1inch is aggregators. 1inch is one of the leading aggregators. We also have our competitors.

This solved the problem: Alice simply goes to the interface, some kind of aggregator, and all the complexity of the process disappears, she no longer needs to worry about anything . She simply gets the best rate to exchange her tokens and is left very satisfied. But, besides the fact that liquidity in this case just looks attractive to Alice, the reality is that fragmentation actually accelerated because of this abstraction, because people didn't have to solve the problem of pooling liquidity, because aggregators were just a layer on top, and it just postponed that problem for a very, very long time, for years to come. Um, most of these most of these DEXs, not all, but most of them have re-implemented very similar storage, very similar accounting, similar calculations. Sometimes they just cloned contracts, made small changes to them, called them tested, and then put them into production, and that led to a lot of crashes and other problems in the future, and fragmentation, as I mentioned earlier, continued to grow along with it grow along with it .

So, today we will talk about the shortcomings of this system not from the perspective of traders, but from the perspective of liquidity providers (LPs). So when you are a liquidity provider, choosing where to escrow is actually very, very tedious. You need to actually look at all the different DEX exchanges that you've heard about and evaluate that you've heard about and evaluate , you know, their security , you know, their security , how long they've been around, what audits they have, and you should try to pick the place with the best profitability best profitability , considering all these other factors. Um, next point— next point— participating as a liquidity provider has a fairly high opportunity cost. If Bob decides he wants to place his funds on Uniswap, he can no longer earn income on Dodo, Curve, or any other DEX exchange available to him.

And if he had a pair like if he had a pair like Aave-Ether, he would no longer have access to the governance of the DAO, because many old governance systems simply check your wallet balance, and that's how they determine your voting weight if you participate in governance matters. Third, moving funds is generally associated with high difficulties. Um, if Bob decides to work with Uniswap, he'll probably want to go to their site and check that the contracts he's interacting with are indeed the ones they publish. He will probably want to verify that the transaction does what he expects with some kind of simulator like Tenderly, and he should definitely check the call data on his hardware wallet before signing the transaction signing the transaction . Once he does all this , the assets will be in Uniswap, and if he wants to withdraw them from there, he will have to do everything in reverse order, and then start the whole process again on the next DEX he moves to.

Lots of checks, lots of tedious work, and you have to be very careful not to lose your funds. And, of course, repeat it every time it happens. happens. Fourth, new projects have only steadily increased this fragmentation, making it more difficult for LPs to operate, and they have even significantly stimulated it through accelerated pools and token issuance, trying to further divide and fragment liquidity. So 1inch analyzed the existing system that we all know today, where on one side is the trader, on the other is the LP, and in the middle is the AMM, and we asked: "How do we create a system that fits the mental model of the AMM that everyone has, but at the same time directly connects traders to the LP, to both transfer funds to the LP, and to collect the desired tokens from the LP?"

That's how 1inch Aqua was born. So let's talk about 1inch Aqua. Liquidity remains in LP wallets. You no longer need to deposit it into another contract, where the funds simply sit around while you receive commissions, and then withdraw them later. It just stays in your wallet all the time.

The liquidity you participate with in Aqua is not tied to any specific trading strategy. It is rather reserved, but only formally, at the signature level, and not physically attached to it. And the calculations from the user's perspective remain atomic. This means that people interacting with AMM on Aqua interacting with AMM on Aqua will have a very similar experience to what similar experience to what they are already used to: you can simply go to the block explorer and see a transaction where their token leaves the wallet and the one they received received comes back. Now let's talk about architecture.

Aqua has three main components. These are Aqua router, Aqua apps and strategies. Aqua router is simply a smart router is simply a smart contract that is responsible for three key functions. LP registration, i.e.

which wallets participate in Aqua; balances— participate in Aqua; balances— how much of each token is allocated for each Aqua strategy in the system; and exchange settlements. So, this is a mechanism that has permission to take funds from the wallet on behalf of the LP and transfer them to someone who interacts with the system. The next component The next component is Aqua apps. So, this is the actual implementation of the swap logic. You can imagine constant product, concentrated liquidity, stable swap, and much more.

They are all implemented as Aqua applications within the system, and we will move on to the next part— next part— strategies, i.e., the use of these Aqua use of these Aqua applications. So, this is the obligation of liquidity providers (LPs) towards them. If you have a constant product and you want to implement it with wrapped Ether and USDC, for example 1 Ether and 1500 USDC, this will be the actual strategy actual strategy tied to this Aqua add-on.

Another example would be a stable swap. You have USDT, USDS, and 1000 units of each. So if we go back to the previous example where we looked at a very simple LP position and analyze it from Aqua's perspective, hopefully it will become clearer. So now from Bob's perspective as a liquidity provider, there is an Aqua there is an Aqua router and an Aqua router and an Aqua AMM application with a constant product between him and Alice. The first thing Bob will do is The first thing Bob will do is approve or allow the Aqua allow the Aqua router to access his funds.

And he will summon Aqua. ship. This will contain all the information about all the information about which tokens it wants to provide, in what quantity, and all of this will be registered in the state of the Aqua the state of the Aqua router contract. As part of this registration, the system will generate an event that will be picked up by the indexer will be picked up by the indexer . Anyone can run an indexer run an indexer , but we will of course have our own official indexer.

It will also track all the state: Bob's registration state: Bob's registration , his tokens, and his balance. Then, when a trader comes in, he can get this information from the indexer. Suppose Alice gets this information from the indexer and wants to get a quote get a quote to see if she wants to trade here. It will go to the Aqua AMM application and pass all the information about Bob obtained from the indexer. If she is satisfied with what she sees, she will send her broadcast to this contract.

It will verify Bob's commitment via the Aqua via the Aqua router, where he actually registered his position. If the verification is successful, he will send her ether to Bob's wallet. He will withdraw the USDC and give them to Alice. Alice gets her tokens, Bob gets his commission. There is a system that is just as effective, except that the funds do not actually leave Bob's wallet until the transaction is completed.

So, it's quite complicated, but what do we actually get out of it ? Well, now liquidity providers can send and sell staked tokens whenever they want tokens whenever they want . They do not need to withdraw funds from the contract in advance. They don't need to worry about permission to do this. They can just sell them.

They can send them, they can send them to a centralized exchange whenever they want exchange whenever they want . There are absolutely no restrictions here. Now they can participate in governance again, as voting rights dependent on wallet balance now see the balance inside your wallet. And, most importantly, liquidity providers can reuse these tokens for other Aqua applications and strategies. And this is very important, which we will talk about next.

So, let's assume that Bob had more than just Ether and USDC. Let's say he also had Aave and Tether in his wallet. And let's assume that each of them had a thousand dollars. So, the total liquidity is four thousand dollars. Bob can go to the Aqua router and do what we did earlier in the previous example, saying, " example, saying, " Hey, I have a thousand dollars in Ether and a thousand dollars in USDC, and I want to invest them in a perpetual product strategy."

So that's two thousand dollars. He can do the same with the entire thousand dollars in Ether and the thousand dollars in Aave. And he can do it a third time with all of the thousand dollars in Ether and the thousand dollars in Tether. So now, even though his actual liquidity is $4,000, he has an effective liquidity of $6,000. On the other hand, Alice can come in and say, "Hey come in and say, "Hey , I want to exchange my USDC for Ether against Bob's position."

Trader Tony can come in with his Aave and exchange it for Ether against the same wallet, Bob's wallet wallet, Bob's wallet . And the third trader, Craig, could come with USDT or Tether. I use them interchangeably all the time, but they are the same thing. And he can also exchange it for Ether. Now you can probably guess that if two big players came at the same time and extracted all the Ether from Bob's wallet, one of them would surely fail, right?

And the answer is yes. I mean, he does n't actually have more than a thousand dollars on the air, but if someone comes in and takes all that out, and then another person comes in, yeah, that's going to cause a crash. In practice, this is unlikely to happen often to happen often , as our indexer will check balances and protect against this, but it will still happen sometimes. But we don't think this will become such a big problem that it will turn into a significant negative for the ecosystem. So, we talked about a permanent product for the Aqua app, but we for the Aqua app, but we could obviously do concentrated liquidity as an Aqua app.

We could do a stable swap like the Aqua app. There are many Aqua apps, each for different types of trading strategies. And when we started thinking about all these Aqua applications that were going to be developed, we realized that there was going to be a lot of duplication with custody, withdrawals, all this boilerplate code that is not essentially pricing curves not essentially pricing curves . So we decided to release at the same time what we call SwapVM, which itself is also an Aqua application. This will try to abstract away all that boilerplate code so people can just focus on the sharing strategies themselves .

So, SwapVM can be considered simply a system of building blocks for swapping platforms. You can think of the price curve as a building block, maybe add limits if you want to do over-the-counter trading or some kind of limit orders, commissions of course because you want to incentivize people who use your trading strategy, and maybe deadlines if you want it to only last a certain amount of time. So if we look at the left side, don't try to read all of this code. This is just an example that I will now consider. If you look at the left side, you'll see a very simple implementation of a persistent product inside Aqua on Solidity, right?

Because Aqua applications are contracts that you deploy on Ethereum. And here would be the very familiar things you would expect, like swap exact in, swap exact out, implemented in the traditional way as an Aqua application on Solidity. And on the right side you'll see what it would look like if you did the same thing on the Swap VM. The first thing you'll notice, besides how small it is, is that it's also written in JavaScript. And that's because you're no longer deploying smart no longer deploying smart contracts, you're actually generating bytecode for the Swap VM, because it's actually the Swap VM.

So here you just initialize the constructor. You say, for example, that you want to have a commission. I would like to use XYC swap, which is just a permanent product. Then you call build and get the bytecode for the sharing strategy you want to provide to others. So these building blocks " building blocks " under the hood" are actually opcodes.

Hmm, there's one more thing to pay attention to, these are so-called extrusions. Perhaps your exchange strategy needs something more than just being isolated in a single contract. An example of when this is done as an extrusion is if you want to, for example, use oracle data as part of your strategy. Another important thing to note is that note is that we encourage participants in this hackathon to write their own opcodes. This will obviously require you to redeploy the Swap VM contract.

This is perfectly acceptable for a hackathon. One very important note: the Swap VM contract has the maximum size allowed in Ethereum. So you will have to remove the opcodes you don't use to insert new ones. Don't feel like it's mandatory or anything, it's just encouraged if you want to get creative and go beyond what we provide with Sorbian today. Next, let's talk about how Aqua can go beyond just AMM.

Everything we've talked about so far is just AMM, but it doesn't have to be that way. Our Aqua bounties have been featured at probably four or five hackathons, and people have been creating prediction markets, privacy pools, and flash privacy pools, and flash loans on Aqua. We've seen a lot of really creative things, so we want to emphasize that you can do it too can do it too . So, if we go back to our previous example with the Aqua example with the Aqua app based on a permanent product, let's change it a little bit to make it an Aqua app for flash loans. So, on the bottom right, where the Aqua app used to be Aqua app used to be , we now have flash , we now have flash loans, and we can imagine that Bob has committed to a strategy where he provides USDC to that same flash loan app.

Alice arrives, she sends the loan amount and the payload for the flash loan. This then goes to the Aqua router, and it checks Bob's commitments made earlier. Once everything is verified, it sends the USDC to Aqua, a sends the USDC to Aqua, a flash flash loan app, executes that payload payload , and then returns the USDC to Bob’s wallet along with some fee, which Alice also paid. So, we briefly discussed flash discussed flash loans. We talked a lot about constant product throughout most of the presentation, but this can obviously go far beyond, for example, to stable swaps with three or four coins inside.

And the most important part of this ecosystem is that all of this can exist in parallel, using the same funds from a single wallet. So, what impact does this have on the larger DeFi market? Well larger DeFi market? Well , for liquidity providers, this means higher utilization of funds or simply better profitability. For DeFi users, this means better prices overall for DeFi overall for DeFi applications.

And for developers, this means a faster path to product and users in general users in general , because the more people use this ecosystem for DeFi, the easier it will be to draw attention to your applications and get people to start using them faster. So, finally, we'll briefly talk about rewards. We have $5,000 total to build a brand new Aqua app on 1inch. That's $2,500 for first place, $1,500 for second, and $1,000 for third. And our second direction our second direction is to expand the existing application to support Aqua, and here the total prize pool is $2,000: $ 1,500 for first place and $ 500 for second.

So, that's all from me. This is a QR code that will take you directly to our rewards page. You can easily find it on the EthGlobal website, but if you want to get it now, it will direct you there. And that's all from me. So thank you, guys.

Um, I think we have a few minutes for questions. Yes, if anyone has any questions, I'd be happy to answer. Yes happy to answer. Yes , there in the back row , there in the back row . Um, you can interact with a deployed Aqua application as a subquery.

There shouldn't be any problems with this. Is this, is this roughly what you're thinking? Can I simply call it from any call that already exists inside the contract? Like a subquery inside a call inside your contract? Yes, but usually Uniswap requires an off-chain signature, right?

Please repeat again. Does Aqua VM need to have a signature from some off- line database? Uh, you mean for for commitments? Like , uh...Yeah, yeah, I think so.

Yes. Um, I...I'll try to answer that better. You can explain it to me just in the hallway, and then maybe we can talk about it in more detail so I can better understand what you're trying to build. Yes.

Sorry. Any more questions? Yes. You asked if it is possible to use custom opcodes in soft VM? Yes, you can.

The contract itself has already reached the maximum size allowed by Ethereum. So find the opcodes you're not going to use, remove them, and that will free up space for the custom opcodes you create. Okay, cool. Thanks, guys.