Introduction to Algebra ‘Integral’ Modular Architecture
Until now, each DEX had its source code in the form of a single immutable monolith, and updating such architecture required liquidity migration and associated additional expenses.
With the advent of Integral, it became possible to separate the most vulnerable part (liquidity storage) and peripheral functionality modules (e.g. oracles, fee calculation) from each other. Critical functionality of liquidity storage and swap calculations is kept at the unchangeable Core, while peripheral functionality of Plugins can be updated when needed without liquidity migration. This approach allows DEXes to develop faster.
Plugins can be introduced by DEXes themselves or external developers encouraged by the fees to create new Plugins and push the technology forward according to DeFi current trends, possibly creating a competitive market of Plugins covering the most various needs.
This article covers the technical side of implementing the Plugins within Algebra ‘Integral’ Architecture, including:
- the concept of a Plugin itself;
- the way a Plugin interacts with its Liquidity Pool (via Hooks);
- available Hooks;
- the process of Plugin deployment (and the introduction of Plugin Factory entity)
- Standard Plugin and its Submodules: TWAP-Oracle, Adaptive Fee, Farming Proxy
- Limit Orders Plugin
Plugins. Interaction between Liquidity Pools and Plugins.
Plugin is a smart contract that connects to a Pool’s contract and expands its functionality. Currently, only one Plugin can be initialized per each Pool. A Plugin can be disconnected or replaced by another plugin. (However, the architecture allows for connecting several plugins to one Pool through a Proxy Plugin, which can be developed in the future).
What a Plugin can do: do arbitrary actions on the blockchain (including calling other contracts), change the fee in the pool, do additional checks, etc.
What a Plugin cannot do: take someone’s liquidity or tokens (directly), change the logic (mathematics) of calculations.
Plugins interact with the Pools via Hooks.
Hook is a function connecting the Plugin and the Pool, which is triggered before or after a certain key event, allowing the Plugin and the Pool to exchange information. The set of possible Hooks corresponds to these events (which are: initialization of a Pool, liquidity mint or burn, swap, flash loan):
- beforeInitialize – a call before initialization of a Pool
- afterInitialize – a call after initialization of a Pool
- beforeModifyPosition – a call before changing any liquidity position. The call can occur before a mint or liquidity burn.
- afterModifyPosition – a call after changing any liquidity position. The call can occur after a mint or liquidity burn.
- beforeSwap – a call before swap
- afterSwap – a call after swap
- beforeFlash – a call before flash loan
- afterFlash – a call after flash loan
If a Plugin is attached to the Pool and the setting corresponding to the given Hook is activated, then the Pool will call the Plugin’s function upon the event. The function must be defined in the Algebra Plugin Interface. Arbitrary logic can be implemented inside this function (including interaction with the same liquidity pool).
Plugin deployment. Plugin Factory.
To create Plugins, the Plugin Factory entity was introduced. Plugin Factory (PluginFactory) is a smart contract responsible for the deployment of Plugins’ contracts and for the primary initialization of Plugin’s Dynamic Fee configuration.
The plugin is deployed during pool creation: PoolFactory calls the createPlugin() method from PluginFactory. At the end of deployment, the plugin address is set in the Pool.
When the Pool is initialized, the beforeInitialize Hook is triggered. As a result of this call, the Plugin sets the Plugin Config of the pool, activating the Hooks it relies on and adaptive fee. Plugin Config is a uint8 bitmap, each bit is responsible for enabling/disabling the hooks, the last bit turns on/off dynamic fees logic.
Also it is possible to set the farming center’s address in PluginFactory; the address will be set in the Plugin and will be used when the Plugin interacts with farming.
Standard Plugin: Modules
Currently the Standard Plugin is a default Plugin, available right upon deploying ‘Integral’. It contains several Modules: TWAP Oracle, Adaptive Fee and Farming Proxy.
TWAP-Oracle (Volatility-Oracle)
- General operation principles: In the current implementation, Plugins can act as Oracles, providing access to historical price and volatility data.
- Initialization and operation: Historical data is stored as an array of timepoints. The oracle is initialized via the afterInitialize Hook. During initialization, the first timepoint (containing the current timestamp and tick) is written to an array. Initialization can only be called once.
- TWAP-Oracle relies on the beforeSwap and afterModifyPosition Hooks. With each swap/change of position, a new entry is added to the array, but not more than once per block. The maximum number of records is 65535. Upon reaching the maximum number of records, recording begins from the zero element of the array, overwriting old timepoints.
- It is also possible to prepay for the initialization of new timestamps, which will reduce the cost of the first per block swaps/position changes. Initialization can be carried out by any user by passing the number of elements for which he wants to pay.
Adaptive Fee
- General operation principles: The main advantage of Algebra over other DEXes is the dynamic fee. In the Integral version, the adaptive fee functionality was moved to the Standard Plugin’s Module. Having information from TWAP-oracle about price changes, the Module calculates the fee based on the volatility of the pair.
- Initialization and operation: To use dynamic fee, the dynamic fee flag must be set in the Pool’s plugin configuration. This module relies on the beforeSwap and afterModifyPosition Hooks. Before each swap/after changing the position, these Hooks are directed to the Plugin. During the call, the fee in the pool is recalculated and changed (using the setFee method of the liquidity pool), if it is different from the previous one.
- If the dynamic fee mode in the pool is disabled, fee can only be changed by the holder of the corresponding rights in AlgebraFactory. The administrator also has the opportunity to change the behavior of the adaptive fee by changing its config.
Farming Proxy
- General operation principles: In the current implementation of Farming there is a Virtual Pool containing information about the liquidity and state of the original Pool. For the Farming Module to work correctly, continuous synchronization between the Virtual and regular Pools is required. Therefore, the Farming Proxy Module was added to the Plugin.
- Initialization and operation: This module is activated if the Virtual Pool’s address has been set. The Module relies on the afterSwap Hook – synchronization of Pools is achieved through the afterSwap Hook, in which the crossTo method of the Virtual Pool is called. At the end of the swap, the Pool transmits information about the final tick and the direction of the swap.
Limit Orders Plugin
- General operation principles: Users can place a limit order that will be executed automatically when a specified price is reached. No external oracles, calls, etc. will be required. Limit orders are executed when the trader makes an exchange.
- Operation: The Limit Orders Plugin is a separate smart-contract. When placing the Limit Order, the user creates positions in the Pool in one token, the range of which does not exceed the pool tickspacing. This Plugin uses Hooks afterInitialize and afterSwap. After initializing the pool, the Pool’s tick is recorded in the Limit Order Plugin to track the intersection of positions. During the swap, the calculation of the crossed ticks and the closure of all positions/limit orders that were crossed happens. The current Pool tick is also updated. In this case, limit orders will not roll back after a complete closure. The user has the opportunity to take liquidity until the limit is closed. All fees collected by the limit order position can be collected by the user upon closing.
Further development
Potential Plugins development directions currently include:
- Introduction of elastic fee. Can be implemented to combat toxic flow.
- Other dynamic fees options
- KYC System
- Gas discount/compensation system for trades
- Plugin for combating JIT liquidity. Jit-liquidity may be recognized as an issue in some cases
- LVR and IL reduction
- Perpetuals
Conclusion
The introduction of Uniswap V4 brings serious shifts to the DeFi landscape. However, this is not the system widely available for implementation by DEXes; Algebra’s Integral, taking into account these arising market challenges, allows a DEX to stay competitive during these fundamental changes – accelerating the progress even further.
About Algebra
Algebra is a Protocol enabling projects to integrate Concentrated Liquidity tech, alongside other groundbreaking features — Dynamic Fees, Built-in Farming, and more. Already seamlessly integrated into various DEXes across different chains, including Camelot, THENA, QuickSwap, StellaSwap, Zyberswap, Equilibre, Magma, Swapsicle, Synthswap, Kim, and more, Algebra propels them to higher trading volume & enhanced capital efficiency. Learn more on our website: algebra.finance.
$ALGB is the platform token of the Algebra Protocol, used for governance, liquidity provision, and much more. The Algebra stakers get part of all fees acquired from the integrated DEXs in ALGB, while part of the commissions is used for buybacks, which strengthens the token itself. ALGB on CoinMarketCap.
