How LP Staking works on Skeleton
Last updated
Last updated
Liquidity providers (LPs) can provide liquidity across different price ranges of the 0.01%, 0.05%, 0.25%, 1%, 5% and 10% fee tiers pool on Skeleton. In exchange, they receive NFT ERC 721 to manage their position. The user interface accommodates LPs who want to stake multiple positions to earn rewards. Rewards are distributed only during the period when the liquidity is active. As a result, LPs will enjoy different APRs in Skeleton rewards based on their liquidity provision methods.
Users are able to choose their risk profile and maximize rewards with Skeleton:
Provide liquidity for a narrow price range (aka. concentrating liquidity) to earn higher APR, but also face higher risk of impermanent loss and will not receive rewards if price moves out of range.
Provide liquidity for a wider price range to earn more guaranteed APR, and face less risk of impermanent loss, but face less capital efficiency so lower APR than if narrower.
Users unfamiliar with concentrated liquidity, but would like to earn rewards should provide liquidity for full range.
Let's start by defining some terms. We refer to programs which incentivize liquidity as Incentives; they're characterized by the following parameters:
rewardToken: Perhaps the most important parameter, would-be incentivizers must pick the ERC20 token which they would like to distribute as a reward for providing liquidity.
pool: The address of the pool in which liquidity must be provided.
startTime: The UNIX timestamp at which rewards start to be distributed.
endTime: The UNIX timestamp at which rewards start to decay.
refundee: The address which has the right to reclaim any leftover rewards after the Incentive has concluded.
Finally, every Incentive has an associated reward, the total amount of rewardTokens that are allocated to be distributed over the lifecycle of the program.
Now that we have an idea of what an Incentive looks like, let's explore how rewards are actually allocated to participants. The next section will touch on the participation mechanics, so for now let's abstract this away and just focus on the high-level design.
Recall that Incentive creators pick a reward amount and a program duration. This directly corresponds to picking an amount of rewardTokens to distribute per second; let's call this the reward rate. So, for every second between startTime and endTime, a constant amount of tokens are distributed proportionally among all in-range liquidity at that second. Crucially, this counts all liquidity, not just liquidity that opts in to participating in the program. So, incentive creators should pick a reward rate that they deem worthwhile to distribute across (potentially) all in-range LPs for the duration of the program.
There are two conditions that must be met for a program to be considered concluded:
block.timestamp >= endTime: In other words, the program's duration must have expired. However, this doesn't mark the official end of the program, as some users may still be participating right up until this endTime boundary and beyond, to maximize their rewards. This leads directly to the second condition.
All NFTs must be unstaked: A program can conclude only when every NFT which participated in it is unstaked.
It's important that most or all programs fully conclude, primarily so that the refundee can reclaim any unallocated rewards. What are the conditions under which unallocated rewards will remain? Well, recall that the reward rate is the same across all in-range liquidity. However, only program participants may actually claim accrued tokens, so it's likely that all programs will end up with a balance of rewardTokens that cannot be claimed. So, refundees will typically be incentivized to bring programs to an official conclusion. This slightly cumbersome design is a consequence of the difficulty of consistently allocating rewards proportional to liquidity.
A final note: stakers who remain in the program after endTime may actually see their rewards marginally augmented or (more likely) gradually diluted. The magnitude of these changes depend on stakers' share of the total active liquidity, the time spent staked after endTime, and the sequence of unstaking. In the worst case, rewards decay proportionally to the duration. For example, at 2x the duration, ½ of rewards could remain, at 3x, ⅓ could remain, etc. While somewhat complex, this behavior can largely be ignored from a game-theoretic standpoint. Stakers should simply attempt to unstake and claim rewards as soon as possible after endTime, an outcome that is likely in any case, as refundees will be eager to reclaim leftover rewards, and mass unstake stragglers.
