Crescent DEX: Epoch Farming
Being an AMM/Orderbook DEX unique to the Cosmos Ecosystem, Liquidity farming is important in providing liquidity for exchanges within our DEX.
In a nutshell, liquidity farming is depositing liquidity to a coin-pair pool, receiving a certain amount of reward proportional to a user’s contribution to that pool, allowing users to swap tokens efficiently.
Explained below is the liquidity farming procedure implemented into Crescent DEX:
Day 1: A user deposits a pair of tokens into a pool, and begins liquidity farming
- The user’s pool tokens for their contribution is now QUEUED for farming, farming to be activated at Day 2 00:00 UTC.
- All newly farmed deposits are considered to be queued ranging from Day 1 00:00~23:59 UTC
Day 2: The user’s contribution to the pool is now farming rewards based on the APR(Annual percentage rate)
- A full 24 hour period (Day 2 00:00 UTC ~ Day 3 00:00 UTC) has to pass in order to receive rewards
Day 3: The user’s contribution has now yielded rewards(CRE), which can be claimed
- The confirmed rewards can be claimed at Farm>Manage>Claim
Day 4: The user then decides to unfarm the whole contribution on this day
- Upon unfarming the full amount, unclaimed confirmed rewards are given, but rewards for Day 4 is not included because Day 4 hasn’t fully passed yet
Now, what happens when a user adds liquidity to an already farming pool?
Day 3: Seeing yielded rewards, the user decides to add liquidity to their already farming position
- The newly added amount is now in queue for farming, while the initial amount remains farming rewards
Day 4: The unclaimed rewards for the initial provided liquidity are auto-claimed into the user’s CRE balance in portfolio at Day 4 00:00 UTC, which can be found in the balance of CRE
- From Day 4 00:00 UTC, the user is now farming the increased amount, and LP rewards for this amount is available to claim manually from Day 4 00:00 UTC
What if you partially unfarmed during a farming epoch?
In this example, the user unfarms 50% of the user’s farming amount. Then, at the moment of unfarming, the accumulated rewards is instantly claimed. Then, only the remaining amount of farming will be eligible for rewards during the epoch, claimable at the end of the epoch.
TLDR(Although you should most definitely read):
- All newly deposited and farmed amounts are put into queue until 00:00 UTC of the next day, and queued amount is technically not farmed yet until 00:00 UTC of the next day
- Adding liquidity to an existing farming pool results in an auto-claim of rewards at 00:00 UTC of the next day based on the initial amount prior to adding
- Rewards can be claimed after provided liquidity is in the farming status for a full 24 hours between 00:00 UTC of yesterday and today
Why do we use this method?
As presented in our Crescent Ethos, Crescent Network will commit to, and evolve toward embodiment of providing a marketplace for multi-chain assets with capital-efficient liquidity incentivization. This includes our orderbook methodology, which vastly increases sustainable and efficient liquidity within a marketplace.
The journey for Crescent does not end at AMM, it is merely the beginning. Orderbook requires quick transactions, and therefore short block times. Creating a vast number of TX transactions exactly at the same time results in a chain overload possibly delaying block times by more than minutes, which is critical to a network providing an orderbook marketplace.
This is why we implemented a version of the F1 distribution method for liquidity farming reward distribution, which is based on the rules below:
Farming queue
- each new farming order is under queued status until activated
- queued farming is not eligible for farming rewards
- queued farming is activated at the first 00:00 UTC arrived
Auto-claim rewards
- F1 assumes constant farming amount during each reward accumulation period
- therefore, if below conditions met at 00:00 UTC, accumulated rewards are auto-claimed based on the farming amount of yesterday 00:00 UTC, and new reward accumulation period begins with the updated farming amount
1. new farming amount incoming : if there exists queued farming
2. unfarmed amount : if farming amount is reduced from yesterday 00:00 UTC
The F1 fee distribution does not calculate the rewards of each block. It saves the cumulative unit rewards of each user’s LP position and calculates the rewards when it is claimed by the user. The cumulative unit rewards is data that saves the amount of rewards of 1 coin from epoch 1 of staking when staking is maintained.
In doing so, if a user changes their staked amount(excluding queued amount), the staked amount is not the amount staked from epoch 1, so the cumulative unit rewards cannot calculate the new amount.
The rewards for the previous staked amount are auto-claimed because calculating the rewards from the previous staked amount would be inaccurate as there has been a change in staked amount. From a rewards distribution perspective, a partial addition in liquidity is seen as a whole new LP position. The chain begins calculating the new cumulative unit rewards from the new epoch 1 again in consideration of the new staked amount.
Compared to other methods of reward distribution by accumulating the reward of each user every block, this method alleviates overwhelming of the chain, enhancing chain stability and block times.
