Technical Design

The Ferra DAMM is a constant-product AMM protocol on the SUI network with advanced features like dynamic fees, concentrated liquidity, and anti-sniper mechanisms. Below, We’ll dive into the technical implementation of DAMM, focusing on how it works, fee calculations, swap mechanics, and other key components.

Core Mechanism: The AMM with Concentrated Liquidity

DAMM operates on the constant-product formula $x \cdot y = k$ Where:

• x : Amount of token A in the pool.

• y : Amount of token B in the pool.

• k : Constant invariant, ensuring the product of token reserves remains constant after a swap (ignoring fees).

Unlike traditional AMMs (e.g., Uniswap V2), DAMM introduces concentrated liquidity within the constant-product framework. Pool creators can define a price range for the pool, which restricts liquidity to a specific price band, improving capital efficiency. This is akin to Uniswap V3’s concentrated liquidity but implemented within a constant-product model, not a full CLMM. Once set, the price range cannot be adjusted by LPs, ensuring stability for pool parameters.

Technical Details:

• Price Range: Defined by the pool creator during initialization, specified as a minimum and maximum price (in terms of token A per token B or vice versa). This limits swaps to occur within the range, concentrating liquidity and reducing slippage for trades within that band.

• Liquidity Provision: LPs deposit tokens in proportion to the current pool price within the defined range. Single-sided liquidity is supported, allowing a single token to be deposited which is useful for token launches.

• Invariant Preservation: The $x \cdot y = k$ formula is maintained, but the effective liquidity is adjusted based on the price range, making it behave like a hybrid between AMM and CLMM.

Fee Structure and Calculation

DAMM introduces a sophisticated fee model with base fees, dynamic fees, and an anti-sniper fee scheduler. Fees are not auto-compounded into the pool, giving LPs flexibility to claim fees in one or both tokens.

Base Fee

The base fee is a fixed fee set by the pool creator during pool initialization (e.g., 0.3% or 300 basis points). It is applied to every swap as a percentage of the input amount. For example, if a user swaps 100 tokens with a 0.3% base fee, 0.3 tokens are deducted as the fee, and 99.7 tokens are used for the swap.

Dynamic Fee

• Purpose: The dynamic adjusts fees based on market volatility to maximize LP returns during high-volatility periods.

• Calculation: The dynamic fee is an additional percentage (currently up to 20% of the base fee, with plans to increase to 100%) calculated on-chain based on volatility metrics. For example:

  • If the base fee is 0.3% (300 bps), the dynamic fee could add up to 0.06% (20% of 0.3%).

  • Total fee = Base fee + Dynamic fee (e.g., 0.36% in this case).

• Volatility Metric: The Volatility is based on price movements over a recent time window. The mechanism is similar to the Volatility Accumulator which explained in DLMM's Dynamic Fee session

Anti-Sniper Fee Scheduler

Purpose:

Deters bots from sniping tokens during early trading (e.g., during token launches) by starting with high fees that decrease over time.

Mechanism:

Use the Time-Based or Slot-Based mechanism, fees can decay linearly or exponentially based on Unix timestamps (time) or SUI slots (block height).

Example: A pool might launch with an initial fee of 10%, which decays gradually to 0.3% over a period of 24 hours or 1,000 slots. For highly volatile tokens, such as meme coins, the initial fee can be as high as 80% at launch to mitigate the risks of sudden price swings.

The linear fee decay from initial fee formular: $F(t) = F_{\text{init}} - \left( \frac{F_{\text{init}} - F_{\text{final}}}{T} \right) \cdot t$

Where:

• $F(t)$ : Fee at time (t)

• $F_{\text{init}}$ : Initial fee, eg: 50%

• $F_{\text{final}}$ : Final fee, eg: 0.3%

• T : total decay duration

• t : elapsed time or slots

Linear decay function over the time (t)

The exponential fee decay equation calculates the fee $F(t)$ over time using a decay constant ${\lambda}$, as described below: $F(t) = F_{\text{final}} + (F_{\text{init}} - F_{\text{final}}) \cdot e^{-\lambda t}$

Exponential decay function over the time (t)

The chart above shows that the fee is quite high at launch (e.g., 38% at 5 minutes after launch) but decreases to a normal rate once trading stabilizes (e.g., 0.54% at 50 minutes after launch).

Swap Mechanics

A swap in DAMM involves exchanging one token for another while maintaining the constant-product invariant and applying fees. Here’s how it works:

Swap Process

1. Input: A user submits a swap instruction with:

   • Input token and amount (e.g., 100 SUI).

   • Desired output token (e.g., USDC).

   • Minimum output amount (to prevent excessive slippage).

2. Fee Calculation:

   • The smart contract calculates the total fee (base fee + dynamic fee + anti-sniper fee, if applicable).

   • Example: For a 100 SUI input with a 0.36% total fee, 0.36 SUI is deducted, leaving 99.64 SUI for the swap.

3. Price Calculation:

   • The pool’s current price is determined by the ratio of token reserves $P = y/x$

   • The swap amount is adjusted to maintain $x \cdot y = k$

   • For a swap of $\Delta X$ token A (after fees), the output $\Delta Y$ of token B is: $\Delta y = \frac{y \cdot \Delta x}{x + \Delta x}$ where $x$ and $y$ are the reserves before the swap.

4. Price Range Check: If the swap would push the pool price outside the defined range, it is rejected or partially executed up to the range boundary.

5. Reserve Update:

   • The pool’s reserves are updated: $x_{\text{new}} = x + \Delta x , y_{\text{new}} = y - \Delta y$

   • The invariant $x_{\text{new}} \cdot y_{\text{new}} = k$ is preserved (ignoring fees).

6. Fee Storage: The fee (e.g., 0.36 SUI) is accumulated and distributed to LPs later

7. Output: The user receives $\Delta y$ of the output token.

Liquidity Provision and Withdrawal

Adding Liquidity

Process:

• LPs call an add_liquidity instruction, specifying token amounts and the pool.

• For single-sided liquidity, the smart contract calculates the equivalent amount of the other token based on the current pool price and adds it to the pool.

• The LP receives an NFT position representing their share of the pool.

• Price Range: Liquidity must align with the pool’s price range. If the current price is outside the range, single-sided deposits may be restricted.

• Fees: A small fee (~0.022 SUI) is required for adding liquidity

Withdrawing Liquidity

• Process:

  • LPs call a remove_liquidity instruction, specifying the position and amount to withdraw.

  • Tokens are returned proportional to the LP’s share of the pool, based on current reserves.

• Liquidity Locks: If the pool has a lock (permanent or vesting), withdrawals are restricted until the lock expires. Permanent locks can be tokenized as NFTs for trading or governance.

• Fee Claiming: LPs can claim accumulated fees separately before or during withdrawal.

Additional Features

Liquidity Locks and NFTs

• Permanent Locks: Liquidity can be locked forever, represented by an NFT. This NFT can be traded, staked, or used in governance programs (e.g., for fee distribution).

• Vesting Locks: Liquidity can have a vesting schedule, allowing gradual unlocking.

Single-Sided Liquidity

• Use Case: Ideal for token launches with limited initial capital (e.g., memecoins).

• Process: A project deposits one token (e.g., 100,000 LOFI). The smart contract initializes the pool with a starting price, allowing swaps to bootstrap the other side (e.g., SUI or USDC).

• Risk: Higher IL risk for single-sided LPs due to price volatility.

Custom Pool Activation

• Mechanism: Pool creators set a start time (Unix timestamp) for when the pool becomes active for swaps (This ensures coordinated launches). The smart contract checks the current timestamp against the activation time before processing swaps.