Overview

DeDust CPMM V2 is a sophisticated implementation of the Constant Product Market Maker ($x \cdot y = k$) designed specifically for the asynchronous architecture of the TON Blockchain.

While it adheres to the fundamental principles of AMMs, it introduces several architectural innovations that distinguish it from traditional implementations like Uniswap V2.

Key Features

1. Non-Compounding Fees

In many AMMs, trading fees are immediately added to the pool's reserves. This increases the value of Liquidity Provider (LP) tokens over time ("auto-compounding"), but it couples the yield to the principal.

DeDust CPMM V2 takes a different approach: fees are accumulated separately from the reserves. This separation unlocks powerful features:

• Claimable Income: LPs can claim their accrued trading fees at any time without having to withdraw or modify their liquidity position.
• Flexible Fee Strategies: The protocol supports various fee collection strategies (FeeIn). For example, a pool can be configured to collect fees only in TON (Asset X), regardless of whether the user is buying or selling.
• Permanent Liquidity Locks: This is a game-changer for DAOs and token creators. Liquidity can be permanently locked (e.g., burning the LP rights) to signal safety to investors, while the creator retains the right to claim the trading fees generated by that locked liquidity forever.

2. Built-in Liquidity Incentives

Liquidity mining is integrated directly into the core protocol logic. There is no need for third-party staking contracts or wrapping LP tokens.

• Efficiency: Accruals are calculated automatically during standard pool interactions (deposits, withdrawals, swaps).
• Multi-Asset: A single pool can distribute multiple different reward assets simultaneously.
• Permissionless: Any user or project can fund a reward schedule for a specific pool.

3. Payment Abstraction

The protocol abstracts away the differences between Native TON and Jettons (tokens). All operations—swapping, depositing, funding rewards—use a unified structure.

• Consistent Payloads: Whether you send TON via PayNative or a Jetton via Transfer, the payload describing the intent (e.g., SwapPayload, DepositPayload) remains identical.
• Robust Error Handling: The PayoutConfig included in every request dictates exactly how to handle success ( payouts) and failure (refunds), ensuring assets are never stuck in the contract.

Architecture

The logic is distributed across three specialized contracts to handle TON's actor model efficiently:

1. Pool: The central manager. It holds the assets, executes the constant product logic, and maintains global accumulators for fees and rewards.
2. Position: An individual contract for each liquidity provider. It tracks their specific share of the pool, their locked/unlocked status, and their personal claimable fees and rewards.
3. Deposit: A temporary utility contract. Since depositing requires two assets, and TON messages are asynchronous, this contract acts as an atomic aggregator to collect both assets before finalizing the deposit.