âŦī¸Changes V1
The new version of our protocol, Algebra Integral, contains a lot of new functions and capabilities, as well as various kinds of optimizations. This version is significantly different from Algebra V1. To simplify migration and integration of the new version, we briefly describe the major differences in this document.
Algebra Integral is located in the master branch of the repository:
At the same time, the V1 was moved to a separate repository (legacy):
Solidity 0.8.20
The most basic change that affected almost all contracts is the transition to a new version of Solidity (0.8.20). In order to maintain backward compatibility, the version directive of interfaces has been kept as >=0.5.0 where possible.
It is important to note that interface IAlgebraPool
requires a version of at least 0.8.4 due to the use of custom errors. For those who use older versions of the compiler, a special version of the interface without custom errors has been made: IAlgebraPoolLegacy
.
Gas optimizations
Almost all contracts have been significantly reworked, which has resulted in gas savings while expanding the capabilities of the protocol.
AlgebraPool changes
Supported tokens
The new version of the protocol does not support tokens whose total supply can exceed "2^128 - 1" (max value of uint128
). This limitation allows us to make contracts more gas-efficient and predictable for the vast majority of tokens.
The new version has wider support for rebase tokens: in the event of a rebase and an increase in the pool balance, the resulting excess will be distributed among active liquidity providers. In the first version of Algebra, as in Uniswap V3 and other implementations of concentrated liquidity, this excess of tokens would simply be stuck on the pool contract forever.
Usage of plugins
The functionality of each Algebra Integral pool can be expanded through various plugins. For more details, see the corresponding section of the documentation.
TWAP oracle moved to plugins
The oracle has been removed from the core protocol and moved to an optional plugin. This avoids spending gas on the oracle if it is not needed.
Now, to get data about timepoints, you need to access the corresponding plugin contract directly.
Adaptive fee moved to plugins
Our dynamic commission was separated from the pools into a separate plugin. Such a change allows us to update the logic of the dynamic fee, use other approaches, or completely turn off the dynamic fee, using the static one and reducing gas costs. Thanks to this, Algebra Integral can be more flexibly customized to specific needs.
GlobalState structure
Due to other pool changes, the globalState
structure has changed. Added field pluginConfig
- tightly packed bitmap with plugin cofiguration. Field timepointIndex
was removed together with the TWAP oracle. Fields communityFeeToken0
and communityFeeToken1
replaced with single field communityFee
.
Changeable tickspacing
In the first version of the protocol, tickspacing was an immutable constant within pools. In Algebra Integral, tickspacing can be changed at any time. This allows the protocol to more accurately and efficiently set up pools for different kinds of tokens. The default tickspacing is 60. Contracts interacting with Algebra Integral pools must take into account the possibility that tickspacing will change. MAX_LIQUIDITY_PER_TICK is fixed based on tickspacing value 1.
Ticks are stored in a bitmap without transformations associated with tickspacing: internally, the pool always uses tickspacing equal to one. This does not introduce any additional overhead, since a doubly linked list is now used to navigate ticks.
Data in ticks
Removed fields outerTickCumulative
, outerSecondsSpent
and outerSecondsPerLiquidity
from Tick
structure. Added fields required for the implementation of a doubly linked list. See the contract documentation for details.
Tick data structure
Now ticks are stored as a doubly linked list: each tick contains the indices of the next (nextTick
) and previous (prevTick
) ticks. The tickTable
mapping is saved and used in the search tree when inserting and deleting new ticks. The tickTable
mapping structure is similar to the same mapping in the first version of the protocol.
Position structure
Removed the lastLiquidityAddTimestamp
field due to the removal of the entire liquidity cooldown mechanism. Changed the data type of the liquidity
field to uint256
.
Custom errors
The second version of the protocol uses custom errors added to Solidity instead of of text messages in require
. This allows us to increase the readability and informativeness of errors, while reducing the size of the bytecode. Pool errors are placed in the IAlgebraPoolErrors
interface.
It is important to note that interface IAlgebraPool
requires a version of at least 0.8.4 due to the use of custom errors. For those who use older versions of the compiler, a special version of the interface without custom errors has been made: IAlgebraPoolLegacy
.
Community fee setup and transfer
Now community fee is regulated by one parameter (
communityFee
) instead of two.Governance can also now configure what value of
communityFee
will be set in new pools by default. This makes it easier to set up new pools.In order to save gas, community fee is no longer sent with each swap, but is accumulated and sent at a specified frequency.
Now all community fee is sent to a pre-specified contract
AlgebraCommunityVault
. This greatly reduces gas costs and increases the security of the protocol.
Liquidity cooldown removed
The new version of the protocol removed the liquidity cooldown mechanic, which was intended to protect against JIT-liquidity in the first version.
Farming changes
Farming as optional plugin
In Algebra Integral, the standard plugin provided by the protocol is now optional and can be connected using the plugin. This allows to use different farming formats, connect new ones, or completely disable this functionality.
Limit farmings removed
In the new version of the protocol, one type of farming is left: eternal (V2-like) farming. Limit farms were almost never used and their removal allows to significantly simplify contracts and increase security.
Transfer of position NFT is no longer needed
In the new version, users no longer need to send the NFT of their position to the farming address. In addition, users can increase and decrease liquidity without having to exit and re-enter farming.
Roles and AccessControl
Now the AlgebraFactory contract implements the IAccessControl interface and the role system. This allows the protocol to fine-tune the permissions to perform individual actions in the protocol.
The owner
of the AlgebraFactory is a superuser and has the rights to all actions in the standard contracts of the Algebra Integral protocol. We recommend transferring the owner's rights to a multisig or a special contract to reduce risks.
Protocol can assign the following roles to different addresses:
keccak256('POOLS_ADMINISTRATOR')
- allows to change tickspacing, community fee, plugin and plugin configuration in poolskeccak256('COMMUNITY_FEE_WITHDRAWER')
- allows to withdraw accumulated community fees from theAlgebraCommunityVault
contractkeccak256('COMMUNITY_FEE_VAULT_ADMINISTRATOR')
- allows change configuration of theAlgebraCommunityVault
contractkeccak256('NONFUNGIBLE_POSITION_MANAGER_ADMINISTRATOR_ROLE')
- allows to change FarmingCenter address in NonfungiblePositionManager contractkeccak256('ALGEBRA_BASE_PLUGIN_MANAGER')
- allows to change adaptive fee configuration in corresponding pluginkeccak256('INCENTIVE_MAKER_ROLE')
- allows to create new farmings, change rates and deactivate old farmings in AlgebraEternalFarming contractkeccak256('FARMINGS_ADMINISTRATOR_ROLE')
- allows to change FarmingCenter address in AlgebraEternalFarming contract and withdraw unspent rewards from farmings
In addition, the protocol can create new roles and use them in its other contracts.
CommunityVault
Accumulated community fee is now sent to a pre-specified contract AlgebraCommunityVault. This greatly reduces gas costs and increases the security of the protocol. An address with the appropriate rights (AlgebraFactory owner or keccak256('COMMUNITY_FEE_WITHDRAWER')
) can withdraw tokens from this vault.
Adaptive fee plugin
As already mentioned, the standard version of the dynamic commission of the Algebra protocol has been moved to a separate plugin.
The adaptive fee configuration has been simplified. Params volumeBeta
and volumeGamma
have been removed along with the corresponding sigmoid.
The corresponding contract code has been largely redesigned. Thanks to this, it was possible to drastically reduce gas consumption and improve the accuracy of the adaptive commission.
Last updated