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

My name is Tanner. I'm a Technical Account Technical Account Manager at 1inch, and today we'll be looking at a presentation about reimagining AMM with 1inch Aqua. So, let's begin. We'll start with the current decentralized exchange landscape as everyone knows it today. Then we'll move on to what Aqua is and how it redefines AMM design.

Next, we'll talk about the tools we've created to simplify development on Aqua. After that, we will move on to expanding this technology beyond just AMMs. We will discuss the benefits for liquidity providers, traders, and developers. And finally, let's briefly talk about the bounty for this hackathon. So, let's start with an example.

We have Bob. He is a liquidity provider, also known as an LP, and he wants to generate income from his Ether and USDC. It will look for different protocols where this pair can be entered, and let's say it stops at the wrapped Ether and USDC pair in Uniswap V2. He will put his Ether and USDC into this contract, they will be stored there, and he will receive some kind of redemption coupon, well, since it is V2, it will be ERC-20 if I remember correctly. He will be able to withdraw them later, and hopes to generate income from this over time as people start using the pool.

So, let's say Alice, a trader, comes along, she eventually finds his pool and wants to exchange her Ether for USDC in that pool. She will send her Ether into this contract. She will receive her USDC, which will make her happy, and Bob will also receive a small amount of USDC from this transaction as a fee, and he will be happy too. So, both parties get the desired tokens. One party receives income, and the other exchanges its tokens.

But of course, there are many more liquidity providers and protocols than just Uniswap, right? There's Curve with its LPs, there's SushiSwap with its LPs, and the list goes on and on. And the initial problem, if we recall the DeFi summer of 2020 and perhaps a little earlier, in 2019, was a very complex issue: Alice did not know where she should best exchange her tokens. And as many of you know, this was solved quite early on in the form of an aggregator. 1inch is one of the first aggregators that still remains a leader in this field, and this essentially solved the problem for Alice.

She simply goes to 1inch or another aggregator and uses the interface. The aggregator takes on all the complexity of finding the optimal place to exchange tokens, everything becomes abstract, and this is very convenient for Alice. So, for her, liquidity in the network looks holistic. If one of the indexers like 1inch added this pool, she sees it in its most optimized form. But in reality, this only accelerated fragmentation in the network, as it became a temporary solution to the biggest problem at the time— problem at the time— how to make liquidity available to everyone through dynamic routing.

And while all this was evolving, implementations of storage, accounting, and computation were constantly being rewritten, forked, or changed, creating chaos that we had never truly encountered. So I want to talk about the shortcomings from the perspective of liquidity providers (LPs)—a group of users whose interests have often been ignored in DeFi for years. First, choosing where to place liquidity as an LP is a real headache. Let's say I'm Bob, I have USDC and Ether, and I want to make a profit, but I'm faced with a difficult task—choosing a protocol to inject liquidity inject liquidity . There are also many opportunity costs in providing liquidity in this way.

If Bob invests his liquidity in Uniswap, he loses the opportunity to earn income in any other competing protocol. So he becomes completely dependent on the chosen protocol on which he intends to earn. And if he had a token pair like AAVE/USDC or AAVE/Ether instead of USDC/ or AAVE/Ether instead of USDC/ Ether, he also loses the right to vote in the DAO management—many protocols previously took into account the token balance in your wallet for voting. So, if you transfer tokens to another wallet, you also lose the opportunity to participate in management. The next problem is that problem is that moving funds for liquidity providers is usually associated with high difficulties.

So, if you decide to invest in Uniswap, you will have to do a lot of due diligence. You must make sure must make sure that the website you are using is correct. You must ensure must ensure that the contracts you are depositing funds into are correct. You need to check the call data that is being subscribed for correctness. And ideally, if you care a lot about security, you'll even use a simulator like Tenderly to check that the transaction is actually doing exactly what you expect.

Once you have done all this, you have a position in that protocol, but if you want to change the protocol to generate revenue elsewhere, you first need to withdraw those funds, which requires caution and verification of all transactions. And then for any subsequent protocol, you will have to go through the same process again: checking the website, contracts, call data, simulations, etc. And every time you do an exchange, you have all this extra effort to do everything properly so that you don't risk giving your funds to scammers, through DNS hijacking or anything like that. And finally, new projects are constantly reinforcing this fragmentation. Moreover, they materially incentivized this through the issuance of their protocol tokens through some form of accelerated pools.

