Rewards
Pearl rewards are designed in a manner to incentivize and reward the users who optimize the trading environment on Pearl by supplying concentrated (deep) liquidity in the active trading range.
Rewards are calculated using the amount of time the price is within the LP's range (only active liquidity will get rewards) and the concentration of liquidity (where concentrated liquidity will get more rewards). For instance, a user with liquidity provision in tighter range will receive more rewards than the user with same liquidity in a wider range, thus encouraging extremely deep liquidity for the trading pairs on Pearl.
The following sections are a guide on how to maximize returns in Pearl v2. Providing liqudity also comes with risks, which can be found here.
Pearl Rewards
Rewards for providing liquidity are broken down into two categories:
Fees:
Fees are charged for each swap transaction on Pearl. Transaction fees are currently fixed at:
Stable Pools | Semi-Stable | Volatile Pools |
---|---|---|
0.01% | 0.1% | 0.3% |
The exchange can be further configured with 0.05% and 1% fee tiers, not currently in use.
When a swap transaction routes or "multi-hops" through several pools to complete, fees are charged on each pool transaction utilized to complete the trade.
Pearl v2 includes a provision to introduce protocol fees. These are currently set to zero, but could be added based on governance vote.
Emissions:
Emissions are the $PEARL
disturbed to each pool at a quantity determined by the outcome of the prior epoch's $vePEARL
pool voting.
$PEARL
are distributed to liquidity providers linearly over the course of the epoch.
Rewards Eligibility
We say that users are eligible to receive fees and $PEARL
emissions because unlike Pearl v1, simply adding liquidity is not enough to earn the benefits.
To receive fees, provided liquidity must be in the active trading range for the pair.
To receive emissions, liquidity must be provided though an ALM (Trident, ICHI, etc.) and staked. Only liquidity provided through an ALM is eligible to earn $PEARL token eimissions.
Liquidity provided above or below the current trading range will not receive fees and the ALM ensures liquidity is optimized for emissions. This is how we incentivize the deepest liquidity at all times, even as prices move.
Incentives for liquidity providers are based on the following criteria:
The proportion of liquidity that user has supplied to the pool within the active range or ALM and amount of time user liquidity has remained within the active range or ALM.
Total trading volume in that range
The volume of emissions that pair has earned based on the outcome of gauge voting for rewards in that Epoch.
Similar to Pearl v1.5, to earn emissions, liquidity positions in the ALM must be staked. Unstaked liquidity will only accrue fees. The fees from staked positions accrue to $vePEARL
voters.
When providing liquidity, there are no hidden fees or obligations and you can withdraw your liquidity at any time.
Unstaked liquidity earns trading fees, which are based on volume, not time-weighted. This is an important requirement in CL when LPs no longer supply liquidity across the full range.
Fee accrual to unstaked LPs incentivizes liquidity at the ends of the range, ensuring markets function correctly, even during an extreme market moves, where volume-based incentives for tail-end LPs could easily outweigh time-based emissions.
Calculating Rewards
Pearl rewards are completely tracked and calculated 100% on-chain.
While all other concentrated liquidity AMMs utilize Merkle implementations to calculate rewards off-chain, Pearl is the first CLAMM with complete rewards calculations on-chain, providing 100% transparency into the reward distributions.
Unlike Pearl v1, incentives are not linearly distributed to the pool across an epoch, allocated based on the user's percentage of tokens within the pool.
The PearlV2 Gauge contract is designed for Concentrated Liquidity Pools and employs the secondsPerActiveLiquidity
metric to distribute rewards among liquidity providers.
Rewards are allocated based on the duration and amount of active or ALM liquidity provided by users.
The gauge monitors the time-weighted active liquidity, rewarding users in proportion to their contribution, encouraging sustained and strategic liquidity provision.
Emission distributions are calculated using the emissions value assigned to that pool for the epoch, the amount of time the price is within the LP’s range (only active liquidity will get rewards), and the concentration of liquidity (where concentrated liquidity will get more rewards). Liquidity providers earn rewards based on the duration and quantity of active liquidity they contribute, while participants in governance receive incentives and collected fees.
Gauges and Rewards
Gauges will support staking and on-chain rewards distribution through two unique features in Pearl's implementation to pools and gauges.
Pearl will have two gauge implementations per pool:
GaugeV2
aka NFT Gauge aka Master Gauge (For NFT staking, emission distribution, fee collection for voters and claim) tracks rewards for all users including ALM stakers. You can choose to stake both (NFT /ERC20) the LP tokens or just one in order to be eligible for emissions.Staking NFT will modify the position in
NonFungiblePositionManager
info to make simplify liquidity management. Users will not be able to claim fees or transfer staked NFTs .Emissions will be distributed using seconds for which liquidity was active in each NFT position, including the ALM. Rewards can be claimed from respective
gaugesPool
per NFT.
GaugeV2ALM
aka ALM GaugeStaking works similarly as Pearl v1.5
Claimed emission from the NFT gauge will be further distributed to staked ALM LP tokens
Staked ALM fees will be claimed by NFT gauge at the time of rebalance and epoch rollover
To streamline gas fees within the NFT Gauge, fees will be collected on user actions while adding or removing liquidity or claiming emissions.
These fees may vary from the actual fee generated in the pool for the epoch as the fees are only accrued to the gauge when triggered by user actions.
Assuming users are actively claiming rewards, all fees will eventually be collected and distributed correctly.
In the event that a sizable amount of fees remain unclaimed, we've implemented an emergency fee claim via passing position IDs in params.
Last updated