Fusion AMM Mechanics Explained

The Problem

Liquidity pools are great! They have a bunch of really cool features and allow for a ton of cool use cases that wouldn't be possible without them. But traditional order books still have one feature that Liquidity Pools (LPs) don't: limit orders.

Order books are good at these... because that's all they are: a set of limit orders. If you want to buy or sell right now, you have to pick the best limit order in the book and use that as the counterparty to your trade. Liquidity pools are really good at this kind of order because of how they keep track of price and handle orders. But if you want to set an order to execute at a certain price in a liquidity pool, things get a bit trickier.

The image above is showing a simplified visualization of what a SOL/USDC LP might look like at some price. As you can see, the current price is not where we want to trade. LPs, however, don't store discrete orders. They represent a continuous price curve where liquidity exists at all points between ranges, so you can't "wait" for price like in traditional limit order books. Under the hood, they keep track of what the current ratio of tokens is (the price) and how it should change as tokens get added or removed, but they don't keep track of when/if someone wants to buy or sell.

Now that we have established that you can't create limit orders on LPs, let's go to Jupiter and create limit orders on LPs.

Doesn't seem right, does it? It looks like a limit order. Quacks like a limit order. But is it actually a limit order? The short answer is: "No". But that doesn't make for a good article. So let's dig deeper into what is actually happening.

The first clue is the name, "Trigger". The way limit orders execute on LPs is by constantly watching the price. Once it hits the required level, a transaction is sent to execute the swap. The issue is, this is really inefficient. Imagine yourself in Jupiter's position: thousands of tokens, each one could have one or hundreds of pools. Thousands of users placing millions of orders on different pools at different prices. And every user expects to have their order filled at the price they requested. That creates immense cost for Jupiter. And the worst part is, fills aren't guaranteed. If your order isn't the fastest or isn't quick enough, you may not buy at the price you requested, or you might only buy a portion of the amount you wanted. Also consider other providers of limit orders. When everyone wants to be the first to get the best price, speed is vital, and more speed = more cost.

The Solution

Make the limit orders part of the liquidity. Simple. Efficient. Ingenious.

Fusion AMM does this by allowing users to place limit orders that the pool keeps track of between ticks. This means that in order for price to move past a level, all liquidity and limit orders on that level have to be consumed.

And if we flip the whole thing on its side and hide the core liquidity itself...

By managing orders in this way we get a bunch of benefits:

• Orders are executed faster,

• Orders are executed more accurately,

• Instead of paying a fee to place a limit order, you earn rewards for providing liquidity through your limit order once it’s filled,

• No risk of partial fills even though the price moved past the limit order.

This finally gives AMMs the final leg up on traditional order books.

Conclusion

FusionAMM isn’t about reinventing the wheel—it’s about putting better tires on the one we’ve been using for years. By collapsing liquidity and limit orders into the same pool, execution becomes smoother, cheaper, and far more intuitive for both traders and protocols.

After all, the best innovations are the ones that make you wonder: "Why weren’t we doing this the whole time?"

Written by jstEagle