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.

A Word on Epochs

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.

Staking Lifecycle

The SOL staking lifecycle is divided into three phases:

• Warmup: When sending a staking transaction to the network, stake first needs to activate before it influences the consensus process and begins to earn rewards. The time this takes is dependent on how much SOL is beginning to stake relative to the SOL already at stake. Up to 25% of the SOL already at stake can warmup per epoch and start to earn staking rewards. In the best case scenario, when a reasonably high percentage of SOL is at stake and there is little new stake entering, this will usually mean that stake will become active in the upcoming epoch that the staking transaction was sent. In times of high stake turnover, e.g. at network launch, stake will progressively activate meaning that only a fraction of stake will enter the validation stage each epoch.
• Validation: Stake in this stage is actively influencing validator voting power and is thus eligible for both rewards and penalties, which will be explained in coming sections of this article.
• Cooldown: When deciding to stop staking, staked SOL needs to pass a period during which stake remains eligible for penalties before it becomes liquid. Similar to the warmup phase, this happens gradually and works in the same way that warming does, with at maximum 25% of the SOL at stake being able to pass the cooldown phase per epoch.

Rewards

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.

Network

• Inflation: Solana has a deflationary issuance schedule starting out at 8% for the first year and decreasing by 15% until it reaches 1.5% after around 11 years, from which point on it will remain constant. Inflated SOL supply is distributed to those staking (95%) with a small portion going into a treasury to fund development of the Solana ecosystem (5%).
• Staked Supply: Newly issued tokens are rewarded to those staking, which means that if there is a lower percentage of the circulating SOL supply at stake, those staking will receive higher rewards.
• Transaction Fees: Transaction fees in Solana are dynamically adapting based on the load in the system. 50% of fees is burned, which indirectly benefits SOL holders as this lowers the overall SOL supply. The rest is retained by the validator proposing the block containing the transaction.
• State Rent: Accounts and contracts on Solana are charged rent in proportion to the space they occupy. 50% of the rent the protocol collects is burned, decreasing the overall SOL supply, and the rest is distributed to validators as part of the transaction fees.

Validator-Specific

• Commission Rate: Validators can set a commission fee in the protocol. This percentage is the proportional cut that validators receive from delegated stake for operating the node infrastructure on behalf of token holders.
• Uptime: Validator nodes earn credits for blocks on the majority fork they successfully voted on. Stakers earn a portion of inflation rewards based on their proportional stake times the percentage of blocks their validator successfully voted on. As an example, if a validator missed to vote on 10% of blocks, its delegators will only receive 90% of the staking rewards.

Penalties

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).

Switching Validators

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.

How to Stake and Further Resources

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.

The Interchain Cometh

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.

About Chorus One

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.

Solana has developed from an initial idea of how one could timestamp events in a distributed setting (Proof-of-History) into a full-fledged, scalable smart contract platform that is able to host high throughput applications supported by an ever-growing ecosystem of validators and developers.

As one of the first validators engaging with Solana, we wanted to write a post about our view of the ecosystem and how it came to be. To do that, I’d like to begin with an anecdote:

In the summer of 2019 in Berlin, back when in-person conferences were still a thing, I was at an afterparty of ETH Berlin with some other early Solana validators including Aurel from Dokia Capital, who likened Solana to a YouTube clip of a guy starting a dance party at a festival. Now, more than a year later, it seems like that analogy is holding up well!

Building the Team and Raising Investment (Video: 0:00–1:10)

In the beginning, Anatoly managed to convince his co-founders of the Proof-of-History idea. The legend says it may have been after a round of underwater hockey, or maybe surfing at Solana Beach above San Diego, which ended up providing the project’s name. Together, they raised a seed round in March 2018, which allowed them to hire a team — many of the which they had worked with before at companies like Qualcomm.

With some money in the bank, the team started to build at breakneck speed and hasn’t stopped since. The ambitious task to launch a performant blockchain that doesn’t require sharding relies on 8 core technologies, many of which had to be built from scratch.

Engaging the Validator Community (Video: 1:10 — ~1:30)

As soon as the core features of the Solana blockchain were there, the team began launching testnets. Realizing how important external validators are, the Solana team took a proactive approach and inspiration from the Cosmos ecosystem — launching a multi-staged incentivized testnet competition titled Tour de SOL. This competition has been ongoing ever since and has seen multiple attacks and bugs that were subsequently fixed ensuring that the mainnet, which launched in March 2020, became and remains a stable and secure environment for application developers to build upon.

Kickstarting the Ecosystem of Applications (Video: 1:30+)

Speaking of applications, as much as we ❤ validators, no blockchain is of any use if there is nothing running on top of it. Solana has from the get-go been focused on delivering something of value and engaged with projects building or seeking to build decentralized applications.

One of the first projects that announced its plans to migrate was Kin. In summer 2020 the biggest news so far hit when Project Serum, an ambitious project seeking to build DeFi applications based around a CLOB (central limit order book) DEX on Solana plus a bridge to Ethereum (learn more about Wormhole here), was announced.

For a breakdown on Serum, and its role within the Solana ecosystem, check out the recent Unchained podcast episode with Sam Bankman-Fried, the CEO of FTX and Alameda Research, and Anatoly Yakovenko, the co-founder and CEO of Solana Labs.

How to Get Engaged with the Solana Ecosystem

Various programs including the Solana Accelerator, as well as the Solana Foundation continue to support application developers that are looking for a platform to build scalable, decentralized applications. If you plan to join the Solana ecosystem, make sure to check out the upcoming hackathon (starting Oct 28).

Information on the network can be found on explorers like our very own Salty Stats or Staking Facilities’ Solana Beach. If you are planning to stake SOL, we recommend the SolFlare wallet.