So, each new protocol only made this problem worse, and they kept trying to divide the pie into smaller and smaller pieces. So if we look at this design that we talked about earlier, with the AMM in the middle, holding the funds and making or helping to make transactions , that's what we focused on when we developed Aqua. We wanted to ask the question: is there a way to get the AMM experience that everyone is already familiar with, but allow funds to go directly from the trader to the LP, and LP funds to go directly back to the trader? And this is where Aqua comes in. So, we'll talk about that later.

So in the 1inch Aqua protocol, liquidity always remains in the liquidity provider (LP) wallet. You don't put them in some third-party contract where they'll just sit there. They are in your own wallet until you need to use them . This also means that you are not tied to any specific trading strategy. You can follow trading strategies, but it no longer locks up your tokens.

You can send them to a centralized exchange if you wish exchange if you wish , or trade them on your own time, exchanging them for something else. You are simply providing the commitment, you are no longer actually tying them online to other trading strategies. And the calculation is atomic. So, from the perspective of traders, the people who are going to use this new system, it's the same experience they've always been used to. They can go to their favorite block explorer, see the moment the transaction was confirmed, and check the result check the result .

So, let 's take a look at the architecture of 1inch Aqua. It consists of three parts. These are Aqua router, Aqua apps and strategies. Aqua router is just an 80-line smart just an 80-line smart contract, and it is responsible for three main functions. The first is the registration of LPs, that is, wallets that actually join the Aqua protocol, balances, which tokens and how much of each token they want to provide to the protocol, and the calculation of swaps.

So, it's actually taking tokens from the LP wallet and moving them to the trader's wallet, and vice versa. Next up are Aqua apps. This is the actual implementation of swap logic. So, you can think about a constant product, concentrated liquidity, stable swap, all the actual elements of the price curve logic. This is the focus of Aqua applications.

And the last thing is strategies. This is LP's commitment to Aqua applications. So, if there is an Aqua app with a permanent product, the strategy would be to have the LP commit to wrapped ether and USDC, which provides one ether and 1500 USDC. Or maybe they are joining the Aqua stablecoin swap app, holding USDT and USDS for 1,000 units of each of these tokens each of these tokens . So if we look at the example from the beginning of this presentation, which is a very basic familiar case for AMM, we can now look at it through the lens of what if they did this inside Aqua.

So the elements now instead of one pool contract in the middle—it's the Aqua router and the Aqua app, and in this case it would be an AMM with a permanent product. So, the first thing that happens is that Bob does an approve or permit to the Aqua router to give it access to any funds for which he wants to provide liquidity. Next, he will call aqua.ship, and aqua.ship will have information about his tokens, how many tokens, which Aqua application he wants to join as a strategy, and all this information will be stored in the Aqua router state.

And in this transaction, the data of this strategy will also be emitted . The indexer can now collect all this information and index it so that other people can access it and quickly find out what is available to them inside the Aqua router. 1- Aqua router. 1- inch runs its own indexer, but it could be anyone. There may be competing indexers that want to index different use cases within Aqua if they are not covered by the main indexer from 1-inch.

So, once Bob has registered with Aqua and once the indexer has received the information, now a trader like Alice can come in and get that information from the indexer. If she likes the information she sees, she can get a quote from the Aqua app using Bob's balance data. And if she's happy with that, she can now, uh, initiate the swap. So initiate the swap. So , she will send her Ether to AMM.

The AMM will then contact the Aqua router and say, "Hey, Bob said he's taking on a commitment with this balance, and we have a trader who wants to exchange token A for token B." If the Aqua router confirms that all of this is valid and Bob has given permission, it will then use its permission or approval to, uh, well, first transfer the Ether and then pull out the USDC and give them back to Alice on the other side. So, in this case, the same deal happened, but inside the Aqua ecosystem with a few extra steps. So what do we get from this? First, LPs can send and sell pegged tokens whenever they want.

Since the funds never leave their wallet, they now participate as liquidity providers in DeFi without having to lock anything in a contract. It's still available to them whenever they want and whatever they want to do with it . LPs can now participate in management. So, if you hold a control token for something that uses wallet balances for voting rights, you no longer lose that right. You can provide liquidity for exchangers and participate in management at the same time.

And most importantly, LPs can reuse the same tokens for other Aqua applications and strategies, and we're going to look at the third one right now. So, let's say Bob has four tokens instead of two. He has Ether, USDC, Aave, and Tether. And he has $1,000 each. In this case, he would have a total of $4,000 in liquidity with which he wants to participate in the Aqua ecosystem.

