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 and emissions, provided liquidity must be in the active trading range for the pair.

Liquidity provided above or below the current trading range will not receive fees nor 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 and amount of time user liquidity has remained within the active range.

• 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 must be staked. Unstaked liquidity will only accrue fees. The fees from staked positions accrue to $vePEARL voters. This applies to liquidity provided manually and through the ALM. There will be options to stake the manual liquidity position NFT as well as the ALM tokens.

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 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:

1. 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.

2. GaugeV2ALM aka ALM Gauge

   • Staking 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.