Bonus Breakdown (Detailed)

Outlining the bonus breakdown more in depth.

As previously highlighted, every swap generates a native ETH bonus that is allocated among liquidity providers and the protocol. There are four uint8 bonus variables that must be initialized for each pool, reflecting the bonus distribution for both buy and sell transactions. These variables correspond to USDC amounts, and the associated ETH bonus is calculated for each swap using an on-chain oracle. For instance, a pool may be initialized with a $10 bonus for purchases and a $15 bonus for sales. If a user decides to sell their tokens, they must pay a bonus of $15 worth of ETH to the protocol and liquidity providers. The smart contract designated by the protocol can utilize this bonus to add permanently locked liquidity, thereby establishing a rising price floor for the token and providing sustainable revenue for its creators. Liquidity providers can promptly claim their share of the rewards collected from the swap. This section outlines how the liquidity provider bonuses are allocated, while the next section will discuss the handling of the protocol APY. The xp.fun pair smart contract keeps track of a series of ascending values referred to as Euler amounts. These values are updated whenever native ETH is sent to the pair contract. Each Euler amount is calculated by adding the previous Euler amount to the ratio of the bonuses, to the current total supply of liquidity provider tokens (LP). The initial Euler amount is set at zero. Mathematically, this update can be represented as:

$$Eulerₙ = Eulerₙ-1 + \frac{Bonus}{LPsupply}$$

Eulern = Eulern-1 + Bonus LP supply With the corresponding sequence of rising numbers:

$${ Euler1, Euler2, Euler3, Euler4 ... Eulerₙ}$$

This sequence is particularly of interest to liquidity providers. Each provider is represented by a struct which stores the LP holdings of each user and a variable called euler0 which is suggestively named after the Euler amounts in our sequence.

struct Provider { 
    uint256 lp; 
    uint256 euler0; 
}; 

This uint256 number represents the latest Euler amount in our sequence at the time the user adds liquidity, in which case we would have euler0 = Eulerₙ.

Suppose the user decides to claim rewards a thousand swaps later. In that moment, the latest Euler amount is Eulerₙ+1000. The exact amount of rewards that this provider accumulated during those thousand swaps is:

$$Reward = lp∗(Eulerₙ+1000 − euler0)$$

This approach operates under the assumption that the LP balance remains constant through out the period. Therefore, whenever a provider takes any action, such as adding/removing liquidity, the variable euler0 will be refreshed to reflect the latest Euler amount in our sequence. This measure prevents a liquidity provider from manipulating their own share of rewards.

As such, it is advisable for a liquidity provider to always claim rewards before adjusting their LP balance. LP tokens are non-transferable except when being burned or added/removed from the liquidity.

The essence of this mathematical approach lies in its ability to accurately determine the share each user receives per individual swap, regardless of the continuous changes in the total supply of LP tokens due to liquidity providers adding or removing liquidity.