Big thanks to my colleagues at Chorus One for their contributions to this post, especially Umberto Natale for providing a lot of the data used, full report here.
Many different industries are using Ethereum to build new decentralized applications.
2021 was the year when this vision stopped being reserved for a small subset of the population with pre-existing capital (investors) or technical expertise (developers), as the popularity of Ethereum reached new heights.
Artists are disrupting traditional notions of value, with OpenSea (the largest NFT Marketplace) growing its transactions volume by “over 600x” in a year.
People are organizing self-sustainable communities, as DAO members take control over their own financial freedom and digital identity.
Builders are creating never-before-seen decentralized financial assets, where Ethereum-based Uniswap continues to dominate. But real fun also came to crypto gaming: many are playing Dark Forest, a game that experiments with cutting edge scaling technology.
Most recently, the whole crypto community has come together to aid Ukraine, at the same rate as well-established international organizations.
Bringing Ethereum into the sun and serving all of humanity, inevitably requires a scalable, secure, and resilient network.
This post aims to set the stage for Ethereum as it nears its greatest milestone, and to take a peek at the future for what this could mean in impact for both staking providers and delegators, after the Altair upgrade. To do this, we have delved into risks, rewards and the complex network that sits in between.
The big goals for the future of Ethereum are scattered across its official roadmap.
Understanding this design is key to comprehending the associated risks and rewards of PoS Ethereum. The process of upgrading started in December 2020, when the first piece of the puzzle fell into place: the Beacon Chain went live. This PoS system sets the basic consensus mechanism, by assigning the right to create a block through a deterministic lottery process. Staking nodes with a higher balance have more probability to be selected. The rewards for staking include block rewards and transaction fees, and we explore these further in the following section.
To stake in Ethereum and run a validator, 32 ETH needs to be sent to the Ethereum Deposit Contract, along with two key parameters: 1) the validator public key and 2) the withdrawal credentials for the deposit. Critically, the public key and withdrawal credentials do not need to be controlled by the same entity. This allows for two ways to participate in the protocol: as a validator or as a delegator (individuals who pass the responsibility of validation while still earning a portion of the rewards). Staking providers such as Chorus One offer ETH holders the opportunity to stake their tokens and participate in consensus through its platform.
Because chosen stakers are given exclusive rights to create a block, the protocol must consist of measures to counteract malicious attack vectors. The implementation of this consensus mechanism relies on three core elements: A fork-choice rule, a concept of finality, and slashing conditions. It is important to note that in PoS networks, slashing is not a necessary incentive for correct behavior by validators but rather an artifact of the particular block rewards and mechanism implemented. Because rewards are based on blocks processed or accepted, there’s an incentive for a validator to validate all forks in the chain, even conflicting ones (nothing at stake). Therefore, a slashing rule has to be implemented, as a matter of design.
The Altair hard fork of October 2021 introduced additional elements to consensus, namely sync committees. Validators that are part of this committee have the duty of continually signing the block header to allow a new set of light clients to easily sync up at very low computational and data cost. These concepts of head of the chain, target of attestation and source of attestation are critical to finalizing blocks and earning rewards. Checkpoints are set on-chain to achieve these goals: when a checkpoint is finalized, all previous slots are finalized. There is no limit to the number of blocks that can go through this system. A checkpoint can only be finalized after the process of consensus chooses another validator, and the infinite machine starts all over again.
It is likely that you’ve come across the prime assumption for PoS: “validators will be lazy, take bribes, and that they will try to attack the system unless they are otherwise incentivized not to” Hope for the best, but expect the worst.
You may have also seen floating around different figures for the “estimated APR” for running a validator, and wondered — where does this number even come from? All estimations for returns rest on a set of assumptions, and many published calculations were presented using outdated specs for the Beacon Chain.
So, let’s take a current look. Incentives in Altair come in the form of rewards, penalties, and slashings. Of these three, slashing is the most relevant to validator health. While crypto rewards have been around for years, their complexity and adoption have seen a significant rise in the recent past. Offerings do differ platform by platform, and all carry different kinds of risks.
One of the main conceptual reworks of Altair was in redesigning how validators are rewarded (and penalized). The idea was to make these incentives more systematic and simplify state management. But it also ups the ante on validator responsibilities.
At present, validators are rewarded/penalized if they fulfill determined duties:
A validator can propose one attestation and one block at a time. Depending on their properties, the reward varies. Participation in proposals and in the sync committee are a matter of luck but quite infrequent, however, attestations should be done once per epoch.
How we view rewards while considering risk in staking is a subject of research at Chorus One. This piece aims for other validators and interested parties to understand the “main-principles” they need to follow in order to minimize losses, and in turn, maximize profits in the process of validation. In our study, we found that currently the expected annualized reward for an ideal validator (perfect performance) is 5.44%. This amount decreases to 5.4% when we take into account a less idealized case.
After providing validators a feeling for how much they stand to earn, the following part will present a more practical example and explain how these figures may actually vary.
Slashing risk is a type of platform-dependent risk, as platforms that offer a similar service carry common risks. This section refers to the different types of penalties, and methods to calculate them at certain scenarios.
All formulas presented have been transformed in order to give a more general idea. The risk modeling was done using the actual definition from the Beacon Chain specs (Phase 0 and Altair) and the state of the chain at the time of writing. More on our methods can be found in our full study, linked previously.
Slashing includes all penalties that result in the partial or total loss of the staked assets of a validator, which range from 0% to 100% of the assets. Failing to perform the current validator duties properly (see last section) leads to being penalized and, in the case of slashable actions, being forcefully ejected from the Beacon Chain for suspected malicious activity. This is done to protect both the validator from further losses, and to help the chain finalize.
The main reasons from slashing that validators must be aware of are: proposing two different (conflicting) blocks, submitting two different (conflicting) attestations and submitting an attestation that completely surrounds or is surrounded by another attestation. If these events are not the result of a malicious action, then it follows that they must come from a bug or error. To account for this, the amount of staked destroyed is proportional to the number of validators slashed around the same time. If this number is small, then it is unlikely to be the result of a coordinated attack because that would require a high number of validators. These “honest mistakes” are punished lightly, at a minimum of 1ETH. If, on the other hand, there’s a high number of validators slashed at the same time, then it is assumed to be an attack, resulting in a higher amount of stake being destroyed, up to the full balance of the node.
There’s of course a certain pressure on validators to avoid going out at the same time as other validators. This expectation to decentralize touches on aspects of client diversity, but also on sources of truth or hosting for clients. This is a very critical point for everyone participating in the Ethereum ecosystem, and one that Chorus One has considered in our design. But back to the topic, these penalties hold true whether or not blocks are being finalized (meaning, 2/3 of validators weighted by stake are online and their votes are being counted). This is the state of normal operations for Ethereum. Anything under that, and we can no longer reach agreement and the inactivity leak mentioned previously comes in to restore balance.
With a clear understanding of the rewards system, estimating the source of possible penalties is much more simple, by calculating the attestation reward/penalty delta.
Indeed, if the reward is not finalized, the corresponding amount is removed from the attester’s balance (the minimum penalty). At that point, the validator’s unlock date for the stake is delayed about 36 days. This is to allow another, potentially much greater, slashing penalty to be applied later, once the chain knows how many validators have been slashed together around the same time (further penalty). If an inactivity leak is active, then the potential reward drops to 0, so by fulfilling the duties you are only able to avoid penalties.
Since getting the source vote wrong implies getting the target vote wrong, and getting the target vote wrong implies getting the head vote wrong, the possible slashing scenarios reduce to these:
To quantify the outcomes for performing validator duties, we would like to compare what could be considered a generic validator across a selection of edge scenarios. This example takes into consideration the following values:
Perfect Validator
To start off, let’s look at what this validator would earn if they, and all other validators, had an ideal participation record under the defined specs.
Attestations can be rewarded with a portion of the “base reward” for each of the correlated duties, weighted by the specific service provided. In the latest specs, the target vote receives the highest rewards, as it is the most important to reach consensus. The base reward is a constant across the network at all times.
BASE REWARD (in Gwei) = Effective balance * [Base reward factor / sqrt(staked ETH balance)]BASE REWARD = 32,000,000,000 * [64 / sqrt(10,000,000,000,000,000)] = 20,480 Gwei = 0.00002048 ETH
Following the upgrade, the block reward allocated is now ⅛ of total rewards as intended by the Ethereum researchers, rather than ⅛ of ¼ of rewards, as was the case pre-Altair. You may notice the delay reward is missing. Now, all attestations are given specific inclusion deadlines to claim their rewards in a gradual pattern, so prompt voting is logically accounted for.
Since all validators are supposed to attest at least one time during an epoch (for a perfectly working network), the number of attesting validators is equal to the total active validators divided by the number of slots per epoch.
ATTESTING VALIDATORS = ACTIVE VALIDATORS / SLOTS PER EPOCHATTESTING VALIDATORS = 300,000 / 32 = 9,375 validatorsTOTAL REWARD = BASE REWARD * ATTESTING VALIDATORSTOTAL REWARD = 20,480 * 9,375 = 192,000,000 GweiBLOCK REWARD = TOTAL REWARD / 8 = 24,000,000 Gwei = 0,024 ETHTARGET REWARD = 26 * TOTAL REWARD / 64 = 78,000,000 Gwei = 0,078 ETHSOURCE REWARD = 14 * TOTAL REWARD / 64 = 42,000,000 Gwei = 0,042 ETHHEAD REWARD = 14 * TOTAL REWARD / 64 = 42,000,000 Gwei = 0,042 ETH
Sync committees rotate rather slowly (every 256 epochs or every day), and validators selected can earn the sync committee reward for each slot in which they participate. A high number of validators will not be actually selected for this reward in a year’s time.
SYNC COMMITTEE REWARD = 2 * TOTAL REWARD / 64 = 6,000,000 Gwei = 0,06 ETH
Finally, we see the maximum possible reward in an epoch (this number also coincides with the minimum penalty for being offline or failing to fulfill the previous duties):
MAXIMUM REWARD = (BLOCK+TARGET+SOURCE+HEAD+SYNC COMMITTEE) REWARDMAXIMUM REWARD = 0,246 ETH
It is important to note that there’s still a potential variation to this reward of a few percent over the course of a year due to sheer luck (e.g. the probability of being chosen to propose, be in the sync committee, being offline exactly at the moment you are selected, etc. This applies even considering this ideal case, where the validator performs all their duties perfectly. The effect increases as the validator set grows, due to probability. Although not worrying in terms of an investment risk (marginal differences should even out over the course of a year), it still should be kept in mind as we delve into actual performance of validators in the network.
If we were to expand this timeline to a year, then the expected reward for this single validator per year sits at around 1.7428 ETH, which corresponds to the 5.44%% APY we mentioned in the previous section. A validator can optimally earn one base reward per epoch over a long time horizon.
Realistic Validator
However, to get a bit closer to model real-world rewards, we must consider the impact of a less-than-perfect validator performance.
As we learned previously, rewards are maximized for validators the better the network behaves. This helps disincentivize malicious behavior but also means that rewards can be reduced by external factors. A model that considers all the reasons why this validator might fail to produce attestations, produce blocks, or fail to propagate is an option, but here we wanted to observe: what would happen if we assume that 99.25% (a fair figure in reality) of active validators are actually attesting blocks? Also, we wanted to make a more conservative choice and assume that our validator was online 99.9% of the time.
As we can see, in this new realistic scenario, the total distribution shifts slightly. The expected annualized reward suffers a reduction of about 0.8% and the resulting expected APY reduces to 5.4%, as we had mentioned. The probability of certain events happening plays a huge part in this scenario, so this is just a starting point to analyze.
Slashed Validator
Next we wanted to estimate what would happen if our validator was caught committing a slashable offense, the ones that were previously outlined to result in substantial loss of stake. To do this, we will assume that we simultaneously sign two different blocks with 1000 validators. In this case, we suffer three types of slashing for each validator involved:
This corresponds to a total loss of -0.8282 ETH. It is worth noting that this slashed amount increases with the number of validators that are slashed at the same time, as was discussed in the slashing overview.
PoS Ethereum is a highly complex and elaborate system. It is thoughtfully designed, but can be difficult to fully grasp from a validator’s perspective, which can make staking seem like an uncertain and unpredictable endeavor. There is still a compelling amount of ETH that is yet to be staked, therefore we must all prioritize network participation and security in the future.
To make sense of the opportunities presented by staking, we wanted to explore the risks native to Ethereum and how said risks stack up versus the offered rewards after the Altair upgrade. Hopefully this article has helped to clarify why and how these rewards can vary from small changes in state or from bigger events, and also show how staking is a profitable business to take part in the long term. As we found in our analysis, the profit of a single validator is around 1.7428 ETH per year, or if we prefer to see in terms of percentage, this corresponds to a 5.44%% APY.
Based on the analysis performed, we find that the most realistic impact is low enough for self-cover to be a viable option, but not low enough to be completely trivial. We have identified the most relevant scenarios to come up with this conclusion. Additionally, we have found that risk can be significantly reduced by non-financial actions, such as promoting validator diversity and operator distribution, as well as putting in place mechanisms to maintain high validation quality standards. You can read our full report here.
Taking Ethereum from the individual to the masses will require a set of tools that accelerate the process of setting-up a validator whilst maintaining the same level of security and protection. At Chorus One we are working to make this a reality through our infrastructure services, and we are preparing to launch new services in the near future that take this to the next level. To learn more, please reach out to research@chorus.one.
Stargaze is an interchain NFT marketplace that solves many problems that exist in NFT marketplaces today. Since January 1 2021, average daily NFT sales have gone from ~$300,000 USD to $73,000,000 USD as of November 26 2021 (a 24,333% increase). Currently, most NFT sales occur on Ethereum, which has popular marketplaces such as OpenSea, Rarible and Sorare. Like many things in crypto, adoption of a particular primitive tends to start on Ethereum and then expands to other blockchains when users start experiencing bottlenecks. Ronin, Wax, Solana and Flow are the four blockchains that trail Ethereum in 24hr NFT sales currently (as of November 26 2021). Blockchains that trail Ethereum in NFT sales address scalability issues that arise from Ethereum’s network congestion. However, many NFT marketplaces that exist on competing blockchains enforce restrictions on how NFT projects can utilise them. With the advent of Stargaze, the Cosmos ecosystem has a dedicated zone for NFTs that does not suffer from scalability issues whilst differentiating from existing NFT marketplaces by being more secure, decentralised, transparent and flexible.
Stargaze is a fully decentralised NFT marketplace in the Cosmos ecosystem, which launched Mainnet Phase 0 on October 30th 2021. Recently, Stargaze announced 25% of their token supply will be ‘fairdropped’ to ATOM and OSMO stakers + to Stargaze validator delegators on Cosmos, Osmosis & Regen. For those who did not qualify for the airdrop, Stargaze is offering early adopters the chance to purchase STARS in a Liquidity Bootstrapping Pool (LBP) held in Osmosis as part of Mainnet Phase 1. The construction of the STARS / OSMO LBP is first-of-its-kind, as Stargaze proposed to borrow OSMO to kickstart the initial STARS / OSMO pool weights. The borrowed OSMO will be returned at the end of the LBP when STARS / OSMO weights are 50/50 and STARS has achieved price discovery. After the LBP has concluded, Stargaze will activate inflation in Mainnet Phase 2 and delegators will have the opportunity to earn staking rewards for securing the network. Finally, Stargaze will go fully-live with their decentralised NFT marketplace as part of Mainnet Phase 3 in Q1 2022, unleashing unmatched economic freedom for creators, stellar incentives for curators and superior security for NFT traders.
There are a number of issues that exist in NFT marketplaces today such as centralised curation, bad security, difficult upload workflows, limited flexibility, high gas fees, scams, intransparency of marketplace contracts and royalty restrictions.
In September 2021, the Head of Product at OpenSea used internal information to buy NFTs before they were featured on the homepage and ‘flipped’ them once featured for a profit, which in traditional finance would be considered insider trading. This is an outcome of OpenSea being non-transparent and centralised and could have been mitigated if NFT curation in OpenSea was decentralised. In the same month (September 2021), a critical security vulnerability was disclosed to OpenSea. The critical security vulnerability detected in OpenSea involved attackers airdropping SVG files to OpenSea users, which if signed by a user upon opening (even if opened on the OpenSea domain ingenuously) would give an attacker full access to a user’s funds in the wallet the malicious NFT was being viewed from. On top of these evident issues, OpenSea also restricts NFT projects to setting a maximum of 10% for royalties from sales. Lest we mention that at current ETH gas prices (124 gwei), it costs minimum $200 to buy or sell an NFT on OpenSea, which prices out a majority of retail. However, high gas prices on Ethereum for buyers and sellers can minimise scam collections, which are more commonplace on cheaper blockchains like Solana. Metaplex, a major NFT platform on Solana, also has their own issues when it comes to difficult NFT upload workflows. Finally, many existing NFT marketplaces are not open-source, which increases risks when interacting with the native smart contracts (as users have to rely on one auditing party.
So, what if I told you that a new NFT marketplace is emerging in the Cosmos ecosystem that offers high-quality security, decentralised curation, simple upload workflows, maximum flexibility, low transaction fees, open-source contracts, vetted projects and unlimited customisation of economic parameters?
Stargaze is opting to build out a zone using Cosmos SDK, which enables the network to have an unparalleled level of security and customisation vs existing NFT marketplaces. Cosmos SDK is built with capabilities in mind, which capitalises on least authority to minimise possible exploits at the execution layer. As Stargaze is its own sovereign chain, it also has 100 reputable validators securing it, all of which are specialised solely on verifying transactions that occur in the zone and can react quickly to upgrading the network to enhance the performance and/or security of it. This is completely different to NFT marketplaces on Ethereum and Solana, which are built as applications and have a reliance on validators to secure the underlying network as opposed to the application itself being in full control of its own security. Separately, the Stargaze NFT marketplace is built using CosmWasm, which is orders of magnitude more secure than the Ethereum Virtual Machine (EVM) because EVM attack vectors such as re-entrancy are not possible. All in all, Stargaze leveraging Cosmos SDK and CosmWasm ensures the network is secure and reliable.
Stargaze introduces a new type of ecosystem actor into their NFT marketplace, namingly, the CurationDAO. The CurationDAO in Stargaze is responsible for curating what artwork can be traded in the marketplace. The DAO is membership-based and is governance-driven, ensuring an open and transparent system is in place for the selection of artwork in the marketplace. Stargaze governance may incentivise the CurationDAO by directing an amount of STARS from emitted inflation to reward their work. Having a DAO that curates what is available on the Stargaze marketplace results in better due diligence of projects and reduces the surface area for scams. It could be expected that Stargaze users (both buyers and sellers) benefit from having a CurationDAO too, as only legitimate projects will be able to be traded, which should lead to more liquid markets.
The Stargaze marketplace has a built-in feature that gives NFT projects the flexibility to choose what type of launch they would like to have (e.g. first-come-first-served mint, auction over t periods, etc). The flexibility of launch options offered by Stargaze allows NFT projects to satisfy demands of their community by working closely with them to determine what type of launch is fairest. Stargaze being a sovereign chain also lets governance exercise a high-level of customisation on protocol parameters, which is beneficial for keeping the network competitive in the long-run. For example, governance could vote on specific network upgrades proposed to improve the performance of the network (which would not be possible in an NFT marketplace that existed as an application). In turn, Stargaze can be much more adaptive than existing NFT marketplaces because governance can vote on introducing changes at the network level to give it a competitive edge.
The Stargaze marketplace provides a simple interface for NFT projects to upload files and add metadata into, which uploads to Interplanetary File System (IPFS) in a matter of seconds. Files that are uploaded in Stargaze are immediately and permanently stored in a distributed and resilient system. The user experience is seamless, as the entire storage process is abstracted away from the end-user via nft.storage. All Stargaze users can be rest assured that the NFTs they own are permanently available, unlike some NFT collections that rely on a third party to host the file the NFT points to.
Fees on Stargaze are negligible compared to what can be seen on Ethereum, so the network is accessible to all types of users (not just those with a high amount of initial capital). It can be expected that fees will be just high enough to prevent spam but low enough to encourage frequent use. Low fees in an NFT marketplace enable more growth and innovation as buyers have greater purchasing power and projects can release more NFTs without transaction fee concerns.
Another unique layer of customisation available on Stargaze vs other NFT marketplaces is that of staking on the native network. One could imagine utility being introduced to STARS that would not be possible on existing NFT marketplaces like OpenSea. For example, in the future users might be able to deposit their STARS into a liquid staking protocol to receive the equivalent staked STARS (stSTARS) that could be used to bid on NFTs (i.e. users could earn yield whilst bidding on NFTs). It might also be a requirement to stake STARS in order to join the CurationDAO (the DAO responsible for selecting what collections are released on Stargaze). Or perhaps, users could stake a minimum amount of STARS in a given time period to be eligible to vote on what collections are reviewed by the CurationDAO. Another option could be to stake some amount of STARS in order to have a higher chance of getting into lottery-based NFT launches. There are limitless possibilities that could be thought of to add utility to STARS. On the flipside of staking STARS, the inflation emitted by Stargaze could also be used to reward creators of NFT projects. Once an NFT project has been vetted by the CurationDAO, it might be eligible to earn x% of staking rewards reserved for creators. In other words, NFT project creators might be entitled to a double source of income in Stargaze — royalties coming from trading of their NFTs on the marketplace + their proportion of a steady stream of STARS emitted every block directed towards creators.
Stargaze code is fully open-source and the core team recently released a LBP simulator that other projects in the Cosmos ecosystem can use to experiment with tweaking parameters before launching an LBP on Osmosis. The Stargaze code is available in a repository on Github for anyone to see, which means anyone can audit the code to ensure there are no vulnerabilities and engineers can easily build on top of existing code to enhance the platform in a collaborative way.
To conclude, Stargaze is a marketplace that exemplifies security, decentralisation, transparency and flexibility, which differentiates it from any existing competition from NFT marketplaces. Due to the nascency of the NFT space, there are many existing inefficiencies in NFT marketplaces across a multitude of blockchains. Stargaze has an opportunity to capture a large segment of a growing NFT market by offering distinct products and services for stakeholders such as NFT projects, curators and users. Novel web3 products will be built out that incorporate Stargaze NFTs in ways we cannot possibly imagine. A new era of interchain NFTs is upon us, enter Stargaze.
Written by Xavier Meegan, Research Analyst at Chorus One
Chorus One is offering staking services and building tools that advance the Proof-of-Stake ecosystem.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
Website: https://stargaze.zone/
Twitter: https://twitter.com/StargazeZone
Stargaze LBP Details: https://gov.osmosis.zone/proposal/discussion/2882-details-and-parameters-of-stargaze-lbp-on-osmosis/
800,000 LDO and many more rewards are live on Lido for Solana and its DeFi integrations
Lido for Solana launched about a month ago and so far north of $200m worth of SOL has already been staked with Lido. Today, we are glad to announce that further liquidity pools and the first liquidity rewards in LDO tokens bridged from Ethereum will start to be distributed.
Holders of stSOL can now supply liquidity to pools like stSOL-SOL, stSOL-USDC, and even stSOL-wstETH
Users providing liquidity to pools will be rewarded in LDO and, for some pools, tokens from our partners ( ORCAfor the Orca pool and MER in the Mercurial Finance pool). In addition, LPs will also collect a portion of pool swap fees and accrue value in their stSOL tokens in accordance with Lido for Solana’s staking APR.
As promised we have partnered with various AMMs to utilize stSOL — the liquid representation of your SOL stake in Lido. To bootstrap and incentivize liquidity providers Lido has initiated the formation of the various pools. Holders of stSOL can now supply liquidity to pools like stSOL-SOL, stSOL-USDC, and even stSOL-wstETH— a first-of-its-kind liquidity pool with two value-accruing Lido liquid staking assets, with wstETH being bridged via Wormhole’s decentralized validator set.
800,000 LDO will be distributed as LP rewards over 2 months on Solana AMMs
The following list contains the current stSOL liquidity integrations:
www.orca.so
Orca has launched a stSOL-wstETH (the wrapped version of Lido’s stETH). This is especially good news for stETH holders. Now, in addition to earning rewards by staking ETH and SOL, you get additional yield by adding liquidity to the wstETH-stSOL pool on Orca. Liquidity providers on Orca will earn 250,000 LDO supplemented by about 35,000 ORCA over the initial
8 weeks of this pool being live.
This first-of-its-kind liquidity pool is a very cool DeFi product! Not only is it composed of two staked assets earning staking rewards, but it also has one of these bridged over to Solana from Ethereum in a decentralized way, highlighting the power of cross-chain DeFi!
To participate in the Orca pool visit the guide linked below.
docs.solana.lido.fi
The amazing Mercurial Finance team went live with a stSOL/SOL pool that will use our internal price oracle to create a maximally efficient liquidity pool. Providers of liquidity to Mercurial will earn 150,000 LDO and matched MER rewards on top of the swap rewards while resting assured that their passive LP position is not exposed to impermanent loss. Read more about this integration.
blog.mercurial.finance
We’ve launched a stSOL-USDC pool in collaboration with Raydium. Providers of liquidity to this pool will collect 250,000 LDO over 2 months in addition to the LP rewards from swaps on the OG of decentralized exchanges that integrates with Solana’s order book DEX Serum.
Finally, Saber, the leading cross-chain stablecoin and wrapped assets exchange on Solana, has launched the stSOL-SOL pool that currently holds TVL of $160M. Liquidity providers stand to gain 150,000 LDO in addition to the LP rewards and SBR yields for this pool. These rewards will be activated once Saber supports cross-incentivization. The stSOL-SOL Saber yield farm can be found here
Lido DAO in partnership with Lido for Solana multisig has transferred LDO incentives from Ethereum to Solana by using the decentralized Wormhole v2 token bridge.
As listed above, 800,000 LDO will be distributed as LP rewards over 2 months on Solana AMMs to bootstrap liquidity for SOL.
Keep a lookout for this and further upcoming integrations at the liquid staking page on Chorus’s website.
chorus.one
Chorus One is offering staking services and building protocols and tools to advance the Proof-of-Stake ecosystem.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
Lido for Solana is governed by the Lido Decentralized Autonomous Organization (Lido DAO). Members of the DAO — holders of the LDO governance token — can vote on high-level proposals, such as whether to expand to a new chain. For day-to-day tasks, we have a much more narrowly scoped need for somebody to execute privileged operations: an administrator.
The administrator rights reside with a 4-out-of-7 multisig that consists of established validators and ecosystem partners. Last week, we successfully set up the multisig on Lido for Solana Testnet. In the coming days, the same will repeat for the mainnet launch, beyond which all new proposals by Lido DAO will be processed via this multisig structure.
This post explores why multisig is important in making Lido for Solana secure and efficient and the way forward for governance in Lido for Solana.
Multi-signature is a digital signature scheme that allows a group of users to sign a single transaction. The transaction could be a governance proposal, a snapshot vote, or even a simple fund transfer instruction. A common terminology to describe a multisig setup is m-of-n multisig. Given n parties with their own private keys, at least m of the private keys must sign a transaction to perform a transaction. For example, a multisig that has 7 members in the group and requires 4 signatures for a transaction to be fully signed — will be termed 4-of-7 multisig
Before we answer the question — why do we need multisig administration? — let us first understand how it supplements DAO governance.
In a DAO governance model, decisions get executed automatically through smart contracts as a result of LDO governance token holders voting on these decisions. This results in a decentralized governance model and eliminates dependence on a centralized authority to execute decisions thereby removing the risk of a single point of failure.
However, in the case of Lido for Solana, even though decisions are taken by the Lido DAO, they are executed by the multisig administration.
To understand why offloading the decision-execution to multisig administration is a good approach let’s look at the different administration methods that are possible in such a scenario
A good middle ground between these two extremes is multisig, a program that executes administrative tasks after m out of n members have approved. For m greater than one, no single party can unilaterally execute administrative tasks. At the same time, we only need to coordinate with m parties (instead of a majority of LDO holders) to get something done.
The benefits of multisig don’t end here. Using a multisig eliminates a lot of concerns that a typical user might have while investing. Let’s take a look at some of the other problem areas that the use of a multisig addresses.
Can I trust the creators of the program to not change critical parameters of their own accord?
There is always the risk that an administrator (the authority that executes the DAO’s decisions) can start executing decisions arbitrarily. By including multiple parties in the multisig, we reduce the points of trust and make the decision execution more decentralized.
Can Lido for Solana perform program upgrades quickly, in case of a critical bug?
A pitfall of on-chain governance is that in the case a critical bug-fix is required, achieving consensus on-chain could prove to be too slow and very costly as a result.
A completely decentralized model of governance slows down project execution, especially if a project is in its initial stages. There is always a tradeoff between the ease of execution and the degree of decentralization. However, that does not mean that one should do away with decentralization completely.
A governance model carried out by a multisig administration is the perfect compromise for a project like Lido for Solana. This lends it speed to execute decisions quickly in the earlier stages and also mitigates the risk of delayed fixing of critical bugs.
Who decides which upgrades will happen in the future and can I trust them to remain benevolent?
Decision on Program Upgrades
The multisig decides on program upgrades. To understand why this is a reasonable solution, we need to take a look at the two possible extreme cases.
1) Single upgrade authority — In Solana the upgrade authority — the address that can sign upgrades — has a lot of power. A single upgrade authority could upgrade programs maliciously at will. For example, a malicious upgrade authority could upload a new version of the Lido program that withdraws all Lido funds into some address and runs away with the funds!
2) No upgrades allowed — On the other hand, if we don’t allow the program to be upgraded at all, and then if it turns out to contain a critical bug, we can’t fix it.
So, a multisig is a good middle ground, where no single entity can take control over the programs and their funds, but we can still enable upgrades.
Trusting Multisig to remain benevolent
The DAO can be trusted because the Lido DAO is large and decentralized, and consists of stakeholders who are aligned long-term. The proposals they vote positively on are by definition aligned with the interests of the stakeholders.
The multisig executes the decisions taken by the DAO. The multisig can be trusted because the multisig participants in turn are all reputable industry partners; their reputation is at stake if they suddenly go rogue!. Additionally, no single multisig member has anything to gain by going rogue.
Why can’t Lido DAO’s proposals be executed directly on-chain?
This is because Lido DAO uses Ethereum for governance and to be able to implement Lido DAO’s decisions on Solana blockchain cross-chain execution is required. Cross-chain governance, at this point, is not mature or fast enough to be a feasible solution.
Therefore, the role of multisig then becomes that of executing the decisions made by the Lido DAO. The governance authority, which is Lido DAO, sets the long-term goals and decides on major proposals. The administrator, multisig in this case, then upgrades the program accordingly and changes its parameters.
Governance — Lido DAO
Administration — Multisig.
Is the source code public and has it been verified that the Lido program is built from that source code?
It is imperative for users, who invest their SOL in Lido, to be sure that the Lido program does not contain any backdoors or hidden features that might hurt their investments. One way to be sure of this is to know that the multisig owners have verified that the Lido and multisig programs were built from the source code that is publicly available
Furthermore, even the users can verify this fact themselves if they wish to do so.
How can I trust the parties involved in this multisig?
Another aspect of transparency inherent to Lido for Solana is the fact that we have made public the names of all 7 organizations that are part of the multisig ceremony. By doing so, users know which parties control the program and can decide whether they trust these parties. We embolden the trust of our users by including only reputable participants and by making sure that this is public information.
Multisig ceremony is the process that the multisig uses to execute decisions. On a high level, this process works as a series of steps.
As explained earlier, multisig programs require multiple signatures to approve a transaction. This allows the signers to review an action on the blockchain before it is executed — making for decentralized governance. Chorus One is using the Serum Multisig program to introduce decentralization in Lido for Solana. The Multisig that we have set up has 7 participants and requires at least 4 of them to sign for a transaction to be approved.
The 7 parties that comprise the multisig are
For now, the power to upgrade the Lido program (upon recommendation of DAO) rests with the multisig, but in the long-term Lido for Solana’s governance would be a completely on-chain decision-making process where the LDO token holders vote with their share on a proposal and collectively accept or reject it.
Decentralized policy-making in the crypto world is a complex problem. Top-down governance, as in the case of centralized organizations, is easy to implement but may not represent the best interests and needs of the stakeholders. On the other hand, a horizontal mode of decentralized governance promises a fairer representation of the voice of stakeholders but is much harder to implement.
There are multiple governance frameworks out there that exhibit varying degrees of decentralization and ease of execution. There is always a tradeoff between how easily one can implement a governance model v/s how decentralized it is. Early on, in a project’s life cycle a less decentralized but easily executable governance model makes more sense.
The long-term goal for Lido for Solana is to have a decentralized governance system with on-chain execution of decisions. In the meantime, executing decisions through a multisig helps us move quickly in the early stages, without having to trust a single party.
In terms of the project roadmap, going ahead we are looking for another audit of our code. That coupled with the results of a bug bounty will put us on the path to the mainnet launch.
Lido for Solana is poised to become the largest liquid staking solution in the market and through DAO governance and multisig administration, we make it secure and efficient. We are committed to reduce the trust surfaces required in Lido for Solana and to keep securely developing this project at a swift pace.
To read about Lido for Solana’s project roadmap please visit
medium.com
Our content is intended to be used and must be used for educational purposes only. It is not intended as legal, financial or investment advice and should not be construed or relied on as such. The information is general in nature and has not taken into account your personal financial position or objectives. Before making any commitment of financial nature you should seek advice from a qualified and registered financial or investment adviser. Chorus One does not recommend that any cryptocurrency should be bought, sold, or held by you. Any reference to past or potential performance is not, and should not be construed as, a recommendation or as a guarantee of any specific outcome or profit. Always remember to do your own research.
Chorus One is offering staking services and building protocols and tools to advance the Proof-of-Stake ecosystem.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
Helium is a blockchain network with a native cryptocurrency (HNT) used to incentivise individuals around the world to provide coverage on a global peer-to-peer wireless network. This is done using a Helium compatible hotspot, which to date provides coverage for low-power IoT devices. Traditional networks such as WiFi do not suit IoT devices well because of their lower range compared to other types of networks such as LoRaWaN. To solve this problem, Helium pioneered LongFi, which represents a mixture of LoRaWaN and blockchain technology. In the past, there were not enough incentives for participants to operate LoRaWaN hotspots resulting in higher costs for companies using IoT devices. With the invention of LongFi and using HNT to reward participants to grow the decentralised network, IoT companies now have a cheaper alternative to use. Helium has already secured multiple partnerships with IoT companies, such as Salesforce, Lime, Airly, Nobel Systems, and more. Network users pay ‘Data Credits’ (fees) to the Helium network to transmit data for any IoT device such as a tracker, temperature sensor, water meter, etc. Hotspots earn rewards (paid for by companies with IoT devices) when an IoT device has used it directly for transmitting data (e.g. to update the companies’ servers about the geolocation of the IoT device). Previously, hotspots played a role in the consensus of the network. However, Helium governance has now voted in favour of introducing validators to replace hotspots in transaction consensus. The new proposal, HIP-25, alleviates the network pressure that hotspots currently endure from validating transactions and transfers consensus work to validators.
Helium introduced 4 core primitives to allow their decentralised wireless network to grow.
The first major design decision was to introduce HoneyBadgerBFT as the consensus layer for the network. HoneyBadgerBFT does not require a leader node, tolerates corrupted nodes, and makes progress in adverse network conditions.
The second major design decision was to introduce hotspots. Helium hotspots are the epicenter of the Helium wireless network. Hotspots are purchased from external providers (currently ~$500) and then plugged into a power source and connected to WiFi. Hotspots act similarly to a WiFi router but with a coverage range orders of magnitude greater (5–15 kilometers); their primary role is to send and receive messages from Helium compatible IoT device sensors and update data from IoT devices to the cloud.
The third major design decision was Helium’s invention of LongFi. LongFi is a type of network design that utilises LoRaWaN and blockchain, which is especially designed for low-bandwidth data (5–20kbps) and variable packet sizes — perfect for IoT devices.
The fourth major design decision of the Helium network was to introduce Proof-of-Coverage. Put simply, Helium hotspots verify the location of hotspots in the LongFi P2P network. Hotspots issue challenges (via challengers) every 240 blocks to targets (other hotspots), whereby the target hotspot must prove their geolocation via transmitting radio frequency packets back to the hotspot challenger. Other hotspots in close proximity to the transmitter (up to 5) must witness and attest to the challenger that the target has responded to the challenge. Previously in the Helium network, 6% of HNT inflation rewards were dispersed to hotspots sending, submitting, and witnessing location proofs. All that is about to change with the introduction of HIP-25.
Due to the sheer growth Helium has experienced, it proved no longer feasible for Hotspots to act as block producers in Helium and issue, submit, and witness location proofs. In general, more hotspots joining the Helium network should be encouraged to join. However, right now, there is a trade-off whereby the more hotspots that join the network, the slower the network becomes. A slow network is detrimental for Helium because the network relies on large volumes of transactions being sent at rapid speeds due to the wide plethora of use-cases Helium network enables (e.g. pet-tracking, air-quality monitoring, art temperature checking, car-park availability alerting, COVID-19 case tracing and much more). When block times are slower, inflation of HNT is also slower, which also impacts the viability of setting up a hotspot to participate in the network. Hotspot addresses change and move, perfect for connecting IoT devices but not so much for verifying on a blockchain undergoing exponential growth. To alleviate the pressure off of hotspots, governance voted on introducing validators in HIP-25 that will run infrastructure to secure the Helium blockchain allowing Hotspots to focus on their core purpose. The role of the validator is a specialised one in blockchain and it is understandable that Helium now wants to utilise reliable node operators to ensure network performance is optimal. We were excited by the news that we would now be able to contribute to such a unique network and are strong believers in the long-term potential of Helium.
The introduction of node operators onto Helium introduces one key change to the staking economics of the network because those participating in consensus have changed. Previously, when hotspots participated in Proof-of-Coverage consensus, they received a consistent share in relation to all other hotspots of the 6% annual HNT inflation rewards. The economics of Helium Network are clear — there is approximately 5M HNT minted every month. Validators now participate in the consensus group and stand to earn 6% of the 5M HNT inflation that hotspots used to earn as rewards.
This means that the consensus group stands to earn 300,000 HNT per month, or 1.8m HNT annually. To run a node on Helium, there is a 10,000 HNT self-bond requirement. The requirement per node on Helium is strict, meaning you cannot be below or above 10,000 HNT per node. If you are below you will not be able to earn staking rewards and if you are above you will not earn any extra rewards for over-staking. The capital and technical requirement in Helium’s Proof-of-Stake network is high. For this reason, Chorus One is offering a Validator-as-a-Service solution for HNT holders that have enough HNT to stake, meaning we will provide infrastructure for HNT stakers who do not have previous experience running nodes. From our calculations, we estimate a staking APR between ~6–36% for HNT stakers.
There are still meaningful incentives for users to set up hotspots given the rewards allocations to data transmission and Proof of CoverageHotspot owners will continue to earn proportionate HNT rewards (up to 32.5% of the inflation rewards per epoch) if IoT devices utilise their hotspot during the duration of an epoch (30 minutes). Hotspot owners will also continue to earn rewards for verifying geographic locations of their hotspot or others in their vicinity (known as challenges, mentioned above).
In Proof-of-Stake networks, inflation is not the only element that contributes to staking rewards. Another key component contributing to staking rewards in PoS networks comes from transaction fees within the network. One interesting aspect of the economics in Helium is their use of data credits to pay for transaction fees. You can think of Helium as somewhat similar to how an algorithmic stablecoin network (such as Terra) would operate. The token HNT is burned to pay for Data Credits (DC), denominated in USD. One data credit is equal to USD $0.00001. In this sense, 100,000 DC would be equal to USD $1. Anyone is able to view the list of fees that are used in Helium. The most common transaction in Helium would include Hotspots sending or receiving IoT data, which costs 1 DC per 1 transfer of packet data. If hotspots needed to send and/or receive 100,000 packets of data and held 1 HNT in their wallet (worth USD $10 at the time), the user would burn 0.1 HNT to receive 100,000 data credits, enough to pay for 100,000 transfers of data to IoT devices.
Now we understand how the economics of the network works, we can dig in a little deeper to what is actually going on in the network right now. As of June 2 2021, there are 48,319 hotspots on Helium. Using the Helium block explorer, in 24h we calculated there to be ~200k transactions. In 30 days, extrapolated this would mean 5.9m transactions and in 365 days, extrapolated this would mean 71m transactions. Using the Helium block explorer, we can see that there were 22.5m DC spent in 30 days. In USD terms, that means that $225 was spent from users sending and receiving data across IoT devices in 30 days. If there are 5.9m transactions per month and this results in $225 USD of HNT burnt (for use as DC) — this means that every 26k transactions generates $1 USD (in other words $1 USD amount of HNT is burned). We can plug in the above current network activity and model it to find out just how much $USD will be used to buyback and burn HNT.
As you can see, a 100x in transaction growth on the Helium network is likely to lead to $270k worth of HNT being burned from circulation annually. Not only that, but stakers stand to earn between 6–36% APR annually as well. This means that there is demand for HNT to buyback and burn when network activity increases and stakers stand to benefit from this the most as their HNT stack increases over time from the staking rewards they are earning. In the past 30 days, the amount of hotspots that are connected in the Helium network increased from 34,550 to 48,130 (39% MoM). If the demand for hotspots continues at this monthly growth rate (CMGR) there will be 5,340% more hotspots than there are today by the end of the year (1.8m). One constraint of the Helium network is that sometimes there is so much demand there is not enough supply of Hotspots from manufacturers. However, more demand for hotspots over time will lead to economies of scale for hotspot manufacturers and is likely to entice competitors to enter the market to fill the demand. This in turn, translates to cheaper prices for hotspot buyers, meaning they can recover their initial costs (hotspot purchase) faster. Our friends at Multicoin capital called this the Flywheel Effect.
One small remark about the original Flywheel Effect envisioned by Multicoin is that it does not take into consideration the possibility of earning staking rewards (due to the removal of hotspots out of the consensus group). HIP-25 shifts 6% of inflation (consensus rewards) from hotspots to HNT stakers. This in turn, will lead to faster economies of scale for hotspot manufacturers and result in lower hotspot costs for network participants as the hotspots that will be created in future can become ‘dumber’ (i.e. not need to be built to understand the intricacies of consensus). The mining ROI mentioned in the original flywheel effect still applies to hotspots, the only change is that 6% of the hotspot mining ROI will now be earned by users staking HNT to secure the network. If anything, the flywheel effect accelerates with HIP-25 as hotspots will become more minimal and therefore cheaper to buy, thanks to specialised workers (validators) securing the network with specialised infrastructure. One might think of HIP-25 as an efficient re-allocation of resources.
We can hypothesise a consensus rewards model where delegation is possible (note: delegation is NOT possible in phase 1) to display what the offset might look like (ignoring other rewards hotspots earn). If the price of HNT and staking APR remains constant (est. 18%), we ignore the time value of money and assume that hotspot prices will come down to $100 (due to economies of scale) we can model the Proof-of-Stake economic equivalent to Proof-of-Coverage (i.e. what it takes for new participants to recover their initial investment).
Using the hypothesised model, if governance decided to activate delegation for HNT stakers, PoS economics become more attractive than PoC economics (disregarding other hotspot rewards e.g. data transmission) once the network reaches 179,000 hotspots. As of time of writing, there are 52,232 hotspots (growing 39% MoM as mentioned above). Helium’s transition to a PoS is a win-win for the network on the whole, introducing better network economics and performance through the introduction of Proof-of-Stake. It is important to know that this PoS model assumes delegation is possible, whereas right now delegation is not possible (nodes cannot stake less or more than 10,000 HNT from one address). In the future, governance might vote to turn on delegation when the Proof-of-Stake network matures. It is important to note that this model has many assumptions and disregards hotspot rewards earned through data transmission to IoT devices. Hotspot rewards earned through data transmission can be very inconsistent and are therefore ignored in this simple model.
The Demand-Side Helium Flywheel Effect — Companies Purchasing DC to Use Helium Network
The demand-side of HNT comes from IoT companies wanting lower cost networking services globally for their devices that do not require a lot of bandwidth. If a customer were to use a cellular modem for their IoT devices, they would pay 1000x more than if they connected to LongFi and have 200x less range. The benefits of IoT devices being able to connect anywhere in the globe where hotspots are available at a fraction of the cost are profound. The business model for Helium is B2B. Customers are companies that have low-bandwidth devices and want to connect to Helium for the cost-savings compared to connecting to a cellular modem. For example, Lime uses Helium to track the location of its scooters. Companies such as Lime are growing at a similar rate to Helium Network, expanding to countries worldwide. As more scooters and hotspots are set-up across the globe, more Data Credits will need to be burned from HNT in order to use the LongFi network. Helium already has 14 multinational companies using its LongFi network.
Whilst most companies that are using the Helium network now are Western-based, there has been a surge of new hotspots being set-up in China in the past two months (May-June 2021). As new geographies grow and more hotspots are set up across the globe thanks to crypto-economic incentives, it becomes more viable for multinational companies to utilise Helium’s services across borders (e.g. to track an IoT across many countries in Asia).
As more hotspots come online on the Helium network, the range of the network increases, making the LongFi network more appealing for companies. This could be considered a Flywheel effect on the demand-side.
To conclude, we are very excited that Helium is transitioning to a Proof-of-Stake network and that we have the opportunity to be one of the first validators supporting it. We are long-term believers in Helium and can’t wait to help the network scale to reach its full potential. Hotspots for IoT devices are just the beginning for Helium. Helium governance recently passed HIP-27 to create the first consumer-owned 5G network in the world on Helium network. In the not so distant future, anyone with a phone may be able to connect to the Helium network’s 5G hotspots and save costs.
Helium’s ambition to launch new technologies by using crypto-economic incentives to enable consumer-owned economies is one Chorus One fully supports. Stay tuned for a future announcement on how HNT holders can stake their assets with Chorus One.
Our content is intended to be used and must be used for educational purposes only. It is not intended as legal, financial or investment advice and should not be construed or relied on as such. The information is general in nature and has not taken into account your personal financial position or objectives. Before making any commitment of financial nature you should seek advice from a qualified and registered financial or investment adviser. Chorus One does not recommend that any cryptocurrency should be bought, sold, or held by you. Any reference to past or potential performance is not, and should not be construed as, a recommendation or as a guarantee of any specific outcome or profit. Always remember to do your own research.
Chorus One is offering staking services and building protocols and tools to advance the Proof-of-Stake ecosystem.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
The Chainlink 2.0 whitepaper was published on April 15th. Chainlink 2.0 aims to create a decentralised metalayer through hybrid smart contracts by having a large number of oracle networks serve users on an individual basis. The end goal of this, would be to have smart contracts interact with multiple oracles, just as users interact with multiple APIs in web2 today. In essence, Chainlink wants to take as much load off of smart contracts as possible. The DeFi metalayer will look something like an off-chain outcomes data factory. Large amounts of data will flow into Chainlink oracle networks and there will be large amounts of nodes offering more specialised services to report on complex values that DeFi smart contracts will call for. Developers will have the flexibility to pick and choose what oracles they need, which in turns allows them to simplify their smart contract code.
The way Chainlink generates one standardised value to send to a smart contract is by aggregating all values it receives from individual nodes for a given variable. A service level agreement (SLA) normally defines how much an individual node can deviate from the aggregated result considered to be correct by the network (usually ~1%). Values are aggregated by the oracle and a median value is sent to a smart contract. This means if there are over 50% of nodes reporting a false value, this false value will be reported to a smart contract (which could have detrimental effects on the functioning of the smart contract it has been sent to). Nodes could have incentive to deliberately report false values if it is in their financial interest to do so. For example, nodes could have information asymmetry if they report false values of crypto-assets and conduct arbitrage across different exchanges reporting different values of crypto-assets (that they have contributed to). There are many different options or reasons that a node might have to report a false value to an oracle. Nodes can also be bribed to report a false value for the benefit of another agent.
Chainlink uses implicit and explicit economic incentives to ensure oracle nodes do not behave maliciously. Explicitly, Chainlink requires two ‘deposits’, one deposit that can be slashed for reporting an incorrect value not agreed upon by the aggregate network and another deposit that can be slashed for falsely reporting that a network of nodes have collectively reported a false value to an adjudicator known as a ‘second-tier’ (more on this later). Implicitly, Chainlink assumes rational economic actors (nodes) will send correct values to oracles because it is in their best interest to do so (i.e. there is an opportunity cost of rewards a node misses out on for behaving maliciously). Implicit incentives are known as the ‘future fee opportunity’ (FFO) in Chainlink. Chainlink are aiming to measure implicit incentives with their ‘Implicit-Incentive Framework’, a revolutionary attempt at quantifying opportunity cost of nodes that includes a node’s performance history, data access, oracle participation and cross-platform activity (e.g. nodes that might be on other networks such as Chorus One and how they perform on their with regards to downtime, slashing etc.). In fact, Chainlink has gone so far as to create an equation to find the implicit incentives of nodes, which can be found below:
This formula defines why a node in Chainlink would implicitly continue to report correct values to oracles because if they do not, they stand to lose their future fee opportunity (found in the equation above).
An interesting point to note about implicit incentives from Chainlink’s whitepaper is that of ‘speculative FFO’. New nodes that go live on Chainlink are betting that their expenses will be outweighed by their future fee opportunity. In essence, those running a node on Chainlink in the early stages are taking a speculative bet on the fact that they will earn considerable fees in the future. The ‘speculative’ side of FFO (i.e. betting on the future success of Chainlink) multiplies the implicit incentive for nodes to ensure they are behaving correctly because they have a stake in the network performing well. The speculative FFO is an interesting take on what the true value of this implicit incentive is. At Chorus, we believe the value of this implicit incentive is only just now becoming more understood by networks. This implicit incentive can be further strengthened by giving node operators more skin-in-the-game. For Chainlink, an existing network, this could mean an airdrop to node operators of x amount of tokens to ensure they care about the success of the network. An even greater implicit incentive might be for Chainlink to offer supercharged rewards (i.e. 2x rewards such as can be found in Mina) to node operators who have the greatest reputational equity, which would be a positive externality for the entire crypto ecosystem as nodes want to increase their reputation across all networks. For new networks, the implicit incentive could be strengthened by offering tokens to node operators in private sales to make sure they have further skin-in-the-game from the inception of a network. Incentivised testnets can also work well for new networks to encourage validators to get actively involved. The earlier a validator has skin-in-the-game and the larger that skin is early-on, the more attention a validator is likely to pay to the future success and security of the network. We will discuss the importance of implicit and explicit incentives for node operators on other networks in greater depth in a future article.
Chainlink 2.0 introduces the concept of super-linear staking (or quadratic staking) to ensure nodes are incentivised to always report correct values (as agreed upon by other nodes). Chainlink has essentially created a second layer (known as tier in the whitepaper) that will be used as a backstop if a watchdog believes that an aggregated value being reported by a network of nodes is false. A watchdog is any node in the first-layer that alerts the higher second-layer when they believe a reported value is wrong. You can think of this system like a ‘dibber-dobber’ system. A watchdog is like a student in a class (tier 1) that the teacher (tier 2) trusts will always report back to him/her if the rest of the class misbehaves. To continue with this analogy, let’s say a teacher is leaving for 10 minutes and is offering a candy reward to all students if they do not misbehave when he/she is gone (this is like an explicit incentive deposit for all students) and a second reward for reporting if >50% of the class misbehaves (reward is given by stripping the explicit incentive deposit from misbehaving students). When the teacher leaves, over half of your class starts misbehaving, which means you cannot work because you are distracted. However, your misbehaving classmates want the best of both worlds, they want to misbehave and earn the reward (keep the deposit) from the teacher. Now let’s imagine that anyone can tell the teacher when over half the class is misbehaving to earn a reward but the teacher already has some randomised priority of how she will distribute the rewards from the explicit incentive of misbehaving students to a ‘winner-take-all’ system (i.e. only one student receives all the rewards ‘slashed’ from misbehaving students for dobbing on their peers). Now let’s imagine that the misbehaving students try to convince the behaving students to not report misbehaviour. If only 1 student reports misbehaviour, they will earn all of the rewards (deposit) of misbehaving students. Therefore misbehaving students need to pay more than the maximum reward one behaving student could receive to all behaving students. Keep in mind the priority, rewards are not even and therefore all rewards for a correct report of misbehaviour will go to one student. This is the super-linear quadratic effect of Chainlink 2.0 staking. It becomes much dearer to bribe behaving students (nodes) in the classroom because the maximum amount required to bribe an individual student is the maximum reward a student could receive from overall slashing of misbehaving students. The minimum adversaries must pay to ensure incorrectness is the maximum reward to every behaving student because if only one student tells the teacher, they stand to receive all rewards of misbehaving students (that’s a lot of candy). If rewards of misbehaving students were distributed equally, it would be much cheaper to convince (bribe) behaving students to falsely report to the teacher. In this sense, the tier system (having a second tier that has the final say) and watchdog priority (having a dibber dobber with some priority that stands to earn all rewards of misbehaving nodes for correctly reporting they are acting maliciously) ensures data integrity of reported values in Chainlink.
Using super-linear staking and adding capped future fee opportunities per node contributes to economies of scale that can be achieved by Chainlink. Each new user that joins a decentralised oracle network lowers the cost for other users on that network and lowers the average cost per unit of economic security. Chainlink supposes the average cost per dollar of network security is the future fee opportunity / number of nodes. If in future Chainlink decides to cap the future fee opportunity at x per n, any fees that are > x per n will be reserved for new nodes that stake in that network. This achieves economies of scale because it is cheaper for an existing user to join an already existing network rather than to create their own (i.e. fees signal where nodes should be, nodes stake and join that network and security is higher). Due to super-linear staking, the more nodes that exist in a network, the more economically secure a network becomes (quadratically!). Economic security is provided by stake, nodes provide this stake and this can be used to find a node’s average cost per dollar of economic security (how much one node contributes to security in a network, the cost is lower as more nodes join a network when FFO is capped and hence economies of scale are found). Therefore there is an implicit incentive in itself for Chainlink to make sure it grows its staking business. The more total value locked grows, the more smart contracts that need oracles, the more funds that can be exploited, the more at risk Chainlink is when oracles are exploited to drain smart contracts, the more reputational risk Chainlink has, the more funds they will require nodes to stake, the more secure the network gets, the less expensive it is for one dollar of stake to secure the network, the more economies of scale Chainlink achieves.
In any PoS network, it is critical that there is enough at stake of economic actors participating in the network to ensure they do not misbehave. To have more assets at stake in any network, barriers need to be lowered. Delegations were not mentioned in Chainlink 2.0, meaning holders of the $LINK token cannot natively delegate their assets to a node operator such as Chorus One. Currently, the only way for users to earn staking rewards in Chainlink 2.0 is by running their own node to report values for jobs that are assigned to them. However, delegation protocols are being worked on. For example, Linkpool are working on democratising staking rewards for $LINK holders via staking pools. The demand for $LINK delegation has been high since the inception of this service by Linkpool. We expect this demand to continue when Chainlink 2.0 goes live, especially because Chainlink 2.0 will likely require most nodes to have some collateral (stake) in order to report values for jobs. Delegation in Chainlink 2.0 gives users the opportunity to earn staking rewards on otherwise idle $LINK and allows nodes to report values on more jobs to increase their future-fee opportunity (FFO), both of which are a net positive for Chainlink. It is very possible that delegation demand could translate into a new era of $LINK liquid staking innovation.
To conclude, Chainlink 2.0 is secured by implicit (e.g. FFO) and explicit incentives (e.g. super-linear staking). The importance of oracle security has never been higher, as the value that oracles secure in DeFi grows every day. Any oracle exploitation is disastrous for DeFi, so it is important oracle networks such as Chainlink improve their security at the same rate that DeFi grows. The proactive approach of Chainlink to change their economics to capitalise on network effects (incentives to run more nodes) and economies of scale (security becomes cheaper as more nodes join) is timely and likely to sustain Chainlink’s position as an oracle market leader well into the future.
On February 10 the Solana community passed a vote to enable inflation on mainnet. SOL holders delegating their tokens to validators on the network will now start to earn staking rewards.
Solana is a composable, unsharded blockchain focused on maximizing transaction throughput through various hard- and software optimizations. Like most smart contract platforms, the Solana network is secured through Proof-of-Stake.
This post is an overview of the staking economics on Solana going into the factors that influence rewards, as well as the risks and restrictions associated with staking SOL tokens.
Staking-related updates in Solana happen at epoch boundaries. An epoch is the length of a certain amount of blocks (in Solana: “slots”) in which the validator schedule of Solana’s consensus algorithm is defined. To stakers this means that beginning and stopping to stake, as well as reward distribution, always happen when epochs switch over. An epoch is 432,000 slots, each of which should at a minimum take 400ms. Since block times are variable this means epochs effectively last somewhere between 2–3 days.
The SOL staking lifecycle is divided into three phases:
Staking rewards on Solana are determined by a variety of factors, some of which are related to the chosen validator, while others depend on the global network state. Rewards are automatically added to the active stake to compound, which means withdrawing earned rewards also requires the cooldown phase to pass.
To ensure that validator nodes act according to the rules, penalties may be enforced by Solana’s protocol in the event of provable misbehavior. In Solana, this relates to voting on conflicting forks in the consensus process. Slashing in Solana would be applicable to both delegators and validators. In the early phases of the network, slashing is not activated yet. The Solana team is exploring models in which the slashed amount would adjust based on correlated faults, as well as based on the duration since the last vote (to discourage validators waiting to vote to avoid getting slashed).
Changing the validator node you are delegated to or staking with multiple validator nodes on Solana is easily possible through splitting and merging stake accounts. Read the documentation below to learn more.
You can stake your SOL tokens on Solana mainnet and earn staking rewards with validators by following the official staking delegation guide. Currently, staking is supported e.g. through the SolFlare wallet built by Dokia Capital.
Chorus One operates a highly available Solana validator and is among the top contributors to the protocol, e.g. as part of the Tour de SOL competition, where we uncovered multiple vulnerabilities in preparation for getting Solana mainnet ready. By delegating to our node you are supporting our work and involvement in Solana.
To observe the current blockchain state and validator nodes, visit the Solana Beach block explorer by Staking Facilities. To learn more about Solana, visit the official website.
In case you have questions, feel free to reach out to reach out to us on Telegram, Email (support[at]chorus.one) or through our live chat feature on our website.
This post was created based on Solana’s official documentation and this post on the Solana forum. Thanks to Dave from my team and Eric from Solana for clarifying details and answering my questions.
Originally published at https://blog.chorus.one on February 11, 2021.
Chorus One has received a joint grant from the Celo Foundation and the Interchain Foundation to develop the building blocks for a bridge that will allow Inter-Blockchain Communication (IBC) between Celo — an EVM-based, mobile-first blockchain platform focused on financial inclusion — and networks built on the Cosmos SDK, such as the Cosmos Hub.
A bridge built upon these components will enable users of the Celo platform to tap into the vast ecosystem of IBC-compatible blockchains and vice versa. Some exemplary use cases include bringing the Celo cUSD stablecoin to the Cosmos ecosystem, as well as including Cosmos-based assets like ATOM, BAND, LUNA, or KAVA in the Celo Reserve.
At Chorus One, we are committed to the “Internet of Blockchains” vision and believe we’re still in the first inning of blockchain interoperability. As of today, we are already operating validation and other node infrastructure on 14 different live networks. Currently, these are still mostly isolated, but in the upcoming months various interoperability efforts such as ChainBridge, Peggy, Solana’s Wormhole bridge, as well as ambitious protocols like IBC — which will go live on the Cosmos Hub soon via the Stargate upgrade — will usher in a new era of cross-chain decentralized applications.
Our work on WASM-based light clients (see also our previous Substrate <> Cosmos SDK project here) represent our first contributions to this space. Our goal with these efforts is to make it easy to add support for new blockchains and upgrades to clients without requiring the full governance process to establish new connections in the IBC ecosystem.
“As one of the top validators on both the Cosmos and Celo networks, I’m absolutely thrilled to see Chorus One working to connect the Cosmos and Celo ecosystems with a fully trustless bridge between these instant finality chains. The work adds to their growing body of past contributions to both networks, including the excellent Anthem staking platform.”
Marek Olszewski — Co-Founder at Celo
We are excited to contribute to realizing a world of interconnected blockchains and would like to thank the Celo Foundation and Interchain Foundation for their support.
Our CTO Meher Roy will present on this project that we aim to deliver in Q1 2021 during the upcoming Interchain Conversations online event taking place Dec 12 and 13. Register here in case you are interested to learn more about our work and other awesome initiatives in the wider Cosmos ecosystem.
Chorus One is offering staking services and building protocols and tools to advance the Proof-of-Stake ecosystem.
We provide staking services on both the Celo blockchain, as well as on multiple Cosmos networks; specifically: the Hub, Terra, Kava, Band, Secret Network, and Microtick. Visit our website to learn more and support our work by staking your tokens with us.
Website: https://chorus.one
Anthem Staking Platform (with support for CELO staking on Ledger): https://anthem.chorus.one
Monthly Newsletter: https://chorusone.substack.com
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Originally published at https://blog.chorus.one on November 13, 2020.
