Fuul
  • INTRO
    • ⚡What is Fuul?
    • 💪Why use Fuul?
    • 🤔Use Cases
    • ⚙️Integration
    • 🔗Main Links
  • HOW IT WORKS
    • 💸Types of Rewards
    • ✅Conversion Events
      • 1️⃣CLAMM LPs (e.g. Uniswap V3)
      • 2️⃣Constant LPs (e.g., Uniswap V2)
      • 3️⃣Lending & Borrowing
      • 4️⃣Staking
      • 5️⃣Token Holders
      • 6️⃣Custom Onchain Events
      • 7️⃣Custom Offchain Events
  • 🤑Incentive Payouts
    • 🗿Fixed Rewards
    • 🌊Variable Rewards
    • 💰Pool Distribution
  • 🧑‍🤝‍🧑Referrals
  • ♾️Attribution Methods
  • 💲Budgets
  • ⚡Fuul Incentives Manager
  • 🎖️Leaderboards
  • 💻Incentives Hub
    • 👨‍💻White-Label Implementation
    • 👍No-Code
  • FOR DEVS
    • ⭐Getting started with Fuul Web SDK
    • ⚙️Sending Custom Events through the API
    • 📄Tracking referrals in your app
    • 👨‍💻API Key Management
    • 🛠️Building your incentives hub in your app (white-label)
      • ℹ️Getting all incentives information
      • 🔗Creating affiliate links or codes
      • 💯Getting Leaderboard Data
        • 🪙Tokens
        • 🌟Points
      • 🙋Getting Individual Rewards
        • 🪙Tokens
        • 🌟Points
      • 🤙Claiming Onchain Rewards
    • 🔧Building widgets
    • 📢Managing Audiences and Segments
      • 👤Getting User Audiences using Fuul SDK
      • 👥Updating Audience Segments using Fuul API
    • ✈️Migration from older SDK versions
    • 🆘Troubleshooting
  • PROTOCOL
    • ⛓️Smart Contracts
    • 🧵Subgraphs
  • Guides
    • ✏️Getting Started
      • Creating Your First Incentive Program
      • How to Add a Budget in Fuul
  • 🏁Creating Triggers & Conversions
    • Understanding Triggers Types
    • Creating an Event with CSV file
  • 🎨Program Incentive Page
    • Building no code landing pages
  • 📊Analytics
    • Understanding Sybil Detection
Powered by GitBook
On this page
  • Formula
  • Out-of-Range Liquidity
  1. HOW IT WORKS
  2. Conversion Events

CLAMM LPs (e.g. Uniswap V3)

Everything you need to know about concentrated liquidity campaigns on Fuul

PreviousConversion EventsNextConstant LPs (e.g., Uniswap V2)

Last updated 3 months ago

Concentrated Liquidity Campaigns allow projects to reward Liquidity Providers (LPs) on concentrated liquidity AMMs such as Uniswap V3, Quickswap, and Camelot. Unlike traditional incentive mechanisms that treat all liquidity providers the same, concentrated liquidity campaigns enable projects to tailor rewards based on how liquidity is provided within specific price ranges.

Concentrated liquidity lets LPs allocate their capital to specific price bands, making their liquidity more efficient and potentially generating higher fees. Fuul’s mechanism for concentrated liquidity is designed to maintain the full benefits and flexibility of these Decentralized Exchanges (DEXs) for LPs, offering greater rewards for those who concentrate their liquidity effectively.

Formula

When an incentive provider chooses to reward a concentrated liquidity DEX using Fuul, they specify a particular pool, the time period for the incentives, and certain parameters for position values. Below, we explain how these parameters work.

For example, if a pool with two tokens (A and B) is incentivized, the Fuul engine analyzes the swaps that occurred in the pool during the defined period and calculates a value score for each position based on the following factors:

  • Liquidity Utilized: The value take into account the liquidity utilized by the position during the period, reflecting how much liquidity from that position was utilized by the pool.

  • Token A Holding: The amount of Token A held by the position during pool swaps, compared to the total amount of Token A in the pool.

  • Token B Holding: The amount of Token B held by the position during pool swaps, compared to the total amount of Token B in the pool.

This system ensures that position values are fair and based on the contribution of each position to the pool's activity.

The exact formula for the distribution of position values in such a pool over a given period of time is as follows:

With:

  • w_liquidity: Weight assigned to rewards based on liquidity.

  • w_a: Weight assigned to rewards for Token A in the pool.

  • w_b: Weight assigned to rewards for Token B in the pool.

  • Liquidity by position / Liquidity by pool: The share of total liquidity provided by the user compared to the total liquidity in the pool.

  • A in position / A in pool: The user’s share of Token A in the pool, calculated as the amount of Token A in the user’s position divided by the total Token A in the pool during an epoch.

  • B in position / B in pool: The user’s share of Token B in the pool, calculated as the amount of Token B in the user’s position divided by the total Token B in the pool during an epoch.

With this setup, this is as if the overall incentive budget was split in 3, with a proportion being shared by LPs based on how much fees they've earned, a proportion shared based on the overall amount of Token A they've held and a last portion based on the relative Token B balance they've had in their position during the time period.

Let's say parameters are set such that: fees = 40%, Token A = 30%, Token B = 30%:

  • If a user earns 50% of the total fees from an epoch, they will receive 20% of the total rewards for that epoch.

  • If a user holds 30% of the Token A in the pool for an entire epoch, they will receive 9% (30% × 30%) of the total rewards for that epoch.

  • If a user holds 20% of the Token B in the pool for the entire epoch, they will receive 6% (30% × 20%) of the total rewards for that epoch.

Out-of-Range Liquidity

Incentive providers have the option to decide whether to reward out-of-range liquidity in concentrated liquidity pools. If out-of-range liquidity is not incentivized, only in-range positions will qualify for rewards.

We strongly recommend focusing on in-range liquidity, as this ensures that rewards go to liquidity providers who are actively contributing to the pool’s functionality. While incentivizing out-of-range liquidity may have limited use cases, the option is available if it aligns with your specific needs.

✅
1️⃣