So he can take $1,000 in ether, full balance, and $1,000 in USDC, full balance, and say he wants to put it into a strategy on the Aave router. So, he currently has $2,000 in liquidity. Then he can again take his entire ether balance and his entire Aave balance and provide them as a token pair within the Aave strategy. And then he can create a third strategy that includes all of his ether as well as his full Tether balance as an Aave strategy. So, his actual liquidity at this point is still $4,000, but his effective liquidity is $6,000.

Now, in this scenario, Alice can come in with USDC and trade against Bob’s ether using the same process we covered earlier. And at the same time, Tony can come and exchange his Aave for Bob's ether. And Craig can also come and exchange his Tether for Bob's ether. And each trade will go through a separate pair, using the same pool of liquidity in Bob's wallet. Some of you might be thinking, "What you might be thinking, "What if two people come in and spend all the ether in the first transaction, won't the second transaction fail because there wasn't enough ether for everyone?"

And the answer is yes. The person who comes second will get the transaction canceled, but this is unlikely to happen often to happen often , as our indexer will check wallet balances and only provide quotes when they are highly likely to go through. So, in certain scenarios, this is likely to happen, but we don't think it's a big enough problem to prevent this technology from being really useful. We've talked a lot about a stable product like an Aqua stable product like an Aqua add-on, but we could obviously implement concentrated liquidity like an Aqua liquidity like an Aqua add-on or a stable swap, and as these pricing curves are implemented, we're seeing a lot of repetitive code in that ecosystem. Therefore, we decided to create SwapVM—a native Aqua SwapVM—a native Aqua application that serves as a virtual machine for swapping—before releasing Aqua, to remove all unnecessary code and allow people to focus on what's important when building new AMMs.

So, you can think of SwapVM as a kind of building blocks for swapping functions. This means price curves, taker limits if you want to create a limit order protocol, fees because liquidity providers usually want to be rewarded, and deadlines if you don't want it to be a perpetual deal. So, if we look at these two examples, one of them will be a “pure” Aqua application, and the other will be a Aqua application, and the other will be a similar application similar application , but built on Swap VM. Don't worry about reading all this code. This is just to show the difference between them.

On the left we see a constant product, implemented as a “ implemented as a “ pure” Aqua application. It is written in Solidity It is written in Solidity , inherits the Aqua app class and, in essence, does what everyone is used to everyone is used to : quote exact in, quote exact out, swap exact in, swap exact out. And exact in, swap exact out. And anyone who has worked with some of these old AMMs has probably seen this logic many times. And if we look to the right, we see the Swap VM implementation, which is actually in JavaScript, because it's just an SDK that uses the "builder" pattern "builder" pattern to essentially say, to essentially say, "Hey, what components do you want to see in your AMM?"

You just do it in a few lines, hit " lines, hit " call build" at the end, and get the bytecode representing this AMM, which can now be run via Swap VM. So, these building blocks inside Swap VM are blocks inside Swap VM are just opcodes under the hood. There are many more of them than the ones I showed in this example. It seems there were three of them in that example. I think there are many more of them on the team .

And there's another additional thing another additional thing we call exstruction, which essentially says, " which essentially says, " Hey, if you want to do something with your AMM that requires data outside of the contract, you can do it with an exstruction with an exstruction ." A very obvious example of this is the collection of oracle data during decision-making. You can create your own opcodes for this hackathon, but you will have to edit our Swap VM contract and then redeploy it . This is a fairly advanced level, and the Swap VM contract itself is approaching the maximum allowable contract size in Ethereum. So if you choose this path, you will have to remove some opcodes that you are not using to make room in the contract for your own opcodes.

So own opcodes. So , keep this in mind as an advanced path, but it will give you a lot of bonus points because we really value swap VM projects during judging. So, Aqua goes far beyond simple AMMs. So far, we’ve only used AMM in our examples because it’s the easiest way to explain the value of Aqua, but in reality, Aqua is a much more versatile engine for connecting two parties who have tokens and want to do something with them. So, Aqua has been available for many hackathons.

I think we've been doing hackathons for about 7 or 8 months now, and people have been creating prediction markets based on Aqua . People built privacy pools. People were creating flash People were creating flash loans, and it really demonstrated the versatility of this protocol. So we encourage people to be creative and think beyond just sharing if you want to use our technology. Here's an example from last time with an AMM of a permanent product, but we'll change it up a bit so you can see how this can be used for more than just AMM.

