Algebra Finance: Modular DEX-as-a-Service with Plugins, Dynamic Fees, and Uniswap Compatibility

I first came across the Algebra protocol when my team and I were forking Camelot DEX. The first version of Camelot was a fork of Uni v2, and for the next version with concentrated liquidity support, they integrated Algebra. Even back then, I was curious about the advantages of that approach.

There are two important points here:

1. Each version of Uniswap is protected by the BUSL-1.1 license — it prohibits commercial use in a production environment for a certain period if someone decides to fork the protocol. Typically, when a new version of Uni is released, the license on the previous one expires. At the same time, viewing, modifying, and using the code for non-commercial purposes — like testing or development — is allowed.
2. The Uni v2 version became extremely popular for forks after its license expired.

Against this backdrop, Algebra chose the following strategy: while the Uniswap v3 license was still in effect, they could freely experiment with the code, identify its weak spots, and think about how to improve them.

This is how the first version of Algebra came to be — essentially an improved version of Uniswap v3, with enhancements and new features.

At the base level, Algebra’s structure mirrors the architecture of Uniswap v3 — the "DEX engine" includes the same key smart contracts.

• The core includes a factory for creating liquidity pools and the pool contract itself.
• The peripheral part includes a router for adding/removing liquidity and executing swaps, as well as the NonfungiblePositionManager — an ERC721 token that represents a position in the pool (I'll talk more about positions later).
• Helper contracts and libraries (not shown in the diagram) are also taken from Uniswap.

Since its launch, the protocol has undergone significant changes, but the basic structure remains relevant — one of the key goals is still to maintain compatibility with Uniswap v3 interfaces.

Next, I'll try to explain how Algebra gained an edge over Uni v3. We'll have to talk quite a bit about Uniswap itself, but the main idea is simple: Algebra == Uniswap + new features.

What’s included in the core functionality of Uniswap v3? What makes this protocol innovative, and why did it make sense to use it as the "DEX engine" for Algebra?

Let’s take the following approach: we’ll break down how Uni v3 reimagined the very concept of a decentralized exchange and its own solutions from previous versions, and how Algebra managed to take it even further and make it better.

What were the drawbacks of Uniswap v2?

• Impermanent loss — Liquidity Providers lose potential profit compared to a “hold” strategy if asset prices fluctuate significantly.
• Inefficient capital usage — in Uniswap v2, liquidity is spread evenly across the entire price curve (from 0 to infinity), while trading typically happens within a narrow range. This means that most of the LP’s capital remains inactive and doesn’t generate yield.

Let’s take a closer look at the phenomenon of impermanent loss — it’s key to understanding the core issues.

Why does impermanent loss happen?

1. In AMMs like Uniswap, liquidity providers (LPs) deposit a pair of assets into the pool (e.g., ETH and USDC). The ratio between these assets in the pool changes dynamically based on prices, in order to maintain the AMM invariant — x * y = k.
2. When the price of ETH rises, the pool automatically starts selling ETH (to maintain balance), and when it falls — it buys more. As a result, the LP loses potential profit they could’ve gained by simply holding ETH in their wallet.

So, the LP loses profit both when the price of ETH rises (they end up with less ETH) and when it falls (they get more ETH, but it’s worth less). In the second case, the losses are even greater.

The Role of Fees

The next important factor is the pool fees, which can partially or fully offset impermanent loss. Let’s look at this using two charts:

The first one shows LP losses without taking fees into account:

Here we can see that if the price doesn’t change (100% on the X-axis), the LP doesn’t lose anything, but with significant price increases or drops, the losses become noticeable.

Now, the chart including fee income:

As we can see, losses during asset price increases become much less significant because fees partially offset the missed profit. But there’s one important point: in Uniswap v2, the fee was fixed — 0.3% for all pools, regardless of asset volatility.

How Did Uni v3 Reduce the Impact of Impermanent Loss?

In the third version of the protocol, Uniswap pulled off another revolution — it introduced the concept of CLMM (Concentrated Liquidity Market Maker), or concentrated liquidity.

Instead of distributing liquidity evenly across the entire price range like in Uniswap v2, LPs in Uniswap v3 can allocate their assets within specific price ranges (called “positions”). For example, if the current ETH/USDC price is 2000 USDC per 1 ETH, an LP can provide liquidity only in the range from 1800 to 2200 USDC.

Liquidity is used for swaps and earns fees only when the current price is within the specified range. If the price moves outside that range, the position becomes “inactive” (it no longer participates in trading), but the assets remain safe. Positions are created as NFTs and can be freely traded on marketplaces, creating a secondary market for liquidity.

This way, an LP can create either a single position within a narrow range or multiple positions across different segments of the price curve.

Such positions help reduce the impact of impermanent loss — LPs gain the flexibility to choose a strategy based on their risk tolerance. In addition, the new approach significantly improves capital efficiency. For example, in Uniswap v2, $10,000 might generate a 1% return, while in v3 the same $10,000, concentrated in an active range, can generate 10% or more.

Rethinking the Fee Structure

The second major innovation in Uniswap v3 is a flexible fee system. For each asset pair, Uniswap v3 offers multiple pools with different fee tiers: 0.01%, 0.05%, 0.3%, and 1%. Typically, high fees (like 1%) are suitable for volatile pairs with higher risks and impermanent loss, while low fees (like 0.05%) are used for stable pairs.

In practice, the same pair can exist in multiple pools with different fee tiers at the same time. This creates a balance between the interests of LPs (who benefit from higher fees) and traders (who want low slippage and low fees).

For example, when adding liquidity to an ETH/USDC pool, you can choose one of four fee tiers:

The interface also shows the liquidity share distributed across pools with the same assets but different fee tiers. Despite the dominance of the 0.05% fee pool, around 20% of the liquidity still remains in the 0.3% pool.

To sum it up: Uni v3 is the foundation, but there are caveats

Uni v3 focused on improving capital efficiency — meaning it allows you to earn more with less capital. But certain drawbacks still remain:

• Yes, fees became more flexible, but if you want a single token pair to have different fee tiers, you have to “split” the liquidity across multiple pools.

• The Uni v3 architecture doesn’t support farming directly. Farming is a tool to attract additional liquidity, but Uniswap already has strong liquidity on its own. So just forking Uni v3 isn’t enough — you still need a way to incentivize liquidity inflow.

• No support for fee-on-transfer tokens — these are tokens that charge a fee on every transfer, which affects the final amount that actually ends up in the liquidity pool.

In its first version, Algebra focused on fixing the shortcomings of Uniswap that I mentioned earlier. Most of the work went into dynamic fees — the protocol gives special attention to this feature in its whitepaper.

In the end, they entered the market with three main features:

1. Dynamic fees
2. Built-in farming (works out of the box)
3. Support for fee-on-transfer tokens

The goal of the fee mechanism is to find a balance between the interests of all parties. As we discussed earlier, in Uniswap v3 this is done through fixed fee tiers (0.05%, 0.3%, 1%). The problem is that this leads to fragmentation of liquidity across multiple pools.

In addition, asset behavior can change over time. For example, an asset considered stable might quickly become volatile. As a result, liquidity may end up being inefficiently distributed across pools with different fee tiers.

Algebra offers a solution to this problem in the form of dynamic fees, which adapt to the pool’s behavior. To achieve this, three key metrics are analyzed:

1. Volatility
2. Liquidity volume
3. Trading volume

High returns for LPs are achieved when there is high trading activity and low volatility:

In practice, it works like this:

• When volatility is high, the fee increases to compensate LP risks
• When trading activity is low but liquidity is sufficient, the fee decreases to encourage more swaps

Algebra uses a flexible formula that takes all these parameters into account and allows keeping all liquidity within a single pool, without splitting it across multiple pools. Thus, unlike Uniswap v3, there’s no need to create two or three different pools with different fees.

Technical Details

The implementation of the dynamic fees mechanism deserves a separate article, but let’s highlight the key points:

• Minimum fee is 0.01%. It can be changed by the factory administrator after initialization.
• Maximum fee is 6.5535% (type(uint16).max with a divisor of 1e6)
• Fee recalculation happens with every interaction with the pool (swap, adding/removing liquidity), but the actual recalculation occurs only once per block.
• The recalculation is handled by the function DataStorageOperator::getFee, which uses the DataStorage and AdaptiveFee libraries.
• The configuration allows setting the fee change rate. Volatility is taken as an average over 24 hours, which smooths fluctuations and improves calculation stability.

Details of the formula implementation and mathematical justification can be found in the whitepaper.

where:

• rangeSecondsInside — time during which the price was inside the range;
• rangeLiquidity — total liquidity in that range.

Then, the contribution of a specific position is calculated:

And finally, the total reward:

where:

• totalReward — total amount of rewards in the campaign;
• campaignDuration — duration of the campaign.

Recalculation happens with every swap in the pool or when a new participant joins the campaign.

Types of farming

In Algebra v1, two types of farming are available:

Support for Fee-on-Transfer Tokens

In its first version, Algebra added support for fee-on-transfer tokens, including deflationary tokens whose total supply can decrease during transactions.

Examples of such tokens:

• Tokens where part of the amount is burned on each transfer, reducing the total supply.
• Tokens that charge a fee on transfers, with the fee being burned.
• Tokens with other fee mechanisms that may not be deflationary but affect the amount of tokens received.

For proper handling of such assets, Algebra implements the function
swapSupportingFeeOnInputTokens.
It determines the actual amount of tokens received by the pool after all deductions, including burns, enabling correct swaps.

Unlike Uniswap v3, where supporting such tokens requires creating wrapped tokens, Algebra handles these assets natively, simplifying interaction.

New Features in Version v1.9

Before releasing the second version of the protocol, Algebra introduced an intermediate update — Algebra v1.9. This is a minor release, but it’s worth mentioning to understand the protocol’s evolution. In this version, the developers focused on contract optimization, improved tick handling, and added new features. Let’s look at the key changes.

Configurable Tickspacing

Tickspacing is the interval between price levels (ticks) in a pool, which determines how precisely you can set the concentrated liquidity range. The larger the tickspacing value, the more available price intervals and higher flexibility in range settings, but this also increases gas costs.

In previous versions, the tickspacing value was a constant set to 60. In v1.9, the developers allowed this parameter to be configurable, limiting the maximum number of intervals to 500. This made it possible to manage ranges more precisely, which is especially relevant for stable pairs (like USDC/USDT), where setting intervals more accurately is important.

Limit Orders

Version v1.9 introduced a new feature — limit orders. Limit orders allow automatically closing positions at predefined prices, reducing price impact. But it’s important to understand that this is a separate product; it just works with the codebase (core) of the protocol’s first version.

Recently, Uniswap released its fourth version, whose code is again locked under a 2.5-year license. As I mentioned earlier, all versions of Uniswap are protected against copying by licenses. In the case of the first version, the Algebra team simply waited for its expiration.

This time, to avoid waiting for the license to expire, Algebra took a smarter approach — the new protocol version, Algebra Integral (v2), will still be based on Uniswap v3 but with added hooks, like in Uniswap v4. This will allow moving to a modular architecture and implementing plugin support.

With this approach, it’s unlikely to create a DEX that surpasses Uni v4, but implementing similar features without violating the license is quite possible.

Modular DEX Instead of Monolith

One of the key features of Uniswap v4 is its modular architecture. The idea of a modular DEX is to create a simple, reliable, and secure core that can be extended with external modules (plugins). Not every pool needs, say, dynamic fees or a TWAP oracle, and having such functionality can significantly increase gas costs.

The previous approach to building a DEX always assumed a monolithic structure, which didn’t allow dropping unnecessary features. But by moving these functions "outside," the pool creator gains the ability to add extra "features" as needed.

Algebra managed to implement modularity through plugins. This approach, in theory, also allows adding new functionality to the DEX without the need to migrate liquidity.

Plugins

Plugins in Algebra Integral are smart contracts that can be attached to a liquidity pool to extend its functionality. Currently, only one plugin can be connected to a pool at a time. It can be disabled or replaced with another.

In theory, the new protocol architecture allows implementing a proxy plugin that enables connecting multiple plugins simultaneously (the protocol plans to develop such a plugin in the future).

Plugins can:

• perform arbitrary actions on the blockchain (including calling other contracts),
• change fees in the pool,
• perform additional checks or execute other external logic.

Plugins cannot:

• directly work with liquidity,
• modify the core mathematical formulas of the pool’s operation.

Hooks

Each plugin interacts with the pool through hooks — special callback functions that are called before and after key pool operations: initialization, position changes, swaps, flash loans, etc. This allows plugins to "hook into" the pool’s workflow and execute necessary external logic.

Examples of Existing Plugins

• TWAP Oracle. Provides access to historical price and volatility data — useful for trading strategies and risk management.

• Adaptive Fee. Calculates dynamic fees by adapting to changes in the trading pair’s volatility. This allows for more efficient pricing.

• Farming. Integrates farming mechanisms, enabling users to earn additional rewards for providing liquidity.

New plugins are also in development. In the future, a marketplace is planned where third-party developers can offer their own solutions.

You can read more about plugins in the documentation.

Other Minor Improvements in v2

Besides implementing the modular architecture, version v2 also introduced other, smaller changes:

• Contracts were rewritten in the latest Solidity version (0.8.20), all require statements replaced with custom errors, and additional gas optimizations were made.
• A linked list is now used for handling tickspacing, so increasing the number of intervals doesn’t increase gas costs.
• Farming-related changes:
  • farming logic was moved into a separate plugin;
  • the ability to create temporary (limit) farming was removed from the protocol, as such pools were hardly used;
  • no need to send NFTs to the farming contract address anymore — just increase or decrease the position participating in the campaign.
• More flexible pool management with AccessControl was added.
• Logic for handling community fee was simplified and reworked.
• The dynamic fees mechanism was not only moved into a separate plugin but also simplified, further reducing gas costs.

The Algebra Finance protocol has firmly carved out its niche in the DeFi world. The project continues to evolve and offer solutions aligned with current trends in decentralized exchanges. In any case, competition is a good thing.

At the same time, the protocol team can no longer be accused of blind copying: for example, all the "innovations" of Uniswap v4 have already been implemented in one way or another by other protocols. Overall, DeFi is a highly competitive environment where good ideas spread and get adopted quickly. Otherwise, there’s a high risk of being left behind.