About Chorus One

Chorus One is offering staking services and building interoperability solutions for decentralized networks.

Our validator node is live on the Solana mainnet. Support our work by delegating to us and make sure to earn staking rewards once they are activated. Learn more here.

Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone

About Solana

Solana is a web-scale blockchain with speeds up to 50,000 transactions per second powered by Proof of History.

Website: https://solana.com/
Twitter: https://twitter.com/solana
Telegram: https://t.me/solanaio

Originally published at https://blog.chorus.one on October 9, 2020.

The Celo mainnet recently launched with over 50 validating entities participating after a successful multi-stage incentivized testnet competition. Celo is an open platform seeking to give access to decentralized financial tools to anyone with a mobile phone. Part of that vision is a sophisticated on-chain governance process that decentralizes power over protocol features and parameters, including Celo’s stablecoin stability mechanism. This post will provide an overview over the currently implemented governance mechanism that was already used to activate transfers and staking rewards on the network.

Phase 0: Submitting a Proposal

Any Celo account can submit a proposal to change features or parameters on Celo by sending a transaction containing all the necessary data such as a title and link to the proposal description together with a deposit of currently 100 Celo, the network’s native token, to the network. Once issued on-chain, proposals enter a queue and Celo holders can signal their belief that this proposal should be voted on by the entire network for up to 28 days [1]. Locked Celo tokens can simultaneously partake in staking with validator groups, as well as signaling and voting in governance.

Phase 1: Approval

Every day, three proposals with the highest amount of upvotes, measured in locked Celo signaled by token holders, can leave the proposal queue and move into the referendum stage in which the entire network will decide on whether the proposal should be implemented.

However, the referendum stage is not initiated automatically. There exists a multi-signature address that must approve the promotion of proposals to the referendum stage (“the approver”). This step is an extra protection to quality check proposals before they are voted on by Celo holders. At launch, the approver is controlled by the Celo Foundation, the plan is to decentralize it to be controlled by a DAO.

Phase 2: Referendum

Once approved, proposals enter a two day referendum stage [2]. During this phase, Celo holders are able to vote “Yes”, “No”, or “Abstain” on each proposal. Votes are weighted by the accounts locked Celo balance. There is currently no delegated voting contract meaning every Celo account is responsible to vote themselves. When a proposal enters the referendum phase, the deposited proposal collateral can be reclaimed by the proposer.

At the end of the referendum stage, the blockchain executes a tally of votes to determine whether the proposal has met the passing criteria to be implemented on-chain. This passing criteria consists of two factors:

• Adaptive Quorum: A certain percentage of locked Celo needs to participate in a proposal for it to be implemented. This percentage is dynamically adapting over time to reflect participation levels in previous proposals. As an example, if participation levels have not been met for a proposal, the mechanism will lower the required quorum for the next proposal to reflect the voting behavior of Celo holders [3].
• Voting Threshold: The second requirement for a proposal to pass checks if the proposal has reached the needed relative amount of “Yes” in relation to “No” votes. Celo defines a constitution consisting of “Yes” vote threshold values that need to be met to update specific protocol parameters or essential contracts. As an example, changing the maximum amount of validator nodes in the network requires more than 70% of “Yes” votes measured in locked Celo to be accepted [4].

Phase 3: Execution

If the tally at the end of phase 2 concludes that the proposal has been accepted, there is a final stage in which the proposal needs to be executed on-chain. This can be done by any Celo account by issuing a special transaction on-chain. This transaction then upgrades the protocol code meaning the change is implemented. Should no Celo account issue the execution transaction for three days, the proposal will automatically be rejected.

Hotfixes and Hard Forks

Finally, Celo’s governance protocol also specifies a different upgrade path for hotfixes like urgent security patches. For such upgrades, a quorum of validators [5] and the approver need to approve the hash of the hotfix proposal to execute updates immediately. Additionally, upgrades that require a hard fork, such as changes to the underlying consensus protocol, will set a “Minimum Client Version” parameter on the chain to inform nodes about the software version required to correctly operate on the network.

How to Participate in Celo Governance

At Chorus One we seek to empower token holders to shape the networks they are invested in. Our staking platform Anthem will soon support Celo and allow Celo holders to stake, vote, and get access to portfolio data including staking rewards and transaction history.

Chorus One offers staking on Celo. Support our work by voting for our validator group and earn rewards knowing your tokens are staking on infrastructure that has been securing millions of dollars for more than a year. Visit https://chorus.one/networks/celo to learn more.

Thanks to zviad from Wotrust and Tim Moreton from C Labs for clarifying a bunch of the questions I had writing this post.

Celo Governance Online Resources

Governance Forum: https://forum.celo.org/c/governance/12
Governance Proposals Statistics: https://thecelo.com
Governance Documentation: https://docs.celo.org/celo-codebase/protocol/governance
CLI Instructions: https://docs.celo.org/celo-gold-holder-guide/voting-governance

[1] In practice Celo utilizes epochs to structure time. Every epoch consists of a certain amount of blocks targeting to correspond to a day in human time.
[2] An extension of this parameter to 2 weeks is already in discussion.
[3] Source: mainnet adaptive quorum code (formula)
[4] Proposals can even pass when the quorum was not met. This can take place when the ratio of “Yes” votes exceeds the constitutional threshold after counting votes that were missing to reach the quorum as “No” votes, i.e. if
Yes / (Yes+No+Votes Missing to Reach Quorum) > Constitutional Voting Threshold.
(sources: mainnet constitution code (parameter values), proposals contract code)
[5] ⅔ + 1 of all elected validator nodes.

Originally published at https://blog.chorus.one on May 20, 2020.