Let's say we implemented a flash implemented a flash loan as an Aqua application, and we still have Bob and Alice on both sides. Alice comes in and says, " comes in and says, " Okay, here's the loan amount I'm interested in, and here's the payload I want to accomplish with the flash with the flash loan." As before, the Aqua flash loan application accesses the Aqua router. He asks, “Hey, is this liquidity available? Does Bob’s wallet really sign the transaction, confirming his consent?

” And if everything is confirmed, it uses the permissions uses the permissions Bob granted earlier to withdraw USDC from his wallet, transfer them to the Aqua flash loan app, perform the load, and then return the USDC with a certain fee; thus Bob continues to make a profit and Alice remains satisfied. So, in this presentation we discussed flash discussed flash loans and AMM of the permanent product. We briefly mentioned stablecoin exchanges, which stablecoin exchanges, which can of course be performed with more than two tokens. And Bob can use all three of these applications simultaneously from one wallet, using the same funds. This is the main advantage of the entire ecosystem: you can collect all the liquidity in one place and do whatever you want with it at the same time, instead of fragmenting it between many different protocols.

So, the impact of this on the broader DeFi market is quite significant. For liquidity providers, this means higher utilization of funds and better returns. Basically, you can do a lot more with your tokens, and this will simply lead to making money faster. For DeFi users, this means that all applications built inside Aqua will typically have better prices as more liquidity comes in as people reuse it and make it more available to many applications at once. And for developers, this means a fast path to production and users, because as this ecosystem grows, more people will pay attention to it and be interested in new protocols launched on its basis.

So, let's wrap this up with a brief explanation of our bounties. We have two of them this year or at this hackathon. The first this hackathon. The first is to create a new Aqua app on 1inch. The total prize fund will be $5,000: $ 2,500 for first place, $ 1,500 for second, and $1,000 for third 1,500 for second, and $1,000 for third .

Another category . Another category is expanding on what you have already built using the new continuation track from ETHGlobal. So just take something you've already created before and add Aqua to it. The total fund will be $2,000. First place will receive $1,500, and second place will receive $1,500, and second place will receive $500.

That's all from my side. Here's the QR code, it will take you straight to our bounty page on the ETHGlobal website, and I'll be happy to answer any questions you have now, because I know this was a lot of information. And if you don't have any questions yet, I'll be in the 1inch partner channel on Discord ETHGlobal along with a few other people from our team. So you don't have to ask questions right now. We'll be there remotely, but you can put them up now if you have them .

Perfectly. Thank you very much, Tanner, as always, for such a comprehensive workshop. If you have a chance, I'll give you a few minutes to scan this QR scan this QR code or maybe ask a question here. But as Tanner said, it will be available on Discord throughout, as I understand it, this entire hackathon. I see some AI notes here, but I'll leave the time open for 30 seconds for possible questions.

Yes, I had a few questions about Aqua VM. So, as you mentioned, if we implement a swap VM, we'll have to redeploy all the smart contracts, right? Repeat the last part, please. Did you say " you say " develop smart develop smart contracts"? Well, if we want to modify something or create our own AMM based on swap VM, we will have to redeploy all the contracts, right?

Not your own AMM, but your own opcodes. Swap VM natively supports its own AMMs, but yes, if you want to do something completely unique, you will need to redeploy the swap VM, which is perfectly acceptable for a hackathon. Of course, this is an issue we will discuss later if we want to make this production-ready, but we want people to be creative. So yes creative. So yes , if you want to create something of your own, you just take our official contract, edit it, and redeploy it.

And about the SDK part, for example, if we want to integrate UI, we will have to modify the 1-in SDK, right? TypeScript SDK, because it will have a different API, right? Um, yes. Yes, I think so . I think so too.

Um, but even if you do, it will be a fairly minor change. I don't think this will be a big problem for the hackathon. Of course. OK. And also, I read about swap VM, so if we change it and add our own opcode, we will also have to register that opcode in a separate smart contract, right?

Like that. The opcodes will be in the same contract. You simply redeploy the same contract with the changed code and those opcodes will become available there. You shouldn't split this into two contracts. Actually, if you find a way to do it, I think that would be fine too, but I have n't really thought about whether it's possible yet.

In general, we recommend simply freeing up space by removing opcodes you don't use and fitting everything into a single contract deployment. Of course. Thank you.