Spotlight on Liquid Staking

Crescent Network
3 min readApr 16, 2022

--

One of the key fundamentals of blockchain is governance. Validators confirm all transactions occurring on the network through the consensus mechanism, and delegation allows users to vote on changes to the network. Many blockchain networks utilize a consensus mechanism where users can stake their tokens to receive staking rewards, putting stagnant assets to work while having voting rights on governance proposals.

In the perspective of a DeFi user, staking may be a double-edged sword. While traditional staking mechanisms yield consistent rewards, the assets are no longer liquid and no secondary or tertiary investment action can be taken to potentially increase aggregated rewards. The assets remain locked in the staking module until unstaked, resulting in increased opportunity cost.

Crescent Network utilizes the Delegated Proof of Stake (dPoS) consensus mechanism, in which delegates(validators) are elected to vote and manage the blockchain on behalf of the electors. The delegates then receive staking rewards, which are distributed to individual electors in proportion to their delegated amount. This method allows for quick consensus with a predefined number of validating nodes, ultimately enhancing network performance.

On top of the delegated proof-of-stake (dPoS) mechanism, Crescent Network adds even more liquidity to staked assets by implementing Liquid Staking. The staked funds remain in escrow, but aren’t locked and inaccessible, as they would be with traditional staking.

Liquid staking tackles the problem of assets remaining dormant by allowing secondary investment opportunities while still giving the user the same power of voting and delegation. Crescent Network’s liquid staking utility consists of whitelisted liquid staking validators that receive equal delegation directly from the liquid staking module. When a user liquid-stakes their CRE, the delegated amount is distributed equally among the set of whitelisted liquid staking validators that can always be managed by governance.

The major advantage of liquid staking is the liquidity of user assets beyond traditional staking. When a user stakes CRE, they receive a token called bCRE (pegged staked representative tokens), which can be invested into other utilities to receive additional rewards. The bCRE represent the amount of CRE delegated plus accumulated staking rewards. By holding bCRE(and/or providing liquidity to a bCRE pair pool), staking rewards are added to a combined liquid staking fund made up of all liquid staked CRE plus rewards, much like a “fund” of a traditional financial institute.

bCRE is the representation of proportional ownership in this “liquid staking fund” of delegated assets. The liquid staking rewards add up proportional to the original delegated amount, and users “claim” their original delegated amount plus accrued rewards by liquid unstaking. As a delegated native token, users are eligible to vote on governance just by holding bCRE or having provided liquidity in a bCRE pair pool, while minimizing opportunity cost simultaneously.

Through liquid staking, the user is free to farm by providing liquidity or use other utilities using bCRE, which may lead to increased returns depending on investment preference, all while maintaining full control over voting power. Also, on Crescent Network, users are not forcefully bound by unstaking periods (often 14~21 days on the Cosmos Ecosystem) because along with liquid unstaking(14 days), users also have the option to swap bCRE for various assets.

On Crescent, when a user decides to undelegate their CRE, they can easily swap bCRE for assets with bCRE paired pools through the Crescent DEX, or liquid-unstake, receiving back the delegated CRE by burning bCRE, plus accumulated rewards. From start to finish, the user can experience enhanced liquidity and optimized investment options for their tokens by using liquid staking.

For more information on liquid staking, reward calculation, and validators, please check out the Crescent Docs.

--

--

Responses (1)