Go to https://solflare.com/access, connect your account and navigate to Staking tab
Go to https://solflare.com/access, connect your account and navigate to Staking tab
Click on CREATE ACCOUNT, enter the amount of SOL you want to stake, search for Chorus One and click on Stake
Select Native SOL Staking
Approve the transaction in your wallet. You're now staking with Chorus One!
.svg){kind=icon}
Proof of History (PoH) is a permissionless, network-wide source of time that functions before consensus. PoH is not a consensus process, but rather a cryptographic approach for tracking time in a blockchain network by establishing timestamps.
Some include: SolFlare, Sollet, Phantom, Math, Atomic, Exodus and Zelcore.
The boom in the DeFi and NFT spaces have pushed fees on Ethereum extremely high causing crypto users to seek other options like Solana.
Solana is one of the most efficient blockchains. It can attain over 50k transactions per second with its Proof of History approach while limiting expenses to $10 per 1 million transactions.
The MEV supply chain is critical to the future performance and business models of the Solana network. Solana is in a phase of actively searching for, and ultimately choosing its MEV supply chain. One approach is to replicate the model established on Ethereum, building a searching and block-building marketplace. This path has multiple downsides, such as artificially introducing a global mempool that would increase Solana’s latency, and may also increase the risk of centralization and censorship.
We’re happy to announce that Chorus One has released a whitepaper today where we contrast the most relevant characteristics of Ethereum and Solana; review some of the features of the block-building marketplace model, i.e “flashbots-like model”, and what retrofitting it onto Solana would entail.
Given the particularities of Solana, we also propose an alternative to the block-building marketplace: the solana-mev client. This model allows for decentralized extraction by validators, through a modified Solana validator client, capable of handling MEV opportunities directly in the banking stage of the validator. Along with the whitepaper, Chorus One is also releasing an open-source prototype implementation of the approach detailed inside the whitepaper itself.
The client can be run by any validator. Even small validators or those with no specific expertise can benefit from MEV rewards by choosing to run the solana-mev client. That means the validators will be able to execute MEV strategies as they appear in their slot, in contrast with the current competitive aspect of searching, which results in a few winner bots extracting the value.
The model shrinks the incentive for independent bots to spam the network which ultimately contributes to episodes of intense traffic, as most of them send transactions targeting the same MEV opportunities.
Given that not all MEV strategies can be implemented inside the validator, independent searchers will continue to play a relevant role in the MEV space on Solana. That is guaranteed by their advantage of quickly building and updating sophisticated strategies, as well as expanding their focus to newly deployed programs and pools. This includes long-tail MEV.
In summary, the MEV client enables permissionless and decentralized extraction that benefits the ecosystem through transparent and ethical strategies, as well as increased financial returns for network participants.
For a comprehensive overview of the motivations and the model, please refer to the whitepaper here.
Navigate to https://phantom.app/ to create or restore your Solana wallet.
If you do not have a wallet yet, you should create a new wallet and note down the seed phrase and store it in a safe place. Follow the onscreen instructions and make sure to fund your wallet with some SOL tokens before you proceed with staking
Make sure to not share or lose the secret recovery phrase (mnemonic)
If you already have a wallet, you can restore it on Phantom using the associated seed phrase. Follow the online instructions to restore your SOL account.
Once you entered the 12 or 24 words you can then restore your wallet and optionally set a password on your account.
Once you have funded your Phantom wallet with Solana, you can click on the Phantom extension to see your account details.
Once logged in, you will be able to view all the SPL assets that you possess. If you do not already have SOL tokens you can get them from a friend or buy them off-exchange and transfer those to your wallet.
Once you do that you will be able to see the SOL tokens in your wallet.
Go ahead and click your SOL balance and on the top right, you will see 3 dots. Click the dots to reveal the staking menu. Click the menu-item Stake SOL
You will be shown a list of validators along with a search button. Go ahead and type Chorus One in the search panel. Chorus One's validator will show up. Go ahead and click on the validator name.
Choose the amount of SOL you would like to stake and click on Stake
Make sure to leave some SOL in your account to pay for the transaction fees
Once you click Stake you will immediately see that your wallet is staking your SOL to your chosen validator. You can also click on the View Transaction link to see the status of your transaction in a blockexplorer. If you look at the Confirmations field you can slowly see it increasing from 0 to 32. Once it reaches the MAX number of confirmations your transaction gets added to the blockchain
Make sure to note down the transaction hash or the link provided on the screen. This allows for easier debugging in case of a failed transaction.
After your transaction is successful you can go back to your Phantom wallet, click on the Solana balance, and see your stake accounts.
Congratulations! You are now staking your SOL!
If you click on your stake accounts you will see that your stake is activating. It takes 1 epoch for your stake to activate. An epoch in Solana lasts for approximately 2-3 days. After this period your stake will show up as active and will start earning rewards.
If you click on your stake balance, you will be given the option to unstake. Unstaking also takes an epoch. Once you click Unstake your stake will start deactivating and will become fully inactive after a maximum of 3 days (1 epoch).
After the stake become inactive you can withdraw it back to your Solana account
At Chorus One, we pride ourselves in being a full-stack partner to the protocols we choose to operate and support. This goes beyond the highly available infrastructure we provide to secure and maintain networks. It includes assisting in ecosystem-building via our ventures and business development teams, as well as participating in network governance and — most notably — deep research. Since our inception, we have been at the forefront contributing to core topics of interest in Proof-of-Stake such as liquid staking.
In recent months, we have shifted a big part of our research focus onto a complex topic that underpins the core fabric of any crypto protocol: MEV (Maximal Extractable Value). This emerging field deals with the value that can be extracted through reordering transactions in the block production process. (A collection of resources on MEV can be found here).
MEV has become an ubiquitous topic for many ecosystem participants. Primarily being a validator, our position in the network places us at a spot within the MEV supply chain that comes with great power, thus also great responsibility. Generally speaking, our mission is to maximize freedom for crypto users and to contribute to the creation of long-term sustainable, user-owned decentralized network infrastructure. Since MEV is a crucial domain that — if not adequately dealt with — might threaten the mission we are set towards; we recognized that we should leverage our expertise and resources to contribute to the MEV space in a way that ultimately benefits networks and their users.
The goals we want to contribute towards in the MEV space are two-fold. On one hand, we aim to make visible and help minimize extraction of value from users through e.g. front-running, sandwiching, and other exploitative practices. On the other hand, we strive to redistribute revenues from non-exploitative MEV that comes into existence from market inefficiency to our delegators that contribute security to the underlying network.
The rest of this article lays out the core pillars of our approach to MEV providing examples of our existing and planned engagements in the area.
What is MEV and how does it impact networks and their users?
Before deciding how we should engage with MEV, we seek to understand what we are dealing with. We are proponents of the open-source crypto ethos and don’t want to keep the information we are gathering to ourselves, but rather share it with the wider ecosystem. Thus, the first pillar of our MEV policy is Transparency. We are actively researching, building dashboards, and publishing other materials to create a shared understanding and to help lighten up the “dark forest” that is MEV.
Our exemplary work in the MEV Transparency domain: Dune Analytics Ethereum MEV dashboard, MEV Extraction Twitter bot, various MEV-related articles (e.g. our series on MEV on Solana).
How can we help to minimize negative externalities of MEV?
As a result of our research effort, we deeply understand MEV in the context of the ecosystems we are a part of. We recognize that MEV can pose negative externalities to users and ultimately the protocols they are trying to utilize. We are actively engaging to help minimize negative externalities in various ways, depending on how deep our engagement in the respective ecosystem is. This can include creating awareness and participating in the dialogue around MEV, research on related problems, as well as supporting and building solutions seeking to minimize exploitative MEV and to decentralize MEV extraction.
Our work in the Network Sustainability domain: operating and participating in public discourse and communities of block building solutions such as Flashbots, investments in projects seeking to minimize front-running (including e.g. Anoma and Osmosis). We have additional projects in this domain in the pipeline and are looking into operating infrastructure to help decentralize block building and relayer infrastructure.
How can we optimize and distribute MEV rewards to our delegators?
It would be hypocritical to say we are in this for the good of it only. There are clear incentives associated with engaging in MEV. Practically speaking, we are looking to optimize the return we can achieve through MEV and pass it through to our delegators creating a differentiated service while helping to improve network usability, security, and ultimately sustainability via the first two of our MEV pillars (see also Phil Daian’s early post “MEV wat do?” on this topic).
For institutional clients that want to offer staking to their users, we are happy to assist in navigating the space and finding the optimal solutions as part of our white label staking services.
If you are building in the MEV space, are trying to understand how MEV will affect your protocol, or are interested to work with us on research topics, feel free to reach out to us through the appropriate channels:
Research: research@chorus.one
Ventures: ventures@chorus.one
Sales: sales@chorus.one
Blockchains not only need to be technically good. Besides the protocol and implementation levels, a key element in the success of a decentralized system is having different and independent groups using it, operating it, and governing it. The economic incentives in decentralized systems to achieve such participation by all these different groups have gained attention from researchers who are now interested in “tokenomics”, as a new field of study.
In this article, we are going to explore Solana economics, focusing on the stimulus to network node operators, or validators. We conducted an analysis of the inflation model, the costs and rewards to validators and stakers, as well as the current network activity levels. We also estimate the minimum stake required of a validator in order to break-even, and estimate the impact of different market scenarios, considering the most important variables and how they affect validator profitability.
For this purpose, we built the Solana Validator Dashboard and the Solana Validation Cost Estimator.
Solana validators currently earn from two sources:
The Solana inflation design has defined SOL emissions as starting at 8%, and decreasing by 15% every year. The model was activated on February 10th, 2021 with the payment of 213,841 SOL.
As of July 2022, Solana’s inflation rate is around 6.8%. The staking yield is equivalent to 9.1%, as 75% of the total supply is currently staked (i.e. total inflation rewards are distributed to staked tokens only, resulting in a dilution of non-staked tokens). The rate does not reflect the yearly emission rate. It can be considered a target instead, and the mechanism behind it is broken down below.
Solana’s inflation model considers 400ms block times even though it is mentioned on Docs that the current implementation targets block times to 800ms. The recent average is around 650ms but with high variance.
Although Solana remains extremely performant to the everyday user, the difference in slot times directly impacts the economics and business viability of running a validator on Solana. Longer block times will result in smaller rewards, given a smaller number of epochs in a calendar year, decreasing the amount of SOL distributed to network participants.
In every epoch, Solana calculates the number of tokens instantiated for the inflation pool. The result will be the amount of SOL tokens to be distributed to validators and stakers as inflation rewards, according to the voting and staking status from the previous epoch. 0.45 SOL is the approximate amount currently allocated and distributed among eligible validators in each slot — 195 thousand SOL per epoch.
Block times impact inflation rewards as the function will taper the initial rate (8%) given how many slots have passed since inflation activation on Mainnet — as a proportion of how many slots fit in one year.
Considering an average block time of 650 ms, the inflation being distributed in every epoch is equivalent to a 4.1% yearly rate and the stake yield falls to 5.5%, instead of the 6.8% and 9.1% previously assumed.
Also relevant to validator economics will be the commission. In fact, stake owners, a.k.a. delegators, earn the inflation rewards. Validators earn a portion of it represented by the commission. In the plot below, we can see that a common fee for public nodes is around 10%. There are only 81 nodes charging a 5% fee or smaller. 100% commission is assumed to refer to private nodes (100 validators).
Block reward from transaction fees varies according to network activity. Recent average is around 0.01 SOL per slot. Total per epoch increases with voting power, as the number of slots attributed to the validator is based on the proportional stake.
Theoretically, as inflation decreases with time, validators’ rewards would be supplemented by the increase in transaction fees. The assumption can eventually become a truth as the network matures. Some plots below show that currently this is an unfair assumption:
1- The market’s cyclic nature — the number of non-vote transactions will not necessarily be growing over time. Total transactions (vote + non-vote) picks in Oct21, around 180 thousand in one day. And falls to less than 100 thousand transactions in Apr22.
2- Solana network has invested in growing the network of validators. The plot below shows the number of unique rewards recipients (addresses).
3- As a consequence of voting power dilution and lower network activity, rewards obtained from transaction fees decreased for validators in an individual perspective.
We split the cost into i) hardware, colocation, and bandwidth, to host the validator and ii) personnel, which can vary significantly. The official recommendations can be found on the Solana Documentation.
Small Validator
Medium Validator
Professional Validator
The vote is an affirmation that a block it has received has been verified, as well as a promise not to vote for a conflicting block. — Solana Docs
Validators are expected to vote on the validity of the state proposed by the slot leader. A validator node, at startup, creates a new vote account and registers it in the network. On every new block, the validator submits a new vote transaction and pays the transaction fee (0.000005 SOL).
Validators usually own (a portion or the total of) the staked tokens, a.k.a. self-staking. In this case, the cost of tokens depends on the average price of acquisition. For the purpose of the current analyses, we will consider the validators only to own 100 SOL at a US$ 50 price.
The Solana Foundation promotes the growth of the validator set through the Solana Delegation Program. Applications require small validators to achieve the “baseline” criteria, which includes running a node also on the Testnet, in order to receive 25,000 SOL. Those who meet the baseline criteria and also the “bonus” criteria can receive an extra (dynamic) amount in the delegation. A recent post on stake delegation strategies and why delegation programs are needed, goals, and criteria can be found in How can networks nurture decentralization?
In summary, Solana validator’s profitability depends on the current inflation rate, block times — reflected on the number of epochs in one year, the voting power, the total supply, the number of transactions, the cost structure, and the SOL market price.
For the three operational levels stated above, we will look at three different economic scenarios: optimistic, average, and pessimistic, with the average scenario being the closest to the current values.
The average market price in one year is fixed at $50 for the purpose of break-even analysis. Different price scenarios can be evaluated in a further session.
We found that the 40,000 SOL to break even would be a realistic amount for a small validator, on an average scenario, close to current levels. The number grows to 253,000 SOL for the medium setup. A professional validator would need more than 1.3 million SOL staked.
For a validator with a 0.01% stake, we estimate a 25 SOL reward from transaction fees in one year. The voting process costs around 200 SOLs per year for each node operator. Therefore, small validators are dependent on inflation rewards to achieve break-even, and ideally, become profitable. Around 350 thousand SOL staked would be needed to fully cover the voting cost, when considering rewards from transaction fees only.
Considering active stake on August 2nd:
Although the number of validators may be considered high compared to other Proof of Stake networks, 71 accounts are responsible for 57% of the total 365 million SOL staked.
The majority of validators currently stake between 80 and 90 thousand SOL, as seen in the plot below. There are at least 138 (7%) instances of the validator client with stake amounts smaller than 40 thousand SOL, the estimated break-even level for a small validator.
Simulation shows that medium and professional validators are more sensible to fluctuations in the SOL market price than small-size validators. Considering SOL average price in a year to be $75, the break-even level decreased by more than 30% for medium and professional levels and only 7% for small validators. A similar effect is found if the average price drops to $25.
In PoS networks, adopting an accurate inflation model in conjunction with direct incentives in form of delegation is important to:
Solana validators and stakers have seen rewards decreasing with higher block times compared to the projected rewards from the initial inflation model. As additional factors, the network experienced a contraction in non-vote transactions during the latest months and the expansion of the validator set.
According to the break-even levels discussed above, an 8.85% inflation target would be the rate level to reflect an effective 5.5% emission in one year, considering 650 ms block times (6.3% if 550 ms block times). Assuming 75% of total supply is delegated to validators, staking yield would become 7.1% in one year and the minimum amount in stake to break even drops by 24%, to 32 thousand SOL.
The inflation rate is even more relevant for small validators’ profitability, compared to transaction fee rewards. Adjusting the inflation model according to the actual network configuration would reinforce the interest of those validators staking less than 40 thousand SOL. Supposing the 8.85% rate simulation above, approximately 21 more validators (1.12%) would reach the break-even level — that is the number of validators currently in range 30-40 thousand SOL in stake.
In this study, we explored the variables behind the Solana validator economics, estimating profitability levels for different market scenarios.
We found that:
Fee markets are now live on Solana but the adoption of the priority fee by dApps and general users at the moment is low, with the proportion of around 4% of transactions paying a higher fee than the fixed rate. It has been in an uptrend since launched, in late July.
Go to the Solana Validator Cost estimator in getguesstimate to explore the relevant variables, their interactions, and correlations. Thanks,
, Chorus One engineer, for building it.
“Look below the surface and you will find that all seemingly solo acts are really team efforts.” —John C. Maxwell
This article was brought to you by
. With meticulous review by
and
.
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
Blockchains not only need to be technically good. Besides the protocol and implementation levels, a key element in the success of a decentralized system is having different and independent groups using it, operating it, and governing it. The economic incentives in decentralized systems to achieve such participation by all these different groups have gained attention from researchers who are now interested in “tokenomics”, as a new field of study.
In this article, we are going to explore Solana economics, focusing on the stimulus to network node operators, or validators. We conducted an analysis of the inflation model, the costs and rewards to validators and stakers, as well as the current network activity levels. We also estimate the minimum stake required of a validator in order to break-even, and estimate the impact of different market scenarios, considering the most important variables and how they affect validator profitability.
For this purpose, we built the Solana Validator Dashboard and the Solana Validation Cost Estimator.
The Solana inflation design has defined SOL emissions as starting at 8%, and decreasing by 15% every year. The model was activated on February 10th, 2021 with the payment of 213,841 SOL.
As of July 2022, Solana’s inflation rate is around 6.8%. The staking yield is equivalent to 9.1%, as 75% of the total supply is currently staked (i.e. total inflation rewards are distributed to staked tokens only, resulting in a dilution of non-staked tokens). The rate does not reflect the yearly emission rate. It can be considered a target instead, and the mechanism behind it is broken down below.
Solana’s inflation model considers 400ms block times even though it is mentioned on Docs that the current implementation targets block times to 800ms. The recent average is around 650ms but with high variance.
Although Solana remains extremely performant to the everyday user, the difference in slot times directly impacts the economics and business viability of running a validator on Solana. Longer block times will result in smaller rewards, given a smaller number of epochs in a calendar year, decreasing the amount of SOL distributed to network participants.
In every epoch, Solana calculates the number of tokens instantiated for the inflation pool. The result will be the amount of SOL tokens to be distributed to validators and stakers as inflation rewards, according to the voting and staking status from the previous epoch. 0.45 SOL is the approximate amount currently allocated and distributed among eligible validators in each slot — 195 thousand SOL per epoch.
Block times impact inflation rewards as the function will taper the initial rate (8%) given how many slots have passed since inflation activation on Mainnet — as a proportion of how many slots fit in one year.
Considering an average block time of 650 ms, the inflation being distributed in every epoch is equivalent to a 4.1% yearly rate and the stake yield falls to 5.5%, instead of the 6.8% and 9.1% previously assumed.
Also relevant to validator economics will be the commission. In fact, stake owners, a.k.a. delegators, earn the inflation rewards. Validators earn a portion of it represented by the commission. In the plot below, we can see that a common fee for public nodes is around 10%. There are only 81 nodes charging a 5% fee or smaller. 100% commission is assumed to refer to private nodes (100 validators).
Block reward from transaction fees varies according to network activity. Recent average is around 0.01 SOL per slot. Total per epoch increases with voting power, as the number of slots attributed to the validator is based on the proportional stake.
Theoretically, as inflation decreases with time, validators’ rewards would be supplemented by the increase in transaction fees. The assumption can eventually become a truth as the network matures. Some plots below show that currently this is an unfair assumption:
1- The market’s cyclic nature — the number of non-vote transactions will not necessarily be growing over time. Total transactions (vote + non-vote) picks in Oct21, around 180 thousand in one day. And falls to less than 100 thousand transactions in Apr22.
2- Solana network has invested in growing the network of validators. The plot below shows the number of unique rewards recipients (addresses).
3- As a consequence of voting power dilution and lower network activity, rewards obtained from transaction fees decreased for validators in an individual perspective.
We split the cost into i) hardware, colocation, and bandwidth, to host the validator and ii) personnel, which can vary significantly. The official recommendations can be found on the Solana Documentation.
The vote is an affirmation that a block it has received has been verified, as well as a promise not to vote for a conflicting block. — Solana Docs
Validators are expected to vote on the validity of the state proposed by the slot leader. A validator node, at startup, creates a new vote account and registers it in the network. On every new block, the validator submits a new vote transaction and pays the transaction fee (0.000005 SOL).
Validators usually own (a portion or the total of) the staked tokens, a.k.a. self-staking. In this case, the cost of tokens depends on the average price of acquisition. For the purpose of the current analyses, we will consider the validators only to own 100 SOL at a US$ 50 price.
The Solana Foundation promotes the growth of the validator set through the Solana Delegation Program. Applications require small validators to achieve the “baseline” criteria, which includes running a node also on the Testnet, in order to receive 25,000 SOL. Those who meet the baseline criteria and also the “bonus” criteria can receive an extra (dynamic) amount in the delegation. A recent post on stake delegation strategies and why delegation programs are needed, goals, and criteria can be found in How can networks nurture decentralization?
In summary, Solana validator’s profitability depends on the current inflation rate, block times — reflected on the number of epochs in one year, the voting power, the total supply, the number of transactions, the cost structure, and the SOL market price.
For the three operational levels stated above, we will look at three different economic scenarios: optimistic, average, and pessimistic, with the average scenario being the closest to the current values.
The average market price in one year is fixed at $50 for the purpose of break-even analysis. Different price scenarios can be evaluated in a further session.
We found that the 40,000 SOL to break even would be a realistic amount for a small validator, on an average scenario, close to current levels. The number grows to 253,000 SOL for the medium setup. A professional validator would need more than 1.3 million SOL staked.
For a validator with a 0.01% stake, we estimate a 25 SOL reward from transaction fees in one year. The voting process costs around 200 SOLs per year for each node operator. Therefore, small validators are dependent on inflation rewards to achieve break-even, and ideally, become profitable. Around 350 thousand SOL staked would be needed to fully cover the voting cost, when considering rewards from transaction fees only.
Although the number of validators may be considered high compared to other Proof of Stake networks, 71 accounts are responsible for 57% of the total 365 million SOL staked.
The majority of validators currently stake between 80 and 90 thousand SOL, as seen in the plot below. There are at least 138 (7%) instances of the validator client with stake amounts smaller than 40 thousand SOL, the estimated break-even level for a small validator.
Simulation shows that medium and professional validators are more sensible to fluctuations in the SOL market price than small-size validators. Considering SOL average price in a year to be $75, the break-even level decreased by more than 30% for medium and professional levels and only 7% for small validators. A similar effect is found if the average price drops to $25.
Solana validators and stakers have seen rewards decreasing with higher block times compared to the projected rewards from the initial inflation model. As additional factors, the network experienced a contraction in non-vote transactions during the latest months and the expansion of the validator set.
According to the break-even levels discussed above, an 8.85% inflation target would be the rate level to reflect an effective 5.5% emission in one year, considering 650 ms block times (6.3% if 550 ms block times). Assuming 75% of total supply is delegated to validators, staking yield would become 7.1% in one year and the minimum amount in stake to break even drops by 24%, to 32 thousand SOL.
The inflation rate is even more relevant for small validators’ profitability, compared to transaction fee rewards. Adjusting the inflation model according to the actual network configuration would reinforce the interest of those validators staking less than 40 thousand SOL. Supposing the 8.85% rate simulation above, approximately 21 more validators (1.12%) would reach the break-even level — that is the number of validators currently in range 30-40 thousand SOL in stake.
In this study, we explored the variables behind the Solana validator economics, estimating profitability levels for different market scenarios.
Fee markets are now live on Solana but the adoption of the priority fee by dApps and general users at the moment is low, with the proportion of around 4% of transactions paying a higher fee than the fixed rate. It has been in an uptrend since launched, in late July.
Go to the Solana Validator Cost estimator in getguesstimate to explore the relevant variables, their interactions, and correlations. Thanks, Ruud, Chorus One engineer, for building it.
“Look below the surface and you will find that all seemingly solo acts are really team efforts.” —John C. Maxwell
This article was brought to you by Chorus One. With meticulous review by Felix Lutsch and Ruud.
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
Maximum Extractable Value (MEV) represents a fundamental concept in cryptoeconomics, highly affecting permissionless blockchains. MEV is the consequence of the design of protocols and brings with it bad and good externalities. Indeed, not all MEV can be considered benign as some represent an invisible tax on the user, e.g. check out one of our previous articles — Solana MEV Outlook. In general, MEV can also be an incentive for consensus instability, see e.g. the time bandit attack. However, considering all types of MEV as bad externalities is wrong. There exist benign forms of MEV that ensure protocol efficiency, and one prominent example is arbitrage. Let’s imagine that some user swaps a huge amount of token A on a specific AMM (huge with respect to the total amount in the pool) and that this transaction creates a $5,000 arbitrage opportunity. All users that swap tokens in the same pool and same direction will see their output lowered with respect to the actual value. Thus, whoever exploits this MEV opportunity will also bring the market back to parity with the true price. This will make the AMM more efficient without harming its users in the process.
On Solana, MEV still represents a dark forest since no one has pointed a flashlight at it. This is because Solana is a much younger blockchain compared to Ethereum, which can be seen in the lack of products like Flashbots. One project that is moving in this direction is Jito Labs, which recently delivered the first MEV Dashboard for Solana representing an explorer aimed at illuminating MEV — see here for an introduction. However, it is not the only one trying to fulfill this duty. Pointing lights on some Solana Decentralized Exchanges (DEXs) in order to illuminate the dark forest is one of the key objectives at Chorus One. MEV is a consequence that will be a crucial factor for the future of PoS networks and we are continually looking for the best way to ride it. You can explore our Solana MEV dashboard here.
It is important to understand that a simple copy of Flashbots may not be good for Solana, since it represents a drastically different network from Ethereum — and Jito seems to be something intrinsically different. In this article, we are going to assess what are the MEV challenges Solana faces. We’ll also review the status of our internal research regarding MEV.
In Section 2, we’ll analyze the current and future status of MEV on Solana, with a detailed analysis of what we found on-chain in Section 2.1.
In Section 3, we’ll discuss some implications of the current MEV strategies and how these can affect the functionality of a PoS network.
MEV has a specific supply chain, which “describes the chain of activity which helps users transform intentions into finalized state transitions in the presence of MEV ”. However, despite this “universal” definition, MEV on Proof of Stake (PoS) networks is drastically different from what it represents on Proof of Work (PoW) networks. This is for several reasons. For sure, the most important difference relies on the possibility of knowing for sure that a validator will propose a block at some point. Further, validators have delegators and can offer to them a portion of the MEV revenue (e.g. lowering the commission) attracting users to delegate with them. This makes MEV on PoS networks a growing business model, which constitutes one of the building blocks for cryptoeconomic incentives. From one side, we have validators who can use MEV revenue to reduce commission rate — even go to negative values — by returning all incomes to the delegators. On the other side, we have incentives for Layer-1 (L1) blockchains to improve network performance. This is because, if the “scaling problem” is solved by the introduction of L2s, the MEV and transaction (txs) fees are also moved away from the main chain, weakening the L1 business model.
This is exactly what blockchains like Ethereum are facing right now, representing one of the great risks over the next few years. See this Twitter thread for a better understanding of the topic.
But, what is the current status of MEV on Solana? Let’s start from the beginning. Solana does not have a public mempool, meaning that some bad externalities of MEV are very difficult to achieve. However, Solana is not free from them since MEV extraction may produce a bad performance of the network, e.g. spam txs, dropped txs, etc. Indeed, some MEV opportunities only exist if searchers run their own validator, inspect txs that come to them, and run an MEV-extraction code on top of it. Having a high stake and getting access to more MEV opportunities is not an easy task. This dramatically reduces the likelihood of being highly profitable, as the distribution of MEV revenues averages around zero, with a tail towards higher values — see Fig. 2.2.
Note that this is obtained in a specific time window, so it is only representative of the shape of the actual distribution.
Since txs fees on Solana are low and MEV opportunities can bring validators more profit, validators are incentivized to auction off their block space to searchers, or at least some rumors are pointing towards this possibility.
Further, on Solana, fees are currently fixed and cheap, meaning that if there is high competition in a specific market, users face the risk of not getting transactions executed. Since a gas-fee auction is still missing, currently MEV searchers spam transactions to the leader (and following validators in the leader schedule) in the hopes of “winning the battle”.
Lastly, on Solana, MEV competition may incentivize validators to perform denial of service (DoS) attacks on other validators in order to leave the spotted MEV opportunities just there, sitting on the table where they are until the attacker can extract them.
The current status of MEV indicates how bad the problem of blockspace-waste is, which resulted in degraded performance for normal users. At the time of writing, according to what can be found on Jito’s MEV dashboard, we have 12,072,328 successful arbitrages against the 350,179,786 unsuccessful ones in 6 months (i.e. a 3.3% of success rate). If we also include liquidations, the success rate goes down to roughly 3%. The total extracted “good” MEV is around $33M. Of course, this is only a lower-bound since MEV can be created any time a user interacts with a blockchain, and smart contracts enable a functionally infinite number of potential interactions. Thus, it is computationally infeasible to calculate a blockchain’s total potential MEV by brute force. Further, we have some previous analyses that show how a huge amount was extracted during periods of stressful market conditions, e.g. $13M MEV during Wormhole Incident and $43M Total MEV from Luna/ UST Collapse on Solana.
Future Solana improvements aim to introduce several features, forcing current MEV strategies to change. Introducing these new features represents a two-sided coin for MEV searchers. Indeed, some spamming bots would be forced to shut down since the local fee market will make it unprofitable to massively spam txs. However, improving the network means more and more users are attracted to use it. This has the immediate consequence of also increasing the total amount of MEV, allowing the chain of implications to continue by incentivizing competition around MEV and “inviting” new searchers to step in.
One of the main problems that can worsen an AMM’s functionality is pool congestion. This is because if there are too many txs happening on a specific pool, users may experience a worse trade due to pool unbalancing. This is why arbitraging is a sort of service that normalizes DEXs functionality. But, despite the fact that we know MEV is happening on Solana, where are the greatest opportunities? In other words, what are the DEXs with the highest pool congestion, and who is “solving” it? To answer these questions, we built an MEV dashboard on Dune Analytics. This is because, by looking at the exchanged volume, — using Solscan — you can definitely have an idea of where the congestion is, but nothing is clear when the question is if searchers are solving for it.
Our preliminary research shows that in 10 days (from July 16th to July 26th), the paths with the highest extracted MEV on Solana were live on Orca and Raydium with a lower bound of 20,775 USD extracted, see Fig. 2.5. There were 68 MEV extractors on these cross DEXs during the analyzed period, thus not a great number in terms of competition. Fig. 2.6 shows how the extracted revenues are concentrated among a few searchers. Precisely, 5 different accounts extracted 80.1% of the total MEV.
It is worth mentioning that none of the studied DEX combinations show a uniform distribution in terms of MEV opportunities, according to what we show in Fig. 2.2.
If we extend the analysis by looking at the USDC Token Accounts belonging to the most profitable MEV searchers, we have that 7 accounts were able to extract 95.6% of total extracted MEV, see Fig. 2.7. Two of them, GjT…m2P and G9D…y2m, interact with the same smart contract, which may indicate that these two accounts belong to the same user. Since these accounts are in the top 7 accounts, this means that it is likely that only 6 users were able to extract 95.6% of the total extracted MEV.
By deep diving, we also found two accounts interacting with a smart contract with clear reference to Jito, Jito…HoMA, with a total extracted MEV in 10 days of 3,342.30 USDC (at time of writing), over a total of 158,132 USDC extracted — i.e. 2.1% of the total amount.
We already stated that, on PoS networks, MEV can be seen as a business model since validators can share a portion of the extracted amount with their delegators. However, as shown in Sec. 2.1, this sometimes can constitute a deal that does not truly mean high returns. MEV revenues are strongly correlated with market conditions and DEXs’ usage, meaning that we’re unable to estimate a fixed income to share with delegators. Further, if competition does not grow fast, the promise of sharing revenue with delegators may bring a centralization problem.
To assess this statement, let’s try to formulate a “gedanken-experiment”. Imagine that the volume exchanged by DEXs on Solana grows by a factor 30, and assume that there is only one validator extracting MEV and redistributing the revenues to delegators. The implication of the increased volume is that MEV also increases. Indeed, a factor of 30 means that in 30 days the DEX’s volume on Solana is greater than $30B, and assuming that the 0.04% of it is MEV — as it happens on Ethereum — this means more than $144M yearly. The implication of having only one validator playing this game is that the extracted amount also increases, making the delegation to them an appealing deal. We can just think that a validator with ~2% of the total stake can extract an MEV of ~ $2.9M yearly. Once the delegation starts to concentrate around a single validator — the sole player — again we have a boost in MEV revenues, since the leader schedule is “stake-dependent” on Solana. This is because the revenue per block is not uniformly distributed, so a higher stake means an increased likelihood of capturing a rare juicy opportunity, pushing up the median of the extracted MEV. If there is no competition, this gedanken-experiment has a single outcome: concentration of stake — i.e. centralization.
Risks become higher if one considers that at the moment Solana is one of the fastest blockchains and that future development aims to improve this even further. The high number of processed txs per second could pave the way for prop firms to enter the market, meaning that more SOL can be delegated to a single validator — the winner of the MEV war.
This, without any doubt, points toward the necessity of building competitive validators for what regards MEV extraction. Once Jito delivers its third-party client for Solana that’s been optimized for efficient MEV extraction (plus its bundle), the risk of centralization can be mitigated. However, even with decentralized block building, as Flashbots aims to achieve with MEV-boost, we remain still far from a definitive solution. Indeed, such an environment makes it easier for builders to buy the blockspace of all validators and thereby isolate the centralization to the builder layer, see e.g. here. At the moment a decentralized MEV from top to bottom is a chimera. The first step toward this direction would require open-sourcing the MEV-extracting validator, starting collaboration between many validators, in the true spirit of open source. Indeed, it is worth noting that adopting validator products developed — and belonging — to a single entity reduces the problem of stake concentration, but can decrease the network’s censorship resistance. If block production is centralized to a single entity, that may represent an enormous censorship risk, regardless of how many validators participate.
For example, let’s assume that this entity gets adopted by 50% of the stake. Suppose now that this entity is regulated by a specific government, which demands that all transactions are blocked. Then, at best, users would need to get their transactions into the other blocks, but in the worst case, this entity can refuse to include vote transactions that vote on blocks that contain sanctioned transactions. This is a simple example that shows how some MEV strategy outcomes could pave the way for censorship risks.
Before concluding, it is worth mentioning that other possibilities do exist. One of them is to frame MEV-extraction as a service, where it is the protocol itself that takes the MEV and shares the corresponding revenue with protocol-token stakers, see e.g. recent rumors on Osmosis development. Despite this “method” seeming to be less prone to a centralization risk, it remains unclear if the time needed to extract MEV is enough to guarantee the AMM functionality — remember that poor competition means some opportunities may remain there for a “long” time. The outcome is the difficulty of assessing all the details of how this will affect the future of the chain.
This article aims to collect some thoughts on how framing MEV may affect the future of PoS ecosystems, focussing on some of its “bad” consequences. Despite the fast development around this huge and complex topic, we at Chorus One are continuously researching this topic with an eye to the future: the healthiness of all networks is always our first priority.
If you’re interested in framing the topic and require research/advisory services on MEV, you can contact our Research Team at research@chorus.one
Solana has announced three main changes in its mitigation plan to address the stability and resilience of the network:
The measures are targeting the intense traffic responsible for two out of the three recent incidents. Although the changes being proposed by Solana developers are considered abstract or deeply technical for the general part of the community, the concepts are not completely new, being imported from other already mature systems. In this article, we will try to break down the technicalities and explain them in simple terms.
The current Solana client version for validator nodes (v1.10) already paves the way for some of these improvements to be iterated on until optimal market fit. Fee prioritization is targeted for the v1.11 release, according to the official announcement.
Solana used to adopt the User Datagram Protocol (UDP) for transmitting transactions between nodes in the network. Nodes send transactions through UDP directly to the leader — the staked node responsible for proposing the block in that particular slot — without a previous connection being established. UDP does not handle traffic congestion or delivery confirmation for data. In situations of network congestion, the leader is unable to handle the volume of incoming traffic, which means some packets get dropped. Even at quiet times, some level of packet loss is normal. By sending the same transaction multiple times, users have a greater chance that at least one of their attempts will arrive.
In contrast to UDP is the Transmission Control Protocol (TCP). TCP includes more sophisticated features but for this to work, it requires a session (i.e. a known connection was previously established between the client and the server). The receiver acknowledges (“acks”) packets and the sender knows when to stop sending packets in case of intense traffic. TCP allows for re-transmitting lost packets, once the sender stops receiving acks, the interpretation is that something must be lost, so the sender should slow down.
TCP is not ideal for some use cases though. In particular, it sequences all traffic. If one portion of the data is lost, everything after it needs to wait. That is not great for Solana transactions, which are independent.
QUIC is a general-purpose protocol which is used by more than half of all connections from the Chrome web browser to Google’s servers. QUIC is the name of the protocol, not an acronym.
QUIC is an alternative to TCP with similar features: a session, which then enables backpressure to slow the sender down, but it also has a concept of separate streams; so if one transaction gets dropped, it doesn’t need to block the remaining ones.
Solana is a permissionless network. Anyone running a Solana client is a “node” in the network and is able to send messages to the leader. Nodes can operate as validators — when it is signing and sending votes — and (or) they can expose their RPC (Remote Procedure Call) interface to receive messages from applications such as wallets and DEXs, and send those to the leader.
The leader listens on a UDP port and RPCs listen on a TCP port. Given the leader schedule is public, sophisticated players with algorithmic strategies (“bots”) are able to send transactions to the leader directly, bypassing any additional RPC nodes that would only increase latency. With the leader being spammed, the network gets congested and that deteriorates performance. The UDP port used by the leader will be replaced by a QUIC port.
Quality of Service (“QoS”) is the practice of prioritizing certain types of traffic when there is more traffic than the network can handle.
Last January, after Solana faced performance issues as automated trading strategies (aka “liquidator bots”) spammed the network with more than 2 million packets per second, mostly duplicate messages, Anatoly Yakovenko mentioned in a tweet that they would bring the QoS concept to Solana.
The Leader currently tries to process transactions as soon as they arrive. Because IPs are verifiable through QUIC, validators will be able to prioritize and limit the traffic for specific connections. Instead of validators and RPCs blasting transactions at the leader as fast as they can, effectively DoS’ing the leader, they would have a persistent QUIC connection. If the network (IP) gets congested, it will be possible to identify and apply policies to large traffic connections, limiting the number of messages the node can send (“throttle”). These policies are known as QoS.
Internally, staked weighted QoS means queuing transactions in different channels depending on the sender, weighted by the amount of SOL staked. Non-staked nodes will then be incentivized to send transactions to staked nodes first, instead of sending directly to the leader, for a better chance of finding execution, since excess messages from non-staked nodes will most likely be dropped by the leader.
According to Anatoly validators will be responsible for shaping their own traffic, and applying policies that will avoid vulnerability. For example, if a particular node sends huge amounts of transactions, even if they are staked, validators can take action, ignoring the connections established with this node in order to protect network performance.
Solana fees are currently fixed and charged for each signature required in a transaction (5000 lamports = 0.000005 SOL). If there is high competition in a specific market, users face the risk of not getting transactions executed. With a fixed transaction fee, there is no way to communicate priority or compete by paying more to get their transaction prioritized. Without alternatives, users (usually bots) spam transactions to the leader (and soon-to-be leaders) in hope that at least one of them is successful. In many situations, this behavior generates more traffic than what the network can process.
A priority fee is soon to be included in Solana, allowing users to specify an arbitrary “additional fee” to be collected upon execution of the transaction and its inclusion in a block. This mechanism would not only help the network to prioritize time-sensitive transactions but also tends to reduce the amount of invalid or duplicated messages sent by algorithms since speculative operations can become unprofitable with an increase in the total cost.
The ratio of this fee to the requested compute units (the computational cost to the program to perform all operations) will serve as a transaction’s execution priority weight. This ratio will be used by nodes to prioritize the transactions they send to the leader. Additional fees will be treated identically to the base fee today: 50% of the fees paid will be collected by the leader and 50% will be burned.
At this point, you could think of several blocks being filled only with transactions targeting an NFT mint. However, there is a limit time for each account to be locked for writing on a single slot (600 to 800 milliseconds). The remnant block space can be filled with transactions writing in different accounts, even if they offer a smaller priority fee. High-priority transactions trying to write to an account that has already reached its limit will be included in the next block.
Each Solana transaction specifies the writable accounts — the portion of the state that will be modified. This allows transactions to be executed in parallel, as long as transactions are independent, i.e. do not access the same accounts. If two transactions write or read to the same account, these two transactions can not be processed in parallel, because they affect the same state.
The Solana team argues that the priority fee will then behave as parallel auctions, affecting only the “hot market” instead of the global price, allowing the fee to grow for a specific queue of transactions trying to write in that account only.
How does the user know the fee to adopt to get a mint? RPCs nodes will need to estimate an adequate fee, most likely using a simple statistical method, for example averaging the actual cost of similar transactions in previous N blocks, or even a quantile. The optimal method will depend on the market, and whether fees for similar transactions are more volatile (high demand) or stable (less demand).
In practice, the priority fee can have a global effect, if the parallel auctions are not implemented on the validator client. With RPCs and users being responsible for arbitrarily setting it, during high intense traffic, applications will likely try to get priority even though they do not interact with the “hot market”, causing an increase in the fee price for other lower demand dApps.
Fee prioritization is targeted for the v1.11 release, according to the official announcement.
The present article covered the three pieces Solana is actively working on to deal with congestion issues, which include changing the communication protocol from UDP to QUIC, adding stake-weighted QoS for transaction prioritization and a fee market that increases fees with high demand. All of these 3 improvements aspire to improve the performance of Solana, which has been experiencing degraded performance quite often.
We hope it was possible to clarify these concepts and understand the motivations and choices being made. Exploring Solana source code would be an essential next step to investigate the exact metrics being implemented in QoS to select or drop transactions or the mechanism behind the increase (and decrease) of fees and other questions that remain unanswered.
I would like to thank the Chorus One team for the enlightening discussions and knowledge sharing, especially Ruud van Asseldonk for the technical review, and Xavier Meegan for the support.
This is the second article of the Solana MEV outlook series. In this series, we use a subset of transactions to extrapolate which type of Maximum Extractable Value (MEV) is being extracted on the Solana network and by whom.
MEV is an extensive field of research, ranging from opportunities created by network design or application-specific behaviour to trading strategies similar to those applied in the traditional financial markets. As a starting point, our attempt is to investigate if sandwich attacks are happening. In the first article, we examined Orca’s swap transactions searching for evidence of this pattern. Head to Solana MEV Outlook — part 1 for a detailed introduction, goals, challenges and methodology. A similar study is performed in the present article. We are going to look at on-chain data, considering approximately 8 h of transactions on the Raydium DEX. Given the magnitude of 4 x 10⁷ transactions per day, considering only Decentralized Exchanges (DEX) applications on the Solana ecosystem. This simplification is done to get familiarity with data, extrapolating as much information as we can to extend towards a future analysis by employing a wider range of transactions.
Raydium is a relevant Automated Market Maker (AMM) application on the Solana ecosystem, the second program in the number of daily active users and the third in terms of program activity.
Raydium program offers two different swap instructions:
Although the user interface (“UI”) interacting with the smart contract sets the swap instruction to use the first instruction type, leaving SwapBaseIn responsible for 99.9% of successfully executed swap instructions:
We built a dataset, extracting the inputs from the data byte array passed to the program, and the actual swap token amounts by looking at the instructions contained in the transaction. Comparing the minimum amount of tokens specified in the transaction and the actual amount the user received, we estimate the maximum slippage tolerance for every transaction. By computing the corresponding slippage, we obtain the histogram:
The default value for slippage on the Raydium App is set to 1%. We can assume that at least 28% of transactions use the default value. Since it is not possible to know the state of the pool when creating the transaction, this number could be a bit higher.
It can be assumed that nearly 0% of slippage values are only achieved by sophisticated investors using automated trading strategies. Orca swaps’ histogram, presented in Fig 2.2 of the previous article, shows a peak in transactions with slippage of around 0.1%. On Raydium, a relevant proportion of transactions lies below 0.05%. This fact can suggest that trading strategies with lower risk tolerance, i.e price-sensitive strategies correspond to 25% of the swaps transactions (accumulating the first two bars in the histogram).
Other evidence of automated trading being common on this DEX is that on average, 40% of transactions fail, mostly because of the tight slippage allowed by user settings.
We are considering more than 30,000 instructions interacting with the Raydium AMM program, from time 02:43:41 to time 10:25:21 of 2022–04–06 UTC. For statistics purposes, failed transactions are ignored.
Although 114 different liquidity pools are accessed during this period, the SOL/USDC pool is the most traded pool, with 4,000 transactions.
The sample contains 1366 different validators as leaders in more than 35000 slots we are considering, representing 93% of the total stake and 78% of the total validator population by the time of writing, according to Solana Beach.
Of 5,101 different addresses executing transactions, 10 accounts concentrate 23% of the total transactions. One of the most active accounts on Raydium, Cwy…3tf also appears in the top 5 accounts in Orca DEX.
The graph below shows the total number of transactions for accounts with at least two transactions in the same slot. If used as a proxy to identify automated trading, on average 9 different accounts can be classified:
We can also look at the pools where these accounts execute more often. It is possible to notice they tend to specialize in different pools. The table below shows the two pools with more transactions for each of the 5 more active addresses:
By deep-diving into account activity by pool, we can see that two accounts concentrate transactions on WSOL/USDT pool; one account is responsible for half of all transactions in the mSOL/USDC pool; most of the transactions in the GENE/RAY pool are done by only one account (Cwy…3tf).
Searching for sandwich behaviour means we need to identify at least 3 transactions executed in the same pool in a short period of time. For the purpose of this study, only consecutive transactions would be considered. The strategy implies the first transaction to be in the same direction of the sandwiched transaction and a transaction in the opposite direction of the initial trade, closing out the positions of the MEV player.
The need for price impact implies a dependence on the amount of capital available to be used in every trade. Some MEV strategies can be performed atomically, with a sequence of operations executed in the same transaction. These strategies usually benefit from flash loans, allowing for anyone to apply it disregarding the capital they have access to. This is not the case for sandwich attacks, since the profit is realized after the successful execution of all the transactions (Fig. 10).
As shown in the first article, the amount of capital needed in order to create value depends on the Total Value Locked in the pool — the deeper the liquidity, the more difficult it is to impact the price. Head to Fig. 2.4 of the first article for the results of simulation into the Orca’s SOL/USDC pool. The figure shows the initial capital needed in order to extract a given percentage of the swap.
In the current sample, we have found 129 blocks with more than three swaps in the same pool, most of the swaps are in the same direction — no evidence of profit-taking. As shown in Fig. 11 below, the pool SAMO_RAY is the pool with more occurrences of multiple swaps in the same slot.
When searching for blocks and pools with swaps in opposite directions as a proxy to profit-taking, 9 occurrences are left with a potential sandwich attack pattern, as shown in the table below (Fig 12). After further investigation of the transactions and the context in which the instructions were executed, it is fair to assume the operations are related to arbitrage techniques between different trading venues or pools.
In this report, we were able to access the activity of the Raydium DEX. The conclusions are based on a limited amount of data, assuming our sample is comprehensive enough to reflect the general practices involving the dApp.
It is possible to notice relevant activity from automated trading and price-sensitive strategies such as arbitrage, which corresponds to 25% of swap transactions. On average, only 40% of transactions are successfully executed and 72% of all reverted transactions fail because of small slippage tolerance. Approximately, 28% of transactions can be classified as manual trading, since they use the default slippage value.
Of 5101 different accounts interacting with the Raydium program, 10 accounts concentrate 23% of the total transactions. One of the most active accounts on Raydium, Cwy…3tf also appears in the top 5 accounts in Orca DEX transactions. This same account is responsible for 77% of swaps in the GENE/RAY pool.
There were 9 occurrences of a potential pattern of a Sandwich attack discarded after further investigation.
It is important to mention that this behaviour is not only dependent on the theoretical possibility but largely biased by market conditions. The results in $13m MEV during Wormhole Incident and $43m Total MEV from Luna/ UST Collapse on Solana demonstrate the increase in profit extracted from MEV opportunities during stressful scenarios. Although the study focuses attention on different strategies and does not mention sandwich attacks, the probability of this strategy happening can also increase, given the smaller liquidity in pools (TVL) and the occurrence of trades with bigger size and slippage tolerance.
This is my first published article. I hope you enjoyed it. If you have questions, leave your comment below and I will be happy to help.
Solana is a young blockchain, and having a complete picture of what is happening on-chain is a difficult task — especially due to the high number of transactions daily processed. The current number of TPS is around 2,000, meaning that we need to deal with ~ 10⁸ transactions per day, see Fig. 1.1.
When processing transactions, we have to deal with the impossibility of a-priori knowing its status before querying information from an RPC node. This means that we are forced to process both successful and failed transactions. The failed transactions, most of which come from spamming bots that are trying to make a profit (e.g. NTF, arbitrage, etc.), constitutes ~ 20% of the successful ones. The situation slightly improves if we consider only program activity. By only considering what happens on Decentralized Exchanges (DEXs), we are talking about 4x10⁷ transactions per day, see Fig. 1.2. This makes it clear that a big effort is required to assess which type of Maximum Extractable Value (MEV) attack is taking place and who is taking advantage of it, even because tools like Flashbots do not exist on Solana.
In what follows, we are going to estimate what happened on-chain considering only ~5 h of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14. This simplification is done to get familiarity with data, extrapolating as much information as we can to extend towards a future analysis by employing a wider range of transactions. It is worth mentioning that Orca DEX is not the program with the highest number of processed instructions, which indicates that a more careful analysis is needed to look also into other DEX — this is left for future study.
The aim of this preliminary analysis is to gain familiarity with the information contained in usual swap transactions. One of our first attempts is to extrapolate if sandwich attacks are happening, and if so, with which frequency. In Section 2, we are going to look at the anatomy of a swap transaction, focussing on the type of sandwich swap in section 2.1. Section 2.2 is devoted to the description of “actors” that can make a sandwich attack. In Section 3, we describe the dataset employed, leaving the description of the results in Section 4. Conclusions are drawn in Section 5.
On Solana, transactions are made by one or more instructions. Each instruction specifies the program that executes them, the accounts involved in the transaction, and a data byte array that is passed to the program. It is the program’s task to interpret the data array and operate on the accounts specified by the instructions. Once a program starts to operate, it can return only two possible outcomes: success or failure. It is worth noticing that an error return causes the entire transaction to fail immediately. For more details about the general anatomy of the transaction see the Solana documentation.
To decode each of the instructions we need to know how the specific program is written. We know that Orca is a Token Swap Program, thus we have all the ingredients needed to process data. Precisely, taking a look at the token swap instruction, we can immediately see that a generic swap takes as input the amount of token that the user wants to swap, and the minimum amount of token in output needed to avoid excessive slippage, see Fig. 2.1.
The minimum amount of tokens in output is related to the actual number of tokens in output by the slippage S, i.e.
from which
Thus, we can extract the token in input and the minimum token in output from the data byte array passed to the program, and the actual token in output by looking at the instructions contained in the transaction.
By computing the corresponding slippage defined in Eq. (2.2) we obtain the histogram in Fig. 2.2. From this picture, we can extrapolate different information. The first one is, without doubt, the distribution of transactions around the default value of slippage on Orca, i.e. 0.1%, 0.5% and 1%. This makes complete sense since the “common-user” is prone to use default values, without spending time in customization. The second one is the preference of users to select the lowest value for the slippage. The last one concerns the shape of the tails around the default values. A more detailed analysis is needed here since it is not an easy task to have access to what actually is contained inside them. The shape surely depends on the bid/ask scatter, which is a pure consequence of the market dynamic. The tails may also contain users that select a different slippage with respect to the default values. However, one thing is assured: this histogram contains swaps from which the slippage can yet be extracted. As we will see, from this we can extrapolate an estimate of the annualized revenue due to sandwich attacks.
The goal of this report is to search for hints of sandwich swaps happening on Orca DEX. All findings will be used for future research, thus we think it is useful to define what we refer to as sandwich swaps and how can someone take advantage of them.
Let’s start with its basic definition. Let’s assume a user (let’s say Alice) wants to buy a token X on a DEX that uses an automated market maker (AMM) model. Let’s now assume that an adversary sees Alice’s transaction (let’s say Bob) and can create two of its own transactions which it inserts before and after Alice’s transaction (sandwiching it). In this configuration, Bob buys the same token X, which pushes up the price for Alice’s transaction, and then the third transaction is the adversary’s transaction to sell token X (now at a higher price) at a profit, see Fig. 2.3. This mechanism works until the price at which Alice buys X remain sbelow the value X･(1+S), where S represents the slippage set by Alice when she sends the swap transaction to the DEX.
Since Bob needs to increase the value of the token X inside the pool where Alice is performing the swap, it is evident that the core swaps inserted by Bob should live on the same pool employed by Alice.
From the example above, it may happen that Bob does not have the capital needed to significantly change the price of X inside the pool. Suppose that the pool under scrutiny regards the pair X/Y and that the AMM implements a constant product curve. In the math formula we have:
where k is the curve invariant. If we set the number of tokens Y in the pool equal to 1,000,000 and the number of tokens X equal to 5,000,000 and assuming that Alice wants to swap 1,000 token Y, we have that the amount of token X in output is:
It is worth noting that here we are not considering the fee that is usually paid by the user. If Alice set a slippage of 5%, this means that the transaction will be executed until the output remains above 4'745.25. This means if Bob is trying to take this 5%, he will need an initial capital of 26,000 token Y.
Sometimes this capital may be inaccessible, allowing Bob to only take a portion of the 5% slippage. For example, let’s consider the Orca pool SOL/USDC, with a total value locked (TVL) of $108,982,050.84 at the time of writing. This pool implements a constant product curve, which allows us to use Eqs. (2.3) and (2.4) to simulate a sandwich attack. Fig. 2.4 shows the result of this calculation.
It is clear that the initial capital to invest may not be accessible to everyone. Further, it is important to clarify that the result is swap-amount independent. Indeed, for each amount swapped by Alice, the swap made by Bob is the one that “moves” the prices of the initial tokens inside the pool. The scenario is instead TVL dependent. If we repeat the same simulation for the Orca pool ETH/USDC, with a TVL of $2,765,189.76, the initial capital needed to extract a higher percentage of the slippage of Alice drastically decreases, see Fig. 2.5.
From the example above, let’s consider the case in which Bob has an initial capital of 2,000 token Y. If he is able to buy the token Y before Alice’s transaction, Alice will obtain an output of 4,975.09 token X, which is only 0.4% lower than the original amount defined in Eq. (2.4).
At this point, Bob has another possibility. He can try to order transactions that are buying the same token X after its transaction, but immediately before Alice’s swap. In this way, he can use the capital of other users to take advantage of Alice’s slippage, even if Bob’s initial capital is not enough to do so, see Fig. 2.6. This of course results in a more elaborate attack, but likely to happen if Bob has access to the order book.
It is not an easy task to spot the actors behind a sandwich attack on Solana. In principle, the only profitable attackers are the leaders. This is because there isn’t a mempool, and the only ones that know the exact details of the transactions are the validators that are in charge of writing a block. In this case, it may be easier to spot hints of a sandwich attack. Indeed, if a leader orders the swap transactions to perform a sandwich, it should include all of them in the same block to prevent an unsuccessful sandwich.
The immediately following suspect is the RPC service that the DAPP is using. This is because the RPC service is the first to receive the transaction over HTTP, since it is its role to look up the current leader’s info using the leader schedule and send it to the leader’s Transaction Processing Unit (TPU). In this case, it would be much more difficult to spot hints of sandwiching happening since in principle the swap transactions involved can be far from each other. The only hook we can use to catch the culprit is to spot surrounding transactions made by the same user, which will be related to the RPC. This is a consequence of the lower price fee on Solana, which raises the likelihood that a sandwich attack can happen by chance spamming transactions in a specific pool. This last one is clearly the riskiest since there is no certainty that the sequence of transactions is included in the exact order in which the attacker originally planned it.
Before entering the details of the analysis, it is worth mentioning that, standing on what is reported on Solana Beach, we have a total of 1,696 active validators. Our sample contains 922 of them, i.e. 54.37% of the total validator population. The table below shows the validator that appears as the leader in the time window we are considering. Given the likelihood-by-stake for a validator to be selected as a leader, we retain fair to assume that our sample is a good representation of what’s happening on Orca. Indeed, if a validator is running a modified version of the vote account program to perform sandwich swap, the rate of its success will be related to the amount of staked tokens, not only by actual MEV opportunities. Further, modifying the validator is not an easy task, thus smaller validators will not have the resources to do that. Since we have all the 21 validators with a supermajority plus a good portion of the others (i.e. we are considering half of the current number of active validators), if such a validator exists, its behaviour is easily spotted in our sample. However, it is worth mentioning that a complete overview of the network requires the scrutiny of all validators, without making assumptions of that kind. Such achievement is behind the scope of this report, which aims primarily to explore which type of sandwich can be done and how to spot them.
Having clarified this aspect, we firstly classify the types of swaps that are performed on the Orca DEX. The table below shows the accounts that are performing more than two transactions. It is immediately visible that most of the transactions are done by only 2 accounts over 78 involved.
As explained in Section 1, we are considering 5H of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14. This sample contains a total of 12,106 swaps, with pool distribution in Fig. 3.1.
By deep-diving into the swap, we can see that most of the transactions in the 1SOL/SOL [aq] and 1SOL/USDC [aq] are done by only two accounts, see Fig. 3.2. Here [aq] stands for Aquafarm, i.e. an Orca’s yield farming program. We can also see the presence of some aggregate swaps in the SOL/USDC [aq] and ORCA/USDC [aq] pools.
We started searching for the presence of leaders performing sandwich swaps. As we described in Section 2.1, in general, a swap can happen in two ways. For both of them, if such a type of surrounding is done by a leader, we should see the transactions under scrutiny included in the same block. This is because, if a leader wants to make a profit, the best strategy is to avoid market fluctuations. Further, if the attacker orders the transactions without completing the surrounding, the possibility that another leader reorders transactions cancelling the effect of what was done by the attacker is not negligible.
By looking at the slots containing more than 3 swaps in the same pool, we ended up with 6 slots of that kind, out of 7479. Deep diving into these transactions, we found that there is no trace of a sandwich attack done within the same block (and so, from a specific leader). Indeed, each of the employed transactions is done by a different user, marking no evidence of surrounding swaps done to perform a sandwich attack. The only suspicious series of transactions is included in block # 124899704. We checked that the involved accounts are interacting with the program MEV1HDn99aybER3U3oa9MySSXqoEZNDEQ4miAimTjaW, which seems to be an aggregator for arbitrage opportunities.
As mentioned in Section 2.2, validators are not the only possible actors. Thus, to complete the analysis we also searched for general surrounding transactions, without constraining them to be included in the same block. We find that only 1% of the total swaps are surrounded, but again without strong evidence of actual sandwich attacks (see Fig. 4.1 for the percentage distribution). Indeed, by looking at those transactions it comes out that the amount of token exchanged is too low to be a sandwich attack (see Sec. 2).
Before ending this section, it is worth mentioning that if we extrapolate the annual revenue that a leader obtains by taking 50% of the available slippage for swaps with a slippage greater than 1%, we are talking about an amount of ~ 240,000.00 USD (assuming that the attacker is within the list of 21 validators with supermajority), see Fig. 4.2. Of course, this is not a real estimate since it is an extrapolation from only 5h of transactions, thus we need to stress that the actual revenue can be different. Further, this is not an easily accessible amount due to what we showcased in Sec. 2. However, the amount in revenue clearly paves the way for a new type of protection that validators should offer to users, especially if we take into account that Orca is not the DEX with the highest amount of processed swaps. Since at the moment there is no evidence that swaps are sandwiched, we will take no action in this direction. Instead, we will continue monitoring different DEXs by taking snapshots in different timeframes informing our users if a sandwich attack is spotted on Solana.
In this report, we define two types of sandwich attacks that may happen on a given DEX. We further describe who are the possible actors that can perform such a type of attack on Solana and how to spot them. We analyzed data from ~5 h of transactions on Orca DEX, from 11:31:41 to 16:34:19 on 2022–03–14 (that is, 12,106 swaps). Despite the cutting of the number of transactions employed, we argued why we believe this sample could fairly be a “good” representation of the entire population.
Our findings show no evidence that sandwich attacks are happening on Solana by considering two possibilities. The former is that a validator is running a modified version “trained” to perform a sandwich attack on Orca. The latter is that an RPC is trying to submit surrounding transactions. We discovered that only 1% of transactions are actually surrounded by the same user, but none of them is included in the same block — excluding the possibility that a leader is taking advantage of the slippage. By deep-diving into this, we discover that the amount exchanged by these transactions results are too low for capital to be invested to exploit the slippage and submit a profitable sandwich attack.
We also show how the capital needed to make sandwich attacks profitable may not be accessible to everyone, narrowing the circle of possible actors.
2021 was an incredible year for Proof-of-Stake. As a major staking provider, we are keen to explore new ways to give back to our delegator community that enables us to pursue our mission to advance the staking ecosystem. For this reason, we decided to initiate the first NFT airdrop to our Solana delegators (see also the official announcement post covering the basics and our reasoning for the ‘Reaction’ drop). In this post, we want to expand on our collaboration with CoherenceNFT going deeper into the background of this initiative and on how our snapshot of on-chain data is impacting the generated art.
After Uniswap’s initial $UNI airdrop, there have been many further iterations to reward initial users and to bootstrap a community of dedicated users. While some airdrops currently try to form a community based on on-chain activity without much of a product (see $SOS and $GAS), others are trying to bring valuable users into their communities; this can especially be seen in the Cosmos ecosystem. Here, Osmosis led the way by airdropping a large portion of tokens to valuable Cosmos community members, an example many others are following, a recent ambitious example being the Evmos Rektdrop. As a validator, we found ourselves in a slightly different situation. We already have a sizable community of delegators earning rewards on their staked assets with us and we wanted to give them something unique to thank them for their support while working towards a larger goal.
We realised that NFTs could serve as a gateway for our ambitions to form an engaged community enabling us to reward our most valued supporters in a crypto-native way. Ultimately, we aim to weave NFTs — including the Reaction drop — into our products and services in creative ways. Stay tuned and hold onto your Reaction NFTs to get access to unique benefits as we explore the possibilities enabled by them!
We decided to begin in the Solana ecosystem, to which we attribute a lot of our success and which has a flourishing NFT ecosystem and low fees; uniquely enabling our initial concept: a large-scale NFT airdrop that is using on-chain data to create art with differing rarities based on our delegators’ profiles. We took a snapshot of the stake accounts delegated to the Chorus One public validator on Dec 8th, set a threshold for delegations of above 0.1 SOL, and aggregated addresses with multiple stake accounts. This resulted in 3,600 unique NFTs which we — in collaboration with CoherenceNFT — decided to further break down into 9 rarities. The NFTs differ in qualities depending on their rarity. This applies to the colours used, which range from new stakers which are coloured in Chorus One greens, to medium duration stakers that are coloured in Solana’s brand colours, to long-term stakers that receive a mix of both. In a similar fashion, the thickness of the lines used in the artworks depends on the amount of stake going from thin for lower amounts of stake to thick for large stakers. The chosen parameters resulted in the distribution illustrated in the image below.
Conclusion
We are thrilled to have started our foray into NFTs and are looking forward to expanding this effort and engaging with various other web3 tools complementing our services. Stay in the loop by jumping onto our Discord, Telegram or showing us your NFTs on Twitter. And while you do that, why not consider staking with us too? Who knows, you could lay your hands on another surprise NFT in the future!
We want to thank CoherenceNFT for this collaboration and are looking forward to engaging with other artists and projects in the NFT space in the future!
I’m excited to work with Chorus One to grow the Solana NFT community by creating an asset to expand the benefits offered to Chorus One stakers. More companies entering the NFT space are making NFT utility and adoption a reality. I’m hoping a broader and more diverse set of businesses and creators are inspired by this to make use of blockchains as a way to fulfil their visions. From a creative point of view, it was really challenging and inspiring to use a new creative mode, where I had to design in advance to reward different ranges of users according to the desired characteristics of the Chorus One team
CoherenceNFT
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
Yesterday, Lido for Solana went live on Solana mainnet. In about 24 hours since launch, around $7m worth of SOL have already been staked with Lido by over 400 accounts.
Now that these stakers have unlocked all this liquidity, the biggest need of the hour is to enable them to utilize it in DeFi protocols.
We understand that and we’re thrilled to announce that we are live on two AMMs — Saber and Raydium.
Saber, the leading cross-chain stablecoin and wrapped assets exchange on Solana, has launched the stSOL/SOL pool currently holding roughly $300,000 in liquidity.
Raydium, an automated market maker (AMM) built on the Solana blockchain which leverages the central order book of the Serum decentralized exchange (DEX), have launched a first stablecoin pool with stSOL
In the near future, another stSOL liquidity pool with an ETH pair will be launched on Raydium.
Raydium’s AMM aggregates Serum’s central limit order book, meaning that pools have access to all order flow and liquidity on Serum. For stSOL the following two markets exist on Serum:
In addition to these integrations, we are working with Mercurial Finance to go live with a stSOL/SOL pool that will use our internal price oracle to create a maximally efficient liquidity pool.
Keep a lookout for this and further upcoming integrations at https://chorus.one/products/liquid-staking
We are thrilled to announce the launch of Lido for Solana. Lido, the leading protocol bringing liquidity to staked assets on Ethereum and Terra, has expanded its offering to Solana. Lido’s liquid staking token for Solana — stSOL — allows its holders to passively earn Solana staking rewards with a diversified set of professional node operators while retaining the ability to collateralize their stake in DeFi applications such as liquidity pools or lending protocols.
Over $6bn have already been staked with Lido by more than 29000 stakers making Lido the largest non-custodial staking protocol for Ethereum and Terra. This overwhelming confidence in Lido’s liquid staking products will only grow with the addition of Lido for Solana to the cohort. As is true with other Lido staking products, Lido for Solana is going to integrate with a number of decentralized finance applications making it easy for stSOL holders to earn passive rewards!
Lido for Solana makes the value locked in staked SOL tokens accessible by issuing stSOL in exchange. Lido for Solana makes Solana staking extremely attractive by providing
Liquid staking circumvents the opportunity cost of having your tokens locked up in a PoS protocol.
In Proof-of-Stake (PoS) networks, users participate in securing the network by locking up their tokens. They get rewarded as a result in the form of native tokens. The staking assets are used as collateral to register validators in the consensus process. This means that while assets are staked, they are held in an escrow on the network. Consequently, staked assets are inaccessible to the token holder while they are being used to secure the network.
Another restriction in most PoS protocols is that even when a token holder decides to exit a staking position, they are only able to do so with a delay. This is most commonly referred to as the unbonding period. In Solana, this period is known as the deactivation/cooldownand lasts for approximately 2–3 days (1 epoch). There are many costs associated with such illiquidity.
Liquid staking circumvents the opportunity cost of having your tokens locked up in a PoS protocol. In liquid staking, the staked positions are tokenized and derivative tokens are issued. These derivative staked tokens are a claim to the underlying, illiquid staking positions and become the liquid representation of the native token. These liquid tokens can be used in various financial products thereby enabling stakers to earn additional yields and manage their liquidity risk exposure.
Liquid Staking on Solana issues liquid tokens called stSOL which can be used in various DeFi integrations available on the platform. Liquid staking for Solana is available on mainnet at https://solana.lido.fi
After approving your transaction you will see the new stSOL balance reflected on the widget.
Head over to the DeFi integrations section at https://chorus.one/products/liquid-staking/ and choose your preferred DeFi Integration. Alternatively, visit https://lido.fi/lido-ecosystem to explore the latest decentralized applications where you can use the stSOL token.
chorus.one
The complete documentation for the project can be found at https://chorusone.github.io/solido/. Head over to the page to explore staking guides and other technical resources.
The launch on the Solana mainnet was preceded by 2 security audits and an ongoing bug bounty program, highlighting the importance placed on the security of the protocol. The complete source code for the on-chain program has been made publicly available and can be accessed at https://github.com/ChorusOne/solido
github.com
Join the liquid staking revolution by heading over to the widget!
Further information and the latest updates on Lido for Solana can be found on the official website.
Chorus One offers staking services and builds 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
Lido, the largest liquid staking project on Eth2 and Terra, is looking to expand its offering to the high-performance blockchain Solana. Chorus One is building this service for Lido. 3 months ago we submitted the proposal to build Lido for Solana. The proposal received support from an overwhelming majority of LDO holders.
Over the last 3 months, we have made rapid progress behind the scenes. This is the story of our journey in building the liquid staking solution for the fastest blockchain in the world
‘Lido for Solana’ is a Lido-DAO governed liquid staking protocol for the Solana blockchain. Anyone who stakes their SOL tokens with Lido will be issued an on-chain representation of their SOL staking position with Lido validators, called stSOL. This will allow Solana token holders to get liquidity on their staked assets which can then be traded, or further utilized as collateral in DeFi products
On the 30th of April, 2021, Chorus One submitted a development proposal to the Lido DAO as a snapshot vote. The proposal was to build a Lido-operated liquid staking protocol for the Solana blockchain
The proposal was put to vote on the 6th of May and every LDO holder was invited to participate. The proposal received overwhelming support. 79 LDO holders holding 96.85m LDO voted exclusively in favor of the proposal.
The proposed design is centered around a liquid staking token, called stSOL, that will accrue staking rewards and represent staking positions with Lido validators on Solana.
medium.com
The stake deposited to the Lido contract on Solana will be distributed to these validators following a logic similar to the Lido Ethereum liquid staking solution. Lido on Solana will have a fee mechanism similar to that on Ethereum which allows splitting of fees between node operators and the Lido treasury (e.g. to be used for the insurance fund). Lido node operators, as well as parameters such as the fee, will be controlled via the governance of LDO holders on Ethereum. Additionally, in the initial version, governance decisions will be carried out via a Multisig controlled by Lido stakeholders on Solana.
We started building Lido for Solana in April 2021. Towards the end of June, we made the codebase audit-ready and we got it audited by Bramah Systems. We have now made the source code public for the whole world to review. In line with the design, we are performing a Multisig ceremony with 7 participants on the Solana testnet. Soon we will be announcing a bug bounty on Lido for Solana.
Lido’s first design was inspired by the Stake Pool program in the Solana Program Library (SPL). In fact, our first version wrapped over the SPL stake pool. However, over time we swapped out the Stake Pool program for a different approach. The end result is a Lido program — similar to the Stake Pool program — but with key differences.
#2 — By doing so all validators get the same fee percentage, which may be lower than that of the node they operate publicly, and by making it 100% commission, we encourage delegations to Lido.
After extensive in-house testing, we commissioned an audit from Bramah Systems. We addressed all issues identified during the audit and re-enforced the security of the Solana program. However, in order to hold Lido to the highest security standards, we are looking for an additional audit.
In a nutshell, the audit covered the following aspects
In order to trust any program with your funds, two things need to be true:
A prerequisite for these is having access to the source code. Therefore, we have made our codebase public for everyone to view. Anyone can visit the Lido for Solana repository, where we have published the source code under the GPL V3 license — https://github.com/ChorusOne/solido
github.com
The documentation for the project can be found here.
To make our project even more robust, we are going to announce a bug bounty for developers to test the project for exploits.
We will be announcing the exact scope, prioritized vulnerabilities, and rewards categorized by threat level on our web page and on Twitter in the coming weeks.
We decided on using multisig governance for the Lido program. Before we get to the details of our Multisig program, let us see why we need it in the first place.
Programs on Solana can be upgraded unless upgrades are explicitly disabled, and this gives the upgrade authority (the address that can sign upgrades) a lot of power. After all, it could upload a new version of the Lido program that withdraws all Lido funds into some address and runs away with the funds. 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. 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.
Multisig Programs/addresses require multiple signatures to approve a transaction. These are smart contracts that enable multiple signers to review an action on the blockchain before it is executed. This allows for decentralized governance. Chorus One used the Serum Multisig program to introduce decentralization in Lido for Solana. This multisig has N=7 participants and requires at least M=4 of them to sign for a transaction to be approved.
The complete multisig ceremony will be covered in a later post dedicated to just that.
It is important to note that the role of the multisig is not to make independent decisions regarding Lido for Solana, but only to execute decisions made by the Lido DAO. The 7 parties that comprise the multisig are
Node operators are crucial to the success of this project. Evaluating and onboarding a responsible node operator is an important step. Shortly after the Lido DAO was initiated, the Lido Node Operator Subgovernance Group (LNOSG) was formed. This group was tasked to onboard and represent node operators in the DAO structure.
With the announcement of a proposal for Lido for Solana, we also announced the onboarding of operators for it. Any node operator that wants to apply could do so by filling up a form.
The frontend for interacting with Lido for Solana (currently pointing to Devnet) is here. We have integrated 5 Solana wallets with the frontend — Phantom, Solflare, Ledger, Solong, and Sollet.
Apart from that, we are exploring integrations with the following DeFi applications to utilize stSOL’s liquidity.
Any projects that want to reach out for integration can do so by sending us an email at support@chorus.one
Going ahead we are looking for another audit of our code. That coupled with the results of bug bounty will put us on the path to the mainnet launch. Stay tuned for the latest announcements at https://twitter.com/ChorusOne
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
Lido, the largest liquid staking project on Eth2 and Terra, is looking to expand its offering to the high-performance blockchain Solana. Chorus One is building this service for Lido.
‘Lido for Solana’ is a Lido-DAO governed liquid staking protocol for the Solana blockchain. Anyone who stakes their SOL tokens with Lido will be issued an on-chain representation of SOL staking position with Lido validators, called stSOL. This will allow Solana token holders to get liquidity on their staked assets which can then be traded, or further utilized as collateral in DeFi products. We will work to integrate stSOL widely into the Solana DeFi ecosystem to enable stSOL users to make use of their staked assets in a variety of applications.
Lido for Solana gives you:
The Lido DAO is a Decentralized Autonomous Organization which governs and enables the development of liquid staking solutions for different blockchains.
The first liquid staking protocol solution was built for Ethereum — and now Lido is expanding to different blockchain networks. Chorus One recently proposed a plan to build “a liquid staking token that will accrue staking rewards and represent staking positions with Lido validators on Solana”. The stake deposited to the Lido contract on Solana will be distributed to these validators following a logic similar to the Lido (stETH) on Ethereum. Lido on Solana will have a fee mechanism similar to that on Ethereum which allows splitting fees between node operators and the Lido treasury (e.g. to be used for the insurance fund).
Lido’s decentralized organization brings together the industry’s top staking providers, decentralized finance projects, and investors. The Lido DAO eliminates dependence on a centralized authority, thereby removing the risk of a single point of failure. Distributed governance also fosters a stronger community!
Solana is an extremely fast, and censorship-resistant blockchain that has witnessed tremendous growth and adoption in the last year. Solana serves transactions at an order of magnitude higher rate when compared to base layer Ethereum. Additionally, there is a flourishing ecosystem emerging around Serum and other DeFi protocols such as Raydium, Oxygen, Pyth Network, and others that are being built on Solana. With over $14bn staked, Solana is now also in the Top 5 of Proof-of-Stake networks by staked value.
Liquid staking takes the utility of Solana a step further by:
Lido for Solana not only makes it very easy to stake but also provides further utility through stSOL. Let’s look at the process in slight detail. A SOL token holder connects their wallet to an interface that supports Lido (one will e.g. be hosted at https://stake.lido.fi) and deposits their tokens into the Lido program. They immediately receive stSOL tokens that represent a share of the total pool. Every user’s tokens are held in a pool controlled by the Lido program.
The Lido program collects the deposited SOL and releases the newly minted stSOL to the user. Beneath the layer, the Lido Program distributes this SOL uniformly across validators participating in the Lido Program. When these delegations accrue rewards on the allotted stake, the total SOL under pool management increases and this increases the value of stSOL tokens. The Lido DAO governs the Lido Program — and also controls the list of validators that are part of this program.
Let’s compare this to traditional Solana staking, where a user has to perform a number of steps:
Furthermore, in traditional staking, if the user wants to diversify her stake across validators she would have to create and manage stake accounts for each validator.
Staking SOL through Lido will come with a variety of benefits:
Interestingly, there is no waiting time for receiving stSOL tokens. When a user delegates their SOL tokens they do not need to perform or wait for the completion of any delegation or activation steps, as is the norm in traditional staking. The user can instantly exchange stSOL for SOL at any time in the open market.
In Lido for ETH, withdrawals from the Lido program are blocked until the ETH2 chain is live. In Lido for Solana, staggered withdrawals will be enabled. These direct withdrawals will take a couple of epochs to process, and will be beneficial for large withdrawals (e.g. because there will be no slippage from trading on the open market). However, for small withdrawals exchanging stSOL on a DEX (e.g. to SOL) will likely prove to be the go-to solution in order to exit a staking position with Lido for most of the users.
Reward distribution in ‘Lido for Solana’ is an interesting deviation from how rewards are distributed in Lido for Ethereum, which pegs ETH2 to stETH in a 1:1 ratio.
To understand how rewards work for ‘Lido for Solana’ let’s look at a hypothetical scenario. Let’s assume that the pool contains 2000 SOL and while we are at it let us also assume that a total of 1800 stSOL are held by the token holders. This puts an exchange rate of 0.9 stSOL per SOL.
If Alice deposits 1 SOL now she will get 0.9 stSOL in return. As rewards accrue SOL balance goes up, let’s say from 2000 to 2100. The new exchange rate becomes
Now if Alice goes and enquires about the value of her 0.9 stSOL, she finds it to be
Effectively, her SOL balance potentially went up by 5% from 1 SOL to 1.05 SOL. This approach is called the share-pool approach. Even though the numbers here are hypothetical they represent the concept of rewards accurately.
Note
The accrued rewards here are after a fee cut for Lido maintainers. To incentivize sustainable management of the Lido ecosystem, a portion of the rewards is split between the node operators and DAO treasury. The remaining larger chunk (on Ethereum, these amount to 90%) of rewards accrue to Lido users and get reflected in the increased value of stSOL as explained above.
Lido for Solana doesn’t follow the pegging approach, followed by ETH and stETH, as of now. However, this might be considered for revision when Solana launches native support for rebasing in SPL tokens.
The stSOLs that one gets can be used to reap secondary rewards through DeFi protocols. There will also be liquidity pools on AMM protocols and other DEXes where one will be able to immediately exchange stSOL for SOL. For the ETH<>stETH pair a popular AMM in terms of liquidity and volume is the Curve pool.
Withdrawals of SOL from the Lido program will be rolled out after the initial MVP that is expected later this summer. As mentioned above, instant withdrawals will be available in the open market. Once activated, withdrawal from the Lido pool will take a couple of epochs. This process is intentionally staggered to avoid bank-run scenarios.
As discussed in the rewards section a portion of the rewards goes to the Lido DAO treasury. The amount that goes to the Lido DAO treasury can be potentially used for different purposes
The Lido DAO is the deciding authority on the various parameters of the ecosystem. Things like fees, upgrade approvals, validator set, voting mechanisms, etc. are decided by the DAO. It is in the DAO’s charter to make the system run smoothly and it does so through the process of voting. To be a voter one must possess the governance token, LDO. The amount of LDO determines the weight of your vote.
Lido DAO’s governance is a key aspect of the ecosystem and holds the key to the success of Lido for Solana.
Chorus One proposed to build the liquid staking solution described here with support from the Lido DAO and the vote past with over 96m LDO in favor and 0 LDO against. Follow our Twitter handle and website to keep in touch with the latest updates.
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.
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!
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.
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.
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.
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.
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
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 performance and security of a blockchain is determined by the nodes operating it. A conventional blockchain is limited by the transactional processing power of a single node in the network. To circumvent this limitation, most protocol designers come up with complex schemes to distribute work across a subset of nodes in the system. This is what we refer to as sharding. Sharding is a complex problem statement that requires well-thought out mechanisms to ensure safety and usability, especially with respect to composability of applications.
There is one team that stands out by taking a different approach to scaling a layer-1 blockchain network: Solana. Instead of trying to scale by adding more nodes, subsetting them across different blockchains, and then trying to economically link them together into one system, Solana is radically optimizing the performance of a single node on one chain (#NoSharding).
The results of this approach are astonishing: in a cluster with nodes running high-performance GPU-based validation hardware, Solana can achieve a throughput of tens of thousands of transactions per second on a single, composable, blockchain!
Sustaining this type of performance in a production environment relies on more than low-level optimization and high-end hardware. Node operators need to be able to continuously operate- even in adversarial settings-both to ensure the network stays performant, and to maximize their rewards for maintaining the blockchain.
One way to achieve this is to rely on network engineers to troubleshoot nodes in case they go down for whatever reason. This solution comes with a host of problems and is putting pressure on individuals. This makes it not well-suited for an environment seeking to be the base layer of a new financial system. Imagine getting a call at night and having to manually fix a machine that is handling large amounts of value, knowing that a mistake can become extremely costly, even catastrophic.
Another approach is to institute an automated failover system consisting of multiple nodes communicating and deciding internally which of them gets to sign blocks. Such a design comes with its own challenges, especially around ensuring that no blocks are accidentally double-signed, which would lead to large slashing penalties. So far only a very small group of teams have explored this design space, e.g. Certus One and Chorus One.
With support from the Solana team, Chorus One has dedicated resources to build and maintain software to provide high availability validation tailored to the Solana network: Solana StrongGate.
StrongGate allows validators on Solana to run redundant infrastructure with a focus on protecting against accidental double-signing. StrongGate works by using the Solana blockchain as a detection mechanism and a highly available, strongly consistent database as a resolution mechanism to determine which of the validator nodes gets to sign blocks.
Watch Chorus One’s Meher Roy present StrongGate at the first SolCon in Osaka, Japan for a detailed breakdown of the design and rationale:
We will soon share the repo and more information on how to use StrongGate for your Solana validator operation. We’d like to thank Solana for their support and we are looking forward to continuing to contribute our part to build and operate the web scale blockchain that the world deserves!
Chorus One is building validation and staking infrastructure for Proof-of-Stake networks.
We will offer staking on the Solana blockchain. You can support our work and earn staking rewards by delegating to our validator node.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Solana is a web-scale blockchain with speeds up to 50,000 tps 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 November 15, 2019.
.png)
