This post will provide a high-level, non-technical introduction to staking SUI tokens.

For a more detailed explanation, please reference the Sui Staking FAQ and Sui Tokenomics white paper provided by the Mysten Labs team. While every effort has been made to make the information presented in this post consistent with the FAQ and white paper, the FAQ and white paper should be considered the authoritative sources of information.

Also, if you're new to staking, you may wish to consider staking a small test amount of SUI tokens to become comfortable with the process.

You have your Sui tokens, congratulations! So what's next?

One option is to put your tokens to work securing the network by staking them. The Sui protocol rewards token holders who do so.

How do you do this?

You do this by staking tokens to one or more validators of your choice.

What's a validator?

Validators operate the server infrastructure that enables the network to function. They're also rewarded by the network protocol for keeping the network running.

Because without validators, there would be no network and without a network, there would be no transactions. And without transactions, Dapps wouldn't work.

What happens when I stake to a validator?

You can retain full custody of your tokens when staking to a validator, IF you stake directly to a validator, i.e. not through a centralized exchange. Staking directly to a validator in this way is called non-custodial staking.

What's the difference between non-custodial and custodial staking?

To retain full custody of your tokens when staking to a validator, you must stake your tokens directly to a validator, i.e. not through a centralized exchange or CEX.
If you stake through a CEX, this is called custodial staking, because the CEX takes custody of your tokens.

You've heard the saying "Not your keys, not your coins..."? Well, when you stake through a CEX, you transfer your tokens from your keys to the CEX's keys. So, "Not your keys, not your coins..."!

However, when you stake directly to a validator, you keep control of your tokens with your keys.

Great, you've decided to stake your tokens directly to a Sui validator! What happens next?

When you stake your Sui tokens directly to a Sui validator, they get deposited into that validator's staking pool. (But remember, if you stake directly, in a non-custodial way, you always retain custody of your tokens, even when they're in the validator's staking pool.)

Each staking pool has it's own exchange rate. Again, quoting the Sui Staking FAQ, "these rates determine the amount of SUI tokens the staker (you) can withdraw in the future."

Note you can also stake to multiple validators. Some people like to do that to hedge risk and support a more decentralized network, for example. The Sui protocol allows you to do this by creating multiple "stake objects" and staking those "stake objects" to validators of your choice.

Remember when we said that the Sui protocol rewards token holders who stake their tokens? Here's how it happens.

The exchange rate increases as more stake is deposited into the pool, i.e. as more SUI token holders delegate to that validator, as long as the validator's staking pool contains less than 10% of the total staked amount of SUI tokens across all validator staking pools. The exchange rate also increases as time progresses.

When you decide to unstake your SUI tokens, you will receive the amount of SUI tokens you deposited, multiplied by the staking pool's exchange rate. Because the Sui protocol sets the staking pool's exchange rate greater than 1, unless the validator is slashed (see below), you should receive more tokens than you deposited.

But what about downtime and slashing?

It's also important to understand that a validator and its delegators only earn rewards if the validator is operational and functioning properly. If the validator is "down", i.e. not operational, for any reason, it will not earn rewards for itself or its delegators.

Also, in the Sui protocol, validators' and its delegators' rewards can get reduced, a/k/a "slashed". This happens if > 2/3 of validators vote to slash a given validator. The intention is for this to keep validators behaving efficiently, responsively and honestly.

If a validator is slashed in this way, via the "tallying rule", the rewards will continue to be slashed until greater than 2/3 of the other validators revoke the slashing.

Alright, so which validators should you stake to?

This is a good question and there's no single right answer. There are some considerations to think about that can help guide your decision though.

As mentioned above, you don't earn rewards if the validator you stake to is not operational. Your rewards could be slashed if the validator behaves in a way that greater than 2/3 of the other validators determine is unhealthy for the Sui network.

Because of this, it's important to choose a validator  you feel will operate their validator well, while operating efficiently, responsively and honestly.

Research the validator or validators that you might delegate to. Reach out and talk to them. Understand what motivates them.

Based on your research and conversations, consider delegating to the validators that you think will operate well, efficiently, responsively and honestly, as well as sync with your own motivations and values.

And don't forget about decentralization!

It's also important to consider the impact on decentralization that your validator choice may have. Remember, we're here to build a decentralized future after all, aren't we?

A decentralized future needs decentralized networks. Decentralized networks need decentralized validator sets. Decentralized validator sets need to be decentralized at the capital and infrastructure layers.

This post we wrote describes what that means in greater detail. The next two paragraphs provide a tl;dr of it.

At the capital layer, too much stake shouldn't be concentrated with too few validators. So all things being equal, choosing validators with lower stake helps decentralize the network.

At the infrastructure layer, too much stake shouldn't be concentrated with the same server provider, data center, or geography. This one can be trickier to figure out. Over time, hopefully tools will emerge that display this type of data and help inform your choice. We'll update this post when they do.

Conclusion

What we've tried to do with this post is provide a high level overview of the Sui staking process. By reading it, hopefully you now understand a little bit more about how Sui staking works. Remember though, this is crypto and things change fast.

It's always important to do you own research and verify any and all information before making decisions, e.g. whether to stake and which validators to stake to.

Thanks for reading, we'll see you on Sui!

P.S. - If you found this post helpful and would like to support our work, please consider staking your SUI to Chainflow.

Please Note: Some third-party sites allow you to stake with Chainflow on different networks. Those sites may have their own Terms of Service, which we're not responsible for; by choosing to stake with Chainflow on any of our networks, whether through third-party sites or directly using our staking address, you represent that you have read and agreed to our application Terms of Service.

Chainflow has supported Solana from the early days. We helped design Tour De Sol—the original testnet program that set the foundation for the healthy ecosystem of validators securing the network today—and have run a high-performing Solana validator ourselves ever since. As a result, we were able to attract about 3 million staked SOL in the months after the launch of mainnet beta.

We've remained an active supporter of the network, leading initiatives like:

• Building Solana Validator Mission Control , an open-source toolkit for independent validator operators
• Launching Nakaflow.io, an open-source Nakamoto Coefficient aggregator that has been cited in reports by the Solana Foundation and other researchers
• Sponsoring the Decentralized Infra track at this year's inaugural Sandstorm hackathon
• Co-organizing the network's new independent validator community calls

Over time, however, we've lost about 90% of our staked SOL. The vast majority of this loss happened when a few large stake accounts delegated away from us. While we still have around 2900 delegators, each of whom we feel sincerely grateful for, the impact of the loss of these large stake accounts has been significant.

It's tough to speculate on why owners of these large stake accounts, a/k/a whales, move stake—one assured us that we did nothing wrong to merit their un-delegation, for example—but this experience left us wondering:

How many other highly-staked validators are similarly dependent on a small number of stake accounts?

So, we decided to take a closer look. Below, we present our high-level findings, as well as a path to gaining new insight into increasing Solana's Nakamoto Coefficient.

Heavy Reliance on Heavy Bags

We looked at stake distribution by stake account across the 50 highest staked validators, which together account for roughly 40% of all staked SOL. Our initial research illustrates that many of the 50 highest staked validators also rely heavily on a small number of stake accounts.

Percentage of Stake Held by Top Two Delegators

First we looked at the percentage of stake held by a validator's top two delegators. Here's what we found:

Some interesting things stand out:

• 7 of the 50 validators (14%) rely on 2 delegators for 99%+ of their stake (not show in graph). Unsurprisingly these are all "anonymous" validators.
• 11 of the 50 validators (22%) rely on 2 delegators for 90%+ of their stake. Unsurprisingly these are all "anonymous" validators.
• 19 of the 50 validators (38%) rely on 2 delegators for 80%+ of their stake. This is a mix of named and "anonymous" validators.
• 26 of the 50 validators (52%) rely on 2 delegators for 50%+ of their stake. This is a mix of named and "anonymous" validators.

Percentage of Stake Held by Top Five Delegators

Then we expanded the analysis to the top five biggest stake accounts for each validator. Here's what we found:

The trends continue here as well:

• 18 of the 50 validators (36%) rely on 5 delegators for 99%+ of their stake (not shown in graph). Unsurprisingly these are, again, all "anonymous" validators.
• 25 of the 50 validators (50%) rely on 5 delegators for 90%+ of their stake. This is a mix of named and "anonymous" validators.
• 29 of the of the 50 validators (58%) rely on delegators for 80%+ of their stake. This is a mix of named and "anonymous" validators.
• 36 of the 50 validators (72%) rely on 5 delegators for 50%+ of their stake. This is a mix of named and "anonymous" validators.

Whales Crown Kings

It's pretty clear from this analysis that whales with big bags heavily influence what the validator set looks like. In many ways, these delegators act as the validator king makers.

Though these whales are largely anonymous, to the extent their identities are known, they're likely most-known to the larger validator businesses, staking as a service providers, and other institutional-focused entities that receive their stake. They may or may not be known to the smaller independent validator operators, however.

The Impact on and Value of Smaller, Independent Validator Operators

This creates a concerning imbalance of power, as smaller, independent validators are likely much more dependent than larger staking companies on whales, yet have less visibility into the whales' intentions.

And for independent validators like Chainflow, losing a few key stake accounts can be the difference between a running sustainable validator and a break-even or even money losing operation.

We feel that a healthy validator set must include smaller, independent operators. It's these operators who often punch above their weight and make outsized contributions relative to their size.

If you agree and want to see them continue to exist within the Solana validator set, it's important to support their work by staking to them.

Diving Deeper

We'd like to continue diving deeper here. For example, it would be interesting to investigate the relationships among the king-making whales.

Discovering commonalities among operators, particularly among the "anonymous" validators that rely heavily on five or fewer stake accounts, would be interesting as well.

Even more interesting would be understanding the incentives that validators may be offering to their large stake account delegators. From our experience in the space, it's not unheard of for validators, if not even common, for validators to offer special terms to delegators with large stake accounts.

Given how much of a reliance there is on small number of whales, this isn't terribly surprising. (For our part, Chainflow never offers such deals to anyone; we treat all delegators equally, no matter how big or how small their delegation may be.)

We plan to dive deeper into these areas in subsequent posts.

What about Solana's Nakamoto Coefficent?

Solana's Nakamoto Coefficient is usually near the top among the networks we track at Nakaflow.io, hovering typically in the 30-32 range. As shown by our friends (and winners of our Decentralized Infra track at this year's Sandstorm Hackathon) Solana Compass, it seems to have plateaued there for a while now:

It would seem, even from this cursory analysis, that shifting a few stake accounts around could push this number even higher. We plan to run a few scenarios and present them in future posts.

Conclusion

Our research suggests that a small number of large stake accounts heavily influence Solana's validator set, with a small number of big-ticket delegators accounting for a significant portion of the stake held by some of the largest-staked validators.

This leaves independent validators particularly vulnerable: If a whale decides to move their stake elsewhere,  a smaller validator operator can transition quickly from a sustainable and profitable operation to a money losing and unsustainable one. Given this vulnerability, continued support of these validators is particularly important.

This isn't to say that our findings are entirely grim. Whales may have the power to concentrate their stake with a small set of larger validators, but they also have the power to distribute their stake more equitably across the broader validator set.

A few moves by some of the larger stake account holders could help to increase Solana's Nakamoto Coefficient. We also hope that by bringing awareness to the fragility of the smaller independent validators staying power, delegators will support them with a renewed enthusiasm.

While this analysis answers some initial questions, it raises many others. We look forward to digging deeper and presenting additional findings in future posts.

P.S - If you'd like to support our work as an independent Solana validator, please consider delegating to us.

We appreciate all delegations, no matter how small or big. All delegators are created equally in our eyes, and we don't cut backroom deals with larger stakeholders.

We recognize the benefits ICS brings to the network and realize it can be a key competitive advantage. We appreciate all the hard work that's been done through the years to get us this far.

From the beginning, recruiting a competent validator set has required significant resources from networks wanting to launch in the Cosmos. ICS greatly reduces this barrier to entry.

At the same time, its adoption poses a few concerns we feel need to be addressed. One of these concerns will prevent us from being able to vote affirmatively for ICS adoption, at least in its current state.

We're particularly concerned about the requirement for all hub validators to validate on every consumer chain, without an ability to opt-out on an individcual chain basis. The rest of this post explains why.

More Chains, More Validators

During the earliest testnets, the primary validator focus was on becoming a hub validator. Zaki reminded us from time to time that operating a validator on the hub wouldn't be the only opportunity for infrastructure operators.

Sine then, the number of non-hub chains has proliferated. In doing so, many validators who weren't able to enter the Hub set have been able to validate on non-hub chains.

This has introduced the community to many well-deserving validators who contribute significant value to the chains the operate on. Most, if not many, may have never been discoverd had the hub been the only way to support the Cosmos.

ICS will re-focus and amplify the responsibilities of hub validators, as well as power they yield. This set is largely set, as stake doesn't move around much. As a result, the number of networks available to validate on will shrink. As vocal advocates of the need to #KeepStakeDecentralized, this power shift gives us pause when considering whether to support ICS in its current state.

More Chains, More Resources, More Money

As stated in the introduction, ICS requires hub validators to validate on every consumer chain that launches. Naturally this requires the validator operators to spend more CAPEX and OPEX resources.

The greater number of networks the operator supports, they need more servers, tooling and human attention to manage their infrastructure well. These requirements translate into higher CAPEX and OPEX costs. Additionally, many validators operate at a loss, at least in the early days.

Furthermore, it's likely ICS will encourage a greater number of chains to launch. This in turn makes it likely that the associated percentage of successful chains will decrease.

All these factors combine to increase the risk validators face in becoming profitable or even breaking even. This is particularly concerning for smaller, independent validators, who have historically operated on thin margins.

These validators are critical to decentralizing networks. They typically contribute greater value back to the networks they support, when compared to exchanges, staking as a service providers and other large validator companies.  Losing them would result in the loss of valuable contributors, while also delivering a severe and significant blow to the decentralization of the Cosmos.

No Values, More Problems

We put values before money at Chainflow. Our values focus heavily on the core tenets of the crypto revolution we're here to build the foundation for. In short, we're here to build a better future, one that's more fair, equitable and inclusive the current economy and power structure it upholds and enables. (Note to Luke: Link somewhere to our values post.)

Over the years, particularly as the "Web3" narrative takes hold, the percentage of people starting projects that hold similar values is decreasing. The "Web3" gold rush is on. This brings all types of speculators and others who are driven first and foremost by exiting and cashing out, following the typical VC, Silicon Valley playbook.

Chainflow picks and chooses the networks we support carefully. We don't support projects whose values we don't feel have the potential to align with our values over the long term. These values have proven, time and time again, to have helped us avoid a number of critical and high profile pitfalls crypto's experienced in recent times.

Having to validate on every consumer chain that passes a governance vote presents a significant risk to our values-aligned selection process. While we hope that each consumer chain that launches is values-aligned, past governance history participation, combined with the continued "Web3" shift toward a money-first focus, leads us to believe that we'll likely not align with each consumer chain that launches.

Voting No, At Least for Now

While the first two reasons give us pause, it's the values alignment risk that will ultimately cause us to vote No for ICS adoption in its current form.

We believe that allowing validators to opt-into indivdual chains is a critical second filter that the Cosmos needs. For example, if a consumer chain passes a community governance vote, yet can't get enough validators to support it, maybe it's a sign that the chain shouldn't launch.

From our own perspective, as explained above, voting "Yes" for the current implementation feels in conflict with our values. However, we do feel optimistic about Cosmos' future and will continue to support the network regardless of the ICS vote outcome.

If ICS passes in its current form, we will use that as an opportunity to advocate strongly for chains we feel values aligned with, while raising red flags for those we don't.

If ICS doesn't pass in its current form, we look forward to working with the community to refine the approach, to maximize the benefit to the network and community that ICS has the potential to provide.

P.S. If our values align with yours, please consider delegating to our Cosmos validator (<-LINK) to support our work.

Replicated Security is Exciting, Transformative, and Flawed

Chainflow joined the Cosmos community in 2017. Over the years, we've been fortunate to witness—first-hand, as a Cosmos Hub validator (find us, here)—the evolution of the Hub network and the broader Cosmos community.

In a recent post, we talked about our journey growing up in the Cosmos, and our excitement for one of the biggest steps to-date in its evolution: Interchain Security (ICS). In short: ICS introduces new ways for Cosmos chains to share security features, like validator sets.

Since we published that earlier post, the first ICS feature to be introduced has been officially renamed to "Replicated Security." And now, with the introduction of Cosmos Hub governance proposal 187, the Cosmos community is finally able to decide how Replicated Security will make its way to the Interchain, after months of discussion and development.

We see the benefits of Replicated Security, and recognize that it can become a key competitive advantage for the Cosmos Hub. We also appreciate all the hard work that's been done through the years to get us this far.

From the beginning, recruiting a competent validator set has required significant resources from networks wanting to launch in the Cosmos. ICS greatly reduces this barrier to entry.

Yet, the adoption of Replicated Security raises issues we feel need to be addressed before moving forward. We're concerned that Replicated Security, as we currently understand it, will:

1. Reduce opportunities for new validator operators, concentrating power in the existing Cosmos Hub validator set
2. Raise operational costs for validator operators, shrinking already-thin margins across the board
3. Eliminate choice for Cosmos Hub validator operators, forcing them to support new chains that may not align with their values

At the core of these issues is the requirement that all Cosmos Hub validators must validate on every Replicated Security "consumer" chain, without the ability to opt-out on an individual chain basis.

Given this requirement, we won't be able to vote affirmatively for Replicated Security adoption—at least in its current state. The rest of this post explains why.

More Chains, More Validators

During the earliest Cosmos testnets, the primary focus for validator operators was on becoming a Hub validator. But, Zaki reminded us from time to time that operating a validator on the Hub wouldn't be the only opportunity for infrastructure operators.

Over the years, the number of non-Hub chains has grown considerably. Since each new chain has needed to build its own validator set, many validators who weren't able to enter the Hub's fixed validator set (currently limited to just 175 active validators) have been able to validate on non-Hub chains, and gain a foothold in the Cosmos ecosystem.

This has introduced the community to many well-deserving validators that contribute significant value to the chains they operate on. Many, if not most, of these up-and-coming validator operators may have never been discovered had operating on the Hub been the only way to support the Cosmos.

Replicated Security will make it such that new Cosmos chains no longer need to build their own, new validator sets; instead, they can become "consumers" of the security offered by the Cosmos Hub's validator set. As a result, the responsibilities of—and the power yielded by—the Hub's validators will grow, likely further entrenching the power dynamics already in place.

As our ongoing tracking from Nakaflow.io shows, stake doesn't move around much on the Hub (or, for that matter, other leading Proof-of-Stake chains). That means we're not likely to see many new opportunities for up-and-coming validator operators to break into the Hub's active set.

In other words: For up-and-coming validator operators, Replicated Security may result in fewer new validator sets to join, and fewer opportunities to break into the Cosmos Hub's validator set.

As vocal advocates of the need to #KeepStakeDecentralized, this power shift gives us pause when considering whether to support Replicated Security in its current state.

More Chains, More Resources, More Money

Replicated Security, as constructed in Prop 187, requires Cosmos Hub validators to validate on every "consumer" chain that launches. Naturally, this requires the validator operators to spend more CAPEX and OPEX resources on supporting these new chains.

The more networks an operator supports, the more servers, tooling, and human attention they need to manage their infrastructure well. These requirements translate, simply, into higher CAPEX and OPEX costs. Yet, many validators already operate at a loss, at least in these early days.

It's likely that Replicated Security will encourage more new Cosmos chains to launch. This, in turn, makes it likely that the associated percentage of successful chains will decrease.

All these factors combine to increase the obstacles that validators face to becoming profitable, or even breaking even. This is particularly concerning for smaller, independent validators, who have operated historically on thin margins.

What's not obvious to many Cosmos participants, though, is that these independent validators are critical to decentralizing networks. They typically contribute an outsized amount of value back to the chains they support—especially when compared to exchanges, staking-as-a-service providers, and large validator companies.

Losing smaller validators would result in the loss of invaluable contributors, while also delivering a severe blow to the decentralization of the Cosmos.

No Values, More Problems

At Chainflow, we put our principles before profit. In our values, we focus heavily on the core tenets of the crypto revolution that we're here to build the foundation for. In short: We're here to help build a better future—one that's more equitable, inclusive, and fair than the current economy, and the power structure it enables and upholds.

As crypto matures—and particularly as the corporate "Web3" narrative takes hold—the percentage of people starting projects that hold similar values seems to be decreasing. The "Web3" gold rush is on. This brings all types of speculators and others who are driven first and foremost by cashing out—all following the typical VC, Silicon Valley playbook.

One important way that we reflect our values is by very carefully selecting the networks we support. We don't work with projects whose values don't feel like they have the potential to align with ours over the long term. This approach has, time and time again, helped us avoid a number of the critical and high-profile pitfalls that crypto has experienced over the years.

While we hope that each consumer chain that launches is values-aligned, the Hub's governance history, combined with the continued "Web3" shift toward a money-first focus, leads us to believe that we'll likely not align with every "consumer" chain that launches. Having to validate on every consumer chain presents a significant risk to our values-aligned selection process.

Voting No, At Least for Now

Ultimately, we're voting "No" on Prop 187 due to this risk to our values.

We believe that allowing validators to opt out of indivdual "consumer" chains is a critical second filter that the Cosmos needs. For example: If a consumer chain passes a community governance vote, yet can't get enough validators to support it, maybe it's a sign that the chain shouldn't launch.

While voting "Yes" for the current version of Replicated Security would feel in conflict with our values, we feel, nonetheless, optimistic about the Cosmos's future and will continue to support the Hub as a validator, regardless of Prop 187's outcome.

If Replicated Security is implemented in its current form, we will use that as an opportunity to advocate strongly for chains we feel values aligned with, while raising red flags for those we don't. If it isn't implemented in its current form, we look forward to working with the community to refine the approach to maximize the benefit this powerful new feature can provide to the Cosmos Hub, and the broader Cosmos ecosystem.

We've been supporting the ecosystem since its earliest days, and we'll continue to support it, and the Cosmos Hub, regardless of the outcome of Prop 187. However the vote works out, we'll remain active, engaged, and vocal.

If your values align with ours, please consider supporting our work by delegating your ATOMs to Chainflow's validator, here.

Yet, as we look to 2023, we remain optimistic. We are, after all, an infrastructure company, and, despite how hollow (or outright criminal) many "Web3 products" were in 2022, we're still inspired by the progress made last year by blockchain protocols and the communities behind them.

Here are some of our personal highlights:

We Went Live on Three New Protocols

Last year, we started operating in the active set of validators on three new mainnets:

• Agoric: A new home in the Cosmos for JavaScript smart contracts
• Quicksilver: Liquid staking across the Cosmos (more on this one below)
• Stargaze: NFTs in the Cosmos

Three new chains may not sound like much, but, in a year as dynamic as 2022, less was more. We take a principled approach to supporting new networks, and, while these three chains are all quite early, each shows some promise in helping to democratize the future of the Web.

Notably, they're all part of the Cosmos. As we've talked about before, the Cosmos has a history of innovation, and last year kept up the trend. New IBC-enabled protocols launched and existing protocols (like the Cosmos Hub, Osmosis, and more) took exciting steps forward. With Interchain Security (ICS) coming soon, 2023 is shaping up to be another banner year.

As always, we'll be on the lookout for other promising ecosystems to support as well.

We Partnered with Friends to Create More Opportunities for Indie Teams

In May, we invited a group of our most inspiring peers to re-launch Chainflow's Staking Defense initiative as the Staking Defense League, a coalition of independent infrastructure operators working together to onboard and support new blockchain infra teams. You can learn more and get in on the action yourself in our Discord.

Then, in June, we joined friends ranging from academics to node operators in co-launching the Validator Commons, an initiative to make blockchain governance more inclusive, accessible, and effective. You can learn more and get in touch on Twitter or the Web.

We Connected with Our Communities around the World

In 2022, we racked up more miles than ever, as we joined events across four continents:

• In North America, we joined: Solana Hacker Houses in New York City and Miami; Graph Day in San Francisco; Consensus in Austin (where we co-hosted the Validator Commons meetup); and smaller get-togethers, like the Agoric Cosmos Meetup in Brooklyn (which we sponsored).
• In South America, we joined: Cosmoverse in Medellin and DevCon in Bogota.
• In Europe, we joined: Gateway Conference in Prague; EthCC in Paris; Nebular in Paris (which we sponsored, and where we spoke on the Terra Crash and co-hosted the Validator Commons workshop); MEV Camp in Lisbon (where we spoke on the validator panel); Solana Breakpoint in Lisbon (where we spoke on the decentralization panel); ATOM Lisbon (which we sponsored); and the Staking Summit in Lisbon (where we spoke on the decentralization panel).
• In Asia, we joined: Korea Blockchain Week in Seoul (where we spoke on the governance panel).

Opportunities like these reflect just how much is possible for small, independent, and values-driven teams like ours. And that's only a handful of our highlights from 2022. As always, we feel grateful for the chance to do what we do, alongside the people we do it with.

It's a new year, but our mission remains the same: build the infrastructure that powers a more inclusive, equitable, and fair digital economy. Some parts of that infrastructure will be technical, others will be social; we're looking forward to all of it in this next year.

Let's jump right in with updates from two of our most dynamic protocols: Quicksilver and Solana.

Halting Quicksilver

Quicksilver Comes under Attack

Last month, we joined dozens of other validator operators in launching Quicksilver, a new protocol for liquid staking in the Cosmos. In our previous piece touching on the launch, we noted:

Like some other Liquid Staking protocols, Quicksilver uses an algorithmic system to decide where staked tokens go. One of the considerations in that algorithm is the decentralization of stake, meaning that Quicksilver should—in theory, at least—distribute stake more evenly across all active validators over time, helping to improve decentralization in The Cosmos. While we're supporting the project out of optimism for that impact, we'll keep you posted on how things play out.

In the short time since we published that, things have played out rather surprisingly.

Quicksilver is designed to facilitate the liquid staking of tokens from other Cosmos networks—such as STARs from Stargaze or ATOMs from the Cosmos Hub. In order to activate liquid staking functionality for a given token, the Quicksilver protocol must first go through an "onboarding process" to formally integrate whatever network that token lives on. This onboarding process relies on Interchain Accounts (ICA), a Cosmos feature which allows for an account on one Cosmos chain to natively control an account on another.

Upon launching, the first network that Quicksilver planned to onboard was the Cosmos Hub. And the plan was straightforward: On December 23rd, Quicksilver would activate ICA to create a Cosmos Hub account, and the protocol would control that account to enable liquid staking functionality for the Hub's native token, ATOM. There was just one problem: The process was so straightforward that an attacker was able to exploit some outdated software on the Cosmos Hub to anticipate, and take control of, the Hub account that Quicksilver created. By the time the community caught on, thousands of ATOMs had already been sent to the compromised Hub address.

That's the short version of a long story, and you can get the full details in the Quicksilver protocol team's official report. To help shed some light on how infrastructure teams like Chainflow played a role in resolving the incident, we'd like to focus on one detail in particular: how the Quicksilver community stopped the attack.

Pumping the Brakes on a Blockchain

When the Quicksilver protocol team recognized that the attack was taking place, they moved to initiate something called a "chain halt," an event that would stop the Quicksilver blockchain from adding new blocks—effectively pausing any activity on the network. Halting the chain would both prevent users from sending ATOMs to the compromised address, and allow the Quicksilver protocol team to update the network's code without causing collateral damage to any active users. But actually getting a blockchain to stop isn't easy—in fact, the whole point of a blockchain is to be a system that's really hard to shut down. Unlike on a centralized network, the team building the Quicksilver protocol didn't have the ability to unilaterally pump the brakes. Instead, they needed to convince the decentralized system running the Quicksilver chain to pump the breaks together.

That's where we, and the other Quicksilver validators operators, came in.

On a Proof-of-Stake network like Quicksilver, the decentralized system running the chain is made up of "validators," machines that run the network by doing things like, for example, verifying and adding new blocks to the blockchain. To carry out a chain halt on a Proof-of-Stake network, you need to convince a critical mass of the teams operating those validators to agree to simultaneously pause them. But, what defines a "critical mass" of validator operators?

A given validator's influence on a Proof-of-Stake network is proportional to the amount of tokens that have been staked to that validator. Put roughly: The more stake that a validator has, the more influence it has on the network. The most acute way to measure that influence is by block production; the more stake that a validator controls, the more blocks it gets to add to the chain. Critical mass for a chain halt, then, isn't so much a critical mass of validators as it is a critical mass of the stake controlled by validators.

The magic number for that stake on Quicksilver, and many leading Proof-of-Stake networks, is 33.3: The consensus rules for the network are set up in such way that, if validators that control collectively more than 33.3% of all the stake on the network decide to halt the chain, then the chain will halt. This is simply a threshold built into the network's code. It's also a social convention that's been adopted by Ethereum, Solana, the Cosmos ecosystem, and other Proof-of-Stake networks.

So, when Quicksilver moved to initiate a chain halt, they needed to enlist the operators behind validators controlling at least 33.3% of the network's stake. On more mature chains, we can see a kind of absenteeism, whereby validator operators with more stake (like large, centralized exchanges) are less engaged with the goings-on of the network over time. As you'd imagine, coordinating a critical mass of checked-out operators can be hard. Fortunately for Quicksilver, its chain had only just launched, and the network's validator operators were still very much plugged into the day-to-day events of the protocol.

Like we've noted before, much of crypto is powered by group chats and Discords of independent infrastructure teams. Quicksilver's chain halt was no different. Alongside the Quicksilver protocol team, we joined the other Quicksilver validator operators in the Quicksilver Discord to get the collective infrastructure community up to speed on the attack, and coordinate, with surprising speed, shut-down procedures for validators controlling stake well above the 33.3% threshold. On December 24th, the chain shut down, ending the attack within a day and allowing the Quicksilver community to fix the issues that led to it.

Then, on January 3rd, we joined the other validator operators in relaunching Quicksilver. Plans to reattempt the Cosmos Hub onboarding process are currently in the works.

Decentralized Infrastructure, Strong Chains

Ideally, Quicksilver would have avoided this attack altogether. Nonetheless, the network's response feels hopeful, with the infrastructure community demonstrating that we can coordinate quickly and effectively in the event of a catastrophe. Looking forward, however, we want to highlight a couple of points about blockchain resiliency—for Quicksilver, and for the Proof-of-Stake ecosystem at large.

The first is the critical importance of the people who operate your blockchain infrastructure. Whether keeping up-to-date with the latest patches and upgrades or responding quickly to emeergency situations like a network attack, these operators are responsible for keeping your networks running. It seems that users can take for granted that blockchains are "immutable." But, they're only as immutable as their infrastructure. And, especially on rapidly-evolving networks like Quicksilver, that infrastructure requires a lot of hands-on attention. When you're learning about a new network, make sure to investigate who its validator operators are. Block explorers like Mintscan make this easy by hosting dedicated lists of networks' active validators.

The second point we want to highlight is the importance of decentralizing the infrastructure behind your networks. In the Quicksilver incident, the community coordinated a chain halt to protect the network. But, you can imagine a scenario where a bad actor moves to halt a chain for more nefarious purposes, like holding the network's assets hostage. To prevent these kinds of attacks, a network needs to make it difficult for bad-intentioned parties to control more than 33.3% of its stake. The simplest way to do so is by ensuring that stake is well-distributed across validators operated by many different good-intentioned parties.

There's a special name for the smallest number of independent parties that can halt a chain: "The Nakamoto Coefficient." As a general rule-of-thumb, the higher a blockchain's Nakamoto Coefficient, the more immutable and resilient the network.

We talk about this a lot, but one straightforward way that you can help to raise the Nakamoto Coefficient on your networks is by staking with smaller, independent validators. Consider it the next time you stake, on Quicksilver and beyond.

Rewilding Solana

Moving Past Old Narratives

Solana has had a strange go of it. The network rose rapidly from "alt-L1" obscurity to become one of the highest-valued, most buzzed-about blockchains within months of its "mainnet-beta" public launch in 2021. And, for as long as the network has been live, it's been dogged by accusations of being a centralized wolf in decentralized sheep's clothing. But, what, exactly, have critics meant by that?

In our framework "The Layers of Decentralization," we lay out the two key dimensions that define the decentralization of a Proof-of-Stake blockchain, like Solana:

1. Capital: The money required to make the network run
2. Infrastructure: Where and how the network runs

In terms of capital, Solana has frequently been crticized as a "VC-chain," one that distributed an outsized amount of the network's native token, SOL, to Venture Capitalists and other investors. The most famous of these investors was the FTX-Alameda chimera, which bought a lot of cheap SOL early on, and touted the investment rather publicly. Critics argue that these kinds of high-profile investments artificially pumped the value of SOL through its previous highs.

Now, though, the fiat value of SOL has fallen, alongside the declining overall market and the ongoing implosion of FTX-Alameda, more than 90% from its peak. Obviously, you would not like to see the value of your decentralized system be so closely tied to the fortunes of so few participants.

But, despite the loss in paper value, there's a more optimistic take on the FTX-Alameda fallout. As our founder, Chris Remus, wrote back in November:

Ethereum founder Vitalilk Buterin later shared a similar sentiment:

From the perspective of decentralizing capital, it feels pretty hopeful to see Solana lose some of its biggest whales.

In terms of infrastructure, Solana has been called a centralized database masquerading as a blockchain. One popular meme rebrands the network as "Sqlana," in a nod to centralized SQL databases. But, assessing the decentralization of blockchain infrastructure is as much about narratives as it is about numbers. And, as we've tracked in our own reporting, Solana has quite a compelling narrative for decentralization in some areas, even measuring among the most decentralized blockchains.

One area wherein that narrative is less compelling, however, is governance. Many Proof-of-Stake protocols have adopted some version of a community governance process, wherein token-holders can propose, and vote on, initatives to steer the future of the network. Solana, meanwhile, has kept its future largely in the hands of its core protocol team, Solana Labs, and its primary community organization, the Solana Foundation. In response, some observers have called to mind the adage, "If you want to go fast, go alone. If you want to go far, go together."

Solana has indeed gone fast, embracing a kind of Hot Rod spirit to push the technical envelope for L1 blockchains. And in a new piece detailing its outlook for 2023, the Solana Foundation highlights the following technical areas as top-level focuses for the coming year: Mobile, Reliability and Resiliency, Programmability, Performance, and Security.

Even though "governance" failed to make the list, there are signs that the Solana community is ready to embrace a more inclusive spirit in 2023.

The Solana Community Looks to the Future

The first sign comes from the development of the Solana protocol itself. Historically, few developers have been allowed to propose or implement changes to the software that runs the network. But now, we're beginning to see new opportunities for more participants to contribute.

At November's Breakpoint event, we saw the start of informal discussions around opening up governance on the protocol. And today, we're beginning to see activity increase around the Solana Improvement Document (SIMD) process, currently the most formal avenue for Solana developers to propose and discuss (if not exactly vote on) changes to the protocol.

The second sign that Solana is ready to "go together" comes from the social initiatives that elevate the network beyond the protocol. Solana boosters have often touted a vibrant community of "builders" as one of the network's competitive advantages over other L1s. Much of the most visible work to foster this community has come from the Solana Foundation directly, in the form of its global "Solana Hacker House" program. But now, we're seeing that start to change, with independent community members developing their own social programming.

For example, this week, Chainflow is joining dozens of other teams from across the Solana ecosystem in hosting the Sandstorm Hackathon, a fully-remote, independent event to foster community-driven innovation on the network. Led by two Solana teams, LamportDAO and Helius Labs, Sandstorm is an ambitious effort to re-energize developers on the protocol after the dramatic end to 2022. The Solana Foundation has joined as a sponsor, but the event seems to be a refreshingly grassroots initiative.

We'll share more about Sandstorm as the hackathon develops. In the meantime, check out our "Decentralized Infra" track, and consider joining to help decentralize Solana while competing for our prizes: $2,000 in USDC and six months of free enterprise-grade RPC access. You can learn more and sign up at the Sandstorm Discord. The event ends on January 23rd.

BONK, Briefly

And then there's BONK.

"Memecoins" are cryptocurrencies with no inherent utility beyond speculation. "Dog Coins" are a subcategory of memecoins that are, well, named after dogs. With that in mind: "Bonk Inu" (identified by the ticker "BONK") is a new Dog Coin on Solana that has, in recent weeks, drawn a lot of attention from the network. (Some people have been calling it "Solana's first Dog Coin," but that feels like Samoyedcoin erasure.)

The Decentralized Exchange (DEX) Orca, for example, has seen quite a bit of recent action from BONK. And while it's not unheard-of for a memecoin to catch fire for a time, it feels unsual for one to espouse a kind of righteous, populist indignation:

What does BONK mean in the face of Solana's movement toward a more inclusive and democratic future? Who knows. Some signs suggest that the winds may already be changing for the token.

Regardless of what happens with BONK, or any single project on Solana, it's clear that a shift is taking place on the network, toward a more community-led spiri  . As Solana supporters since before the network's public launch, we're excited to do our part to center decentralization in these important next steps.

Eyes Peeled

Here are a few threads we’ll be keeping our eyes on over the coming weeks:

Livepeer Integrates with Bundlr for Decentralized Video Storage and Streaming 📺

We've previously highlighted Livepeer (on which we've operated since 2018; find us here) as a potential player in the future overlap between Crypto and AI. In the present, meanwhile, Livepeer's primary application concerns video transcoding, the process by which streaming video is made viewable in different formats. Given that streaming video is the largest single driver of Web traffic, there's a lot of transcoding going on around the world at any given moment. This is a big opportunity space to work within.

Last week, Livepeer shared some details about their new integration with Bundlr, a decentralized storage platform. Esentially, the integration will leverage Bundlr for the storage of video files, and Livepeer for their transcoding.

This creates an interesting synergy that opens up more of the streaming video stack to blockchain-backed decentralization. We're curious to see how partnerships like this catalyze (or fail to spark) the adoption of more decentralized infrastructure for the Web.

Check out Livepeer's recap of a recent chat with the Bundlr team, here:

Flow Considers the Onboarding Experience 👩‍👧

Flow is an interestingly consumer-focused blockchain (on which we've operated since genesis in 2020; find us here) that powers, among other things, the trading card-like "NBA Top Shot." The network is notable, from a decentralization standpoint, for a taking a "decentralize over time" approach.

This, then, feels noteworthy: In a recent piece, the Chief Architect of Flow ponders a "hyrbid" custody model that would allow users to start with a custodial account, then transition to self-custody. You can read the full post, here.

While, in many cases, the "decentralize over time" approach is a bit of "Decentralization Theater", Flow has a track record of actually doing it. Last year, for example, the network finally launched permissionless smart contracts.

This latest custody proposal is, of course, speculative, but we'll be following along closely. For our part, we're leading our own research into onboarding and wallets, and we love to see protocols openly question parts of the crypto user experience that have begun to crystallize around user-unfriendly patterns.

The Cosmos's Interchain Security Timeline Comes into Focus ⚛️

In our last update, we wrote about the Cosmos's forthcoming Interchain Security (ICS) feature:

ICS solves [the challenge for new chains of spinning up their own validator sets] in a clever way by simply allowing new chains to run using the validator set of an existing chain. In the official ICS vocabulary, the new network becomes known as a "consumer chain," because it's "consuming" (or, "leasing") security from the existing network, which in turn becomes known as the "provider chain" because it's "providing" security to the new network.

Cosmos commentator "Robb Stack" sums up the upcoming timeline of events for ICS's launch nicely:

And researcher "Thyborg" breaks down next steps for the Hub:

The first major step to watch will be the passage the next major upgrade for the Cosmos Hub, the "Rho" upgrade. (Chain updates often have fancy code names like this). This upgrade hasn't been put up for a formal vote yet, but the details are being hashed out on the Cosmos Forum now.

Nakaflow Maintenance Update

Nakaflow.io is our tool for comparing the Nakamoto Coefficient for stake distribution on more than a dozen of the leading Proof-of-Stake blockchains (like Ethereum, Solana, the Cosmos Hub, and more). The Nakaflow site is currently down as we make some upgrades to the backend and user interface.

We'll share an update on Twitter when the tool returns. We appreciate your patience in the meantime.

FTX's rapid blow-up, and its far-reaching consequences, have sent projects across the space spiraling. And this is, of course, just the latest in a series of developments this year that have shaken the crypto ecosystem. How'd we get here? Researcher Molly White and Bloomberg's Matt Levine have some helpful explainers:

Molly White:

1. The FTX collapse: the latest revelations (part three)
2. The charges against Sam Bankman-Fried and the first FTX Congressional hearing

Matt Levine (paywalled, free with newsletter sign-up):

1. FTX's Balance Sheet Was Bad
2. How to Do Fraud at a Futures Exchange

We're watching along with everyone else to see just how this complicated series of dominoes will continue to fall, and our thoughts are with the many people affected.

Yet, for as much as the scandals and scams rampant in crypto may dominate the conversation at the moment, there are more hopeful developments taking place in some of the field's less visible corners. In this piece, we're going to share an update from one of them: the Cosmos, a unique crypto ecosystem on the cusp of a game-changing innovation.

Let's dive in.

The Cosmos and Its Hub

Historically, when two different blockchains have wanted to share data with each other, they've required something called a "bridge," an application that allows objects on one chain to be represented as "equivalent" objects on the other. Each side of the bridge retains distinct infrastructure—separate code, separate hardware, etc.—but these two sides can now interact, in a way, "on-chain." Bridges have succeeded at enabling formal coordination across networks, but have proven over time to be rather problematic. This year alone has seen a number of damaging, high-profile attacks made possible by exploits in bridge code.

Bridges aren't the only way to share data among blockchains, though. Modern chains, unburdened by the technical constraints of longer-running networks like Bitcoin and Ethereum, are being built from the ground-up with modularity and interoperability in mind.

"The Cosmos" is an ecosystem of such chains, united by their adoption of a set of standards called the Inter-Blockchain Communication (IBC) protocol, which allows compatible networks to share data natively among themselves; no bridges required. The basic vision behind the Cosmos is for the Web to be run on a collection (a… cosmos?) of "app chains," independent blockchains that serve their own purposes while connecting seamlessly with other networks. Sitting at the heart of this vision is the oldest of these app chains: the Cosmos Hub.

In function, the Cosmos Hub was built to be simple. Like Bitcoin, it eschews complex smart contracts in favor of one primary use case: transferring tokens (in this case, ATOMs, the native tokens of the chain) between accounts. In concept, however, the Cosmos Hub serves a more complicated purpose. As the first, and most battle-tested, IBC network, the Cosmos Hub is the de facto financial heart of the Cosmos, with ATOM acting as a kind of reserve currency for the broader Cosmos ecosystem. The Interchain Foundation, one of the core development outfits behind IBC and the Cosmos, described this vision for the Cosmos Hub as a "port city."

Since the Cosmos Hub went live in 2019, we've seen this vision largely play out, with the ATOM serving as the most liquid on-/off-ramp for capital to flow through the Cosmos ecosystem. But, while this simplicity has remained a virtue for many in the Cosmos, a growing segment of the community has pushed to expand the Cosmos Hub to do more.

In April of this year, that “do more” segment nearly succeeded, with the introduction of a governance proposal to enable new smart contract functionality on the network. That particular initiative failed, but it set the stage for an even bolder proposal that was made public at the Cosmos's premier event, Cosmoverse, in September. This new initiative, branded "ATOM 2.0," called for a set of sweeping changes that would introduce new features to the Cosmos Hub and, in theory, drive more value to the ATOM and its holders. After weeks of discussion, counter proposals, and counter-counter proposals, ATOM 2.0 ultimately failed to pass a community vote as well.

So, where does that leave the Cosmos Hub today? With its long-term direction uncertain, the Hub's community has turned its attention to the launch of a less controversial, and long-simmering, feature for the network: Interchain Security (ICS).

Interchain Security, Briefly

We noted above that even if two blockchains are connected by a bridge, they remain two distinct networks, with separate software, separate hardware, etc. The Cosmos isn’t so different, in that, even if two blockchains are IBC-compatible, they remain separate chains with distinct back ends. They may be natively interoperable with other networks in the Cosmos, but they're still responsible for maintaining their own infrastructure.

This presents a number of challenges for new chains, including the particularly vexing problem of spinning up their own healthy, well-functioning validator sets. The Cosmos Hub, to take an example, runs on a set of 175 active validators, while Regen Network, to take another, has its own, distinct set of 75 active validators. Each network within the Cosmos is responsible for maintaining its own respective validator set. In an evironment where validator operators are short on resources and different chains are competing for their attention, this can be a pretty tall order.

ICS solves this problem in a clever way, by simply allowing new chains to run using the validator set of an existing chain. In the official ICS vocabulary, the new network becomes a "consumer chain," because it's "consuming" (or, "leasing") security from the existing network, which in turn becomes a "provider chain" because it's "providing" security to the new network.

This represents a complicated bargain for the Cosmos: on one hand, ICS will make it easier than ever for new app chains to launch with access to healthy, robust, and field-tested validator sets (good for decentralization!). On the other hand, it explicitly affords even more power to entrenched validator sets, scaling their centralization characteristics from one chain to, potentially, many others (bad for decentralization!).

No matter how you slice it, ICS will make the health of validator sets in the Cosmos more consequential than ever. It’s critical, then, that validator operators are well-prepared for its launch, and, this month, we joined dozens of other infrastructure teams in completing the final major prep program ahead of ICS’s 2023 rollout. It was called the “Game of Chains.”

On Court in the Game of Chains

Game of Chains was what's known as a "testnet program," which is like a series of exercises in a dummy version of a network, one that involves only "fake" transactions and valueless tokens. Safely removed from real-world consequences, testnet programs act as laboratories for teams to explore (and, often times, fumble) ideas before taking them live with users.

Events like this are typically invisible to non-DevOps engineers (that is, most people), so we wanted to share a closer look at what Game of Chains was, and how Chainflow participated as part of our longstanding history of supporting the infrastructure behind the Cosmos.

Game of Chains was organized and coordinated by Hypha Coop, a cooperatively-owned consulting team with a growing footprint in the Cosmos ecosystem. You may recognize them as the custodians managing the Cosmos Hub's ongoing community governance process via the @CosmosGov handle and the Cosmos Forum. In fact, we worked with Hypha earlier this year to launch the Validator Profiles section of the Forum. Joining Hypha in organizing Game of Chains were the Interchain Foundation and Informal Systems, two core developers on IBC and the Cosmos.

The program was structured as a dummy environment, and a series of tasks for us and the other participants to complete within it. Essentially, these tasks served as practice reps for all the major infrastructure-side mechanics that ICS will call for in the real world. We tackled them in three phases:

• Phase One: the organizers launched an initial provider chain, then we voted to bring two new consumer chains online, and spin up validators to run them.
• Phase Two: we voted to bring even more consumer chains online and run them.
• Phase Three: all bets were off, and participants could create our own governance proposals and launch our own chains.

In all, we trialed spinning up and shutting down dozens of new chains, each interacting with ICS features in different ways.

To get a sense of what, exactly, that looked like, check out the testnet governance page, where you'll find the nearly 100 proposals processed over the course the event, each calling for approval from the community of testnet participants to do things like launch new chains, shut down old chains, and modify various parameters across this interchain mini-ecosystem. Put simply: Game of Chains was a ton of work for everyone involved.

You might be wondering, then, "Why participate in the testnet at all, if it’s not real, it's hard, and you can just support the mainnet later?" Well, first, and most importantly: we're an infrastructure team; this is what we do. We've been supporting testnets and other infrastucture efforts in the Cosmos for more than five years, and it remains a core focus of ours to build the infrastructure powering the ecosystem. Testnets like this are crucial for making sure that that infrastructure is ready for primetime. Second, and perhaps less visibly: Game of Chains, like some other "incentivized testnets," was designed with a built-in reward structure.

You'll notice, in the official Game of Chains task list, a section detailing the "point system." Any time a team completed a task, that team was entitled to official "participation points." Throughout the program, we and the other participants submitted evidence of the various tasks we finished, and our collective participation was tracked on a shared "leader board."

The deal for testnet participants was essentially this: the more points you earned from completing tasks, the more rewards (like, say, ATOM delegations to your mainnet Cosmos Hub validator) you could be entitled to in the real world, later.

So, how’d we do? If you're feeling really frisky, you can find our validator—along with each transaction, vote, etc. that we participated in—here. Otherwise, here's a high-level breakdown of everything we did to support the testnet:

• Phase One: we voted to launch the first batch of two pre-defined consumers chains, and we launched validators to begin creating blocks for these new chains.
• Phase Two: we voted to launch the next batch of, this time, four pre-defined consumer chains; and we launched validators to begin creating blocks for them.
• Phase Three: we voted to reject invalid proposals; we voted to accept new consumer chains; we voted, in fact, on 70 of the 87 available of proposals; and we started to launch a type of support node called a "Relayer," but were cut short when the test chains were halted earlier than originally scheduled.

As of writing, the leaderboad was still being updated to reflect our final point toal. We look forward to seeing our final point score at the end of the process later this month.

Regardless of our final score, we're coming out of the program feeling inspired. Having spent years operating on, and helping to design, testnets, we can say with some authority that the Game of Chains testnet was one of the most exciting testnets we've ever joined. A few reasons why:

• ICS will be a game-changer for the Cosmos: We've been supporting the Cosmos since the very beginning, and this represents the biggest innovation since the launch of IBC. We're eager to see how this new feature set translates to the real world, and the tesnet organizers designed smart program tasks that helped to battle-test the newest functionality. We're feeling ready.
• Hypha Coop delivered a well-organized experience: Testnets are chaotic, and often deviate from the planned roadmap in surprising ways. Having Hypha, with their extensive familiarity with the Cosmos community, on board helped to provide a comparatively smooth and productive program.
• Our fellow participants were dialed-in: Something that most people don't have visibility into is that a lot of what makes crypto tick is a bunch of Discords and group chats among infrastructure operators, all helping one another troubleshoot various issues. This is true of mainnets, and doubly true of testnets, where we're chatting constantly with other teams to break down tasks and provide technical support on tricky infrastructure issues. Game of Chains was no exception, and we're thankful for all the support we received from other participants. We feel it’s especially important to note here that the most active contributors to Game of Chains were the teams behind smaller, independent validators. Just like on mainnets, bigger validators and exchanges stayed, for the most part, on the sidelines. Something to keep in mind when considering where to delegate your tokens: it’s the indie teams who make crypto work!

As we turn our attention to the mainnet launch of ICS in early 2023, we're feeling sincerely grateful for all the hard work teams across the ecosystem are putting in to make sure it's a success. But we're also feeling a bit nostalgic coming off this latest testnet. You see, Chainflow was born from the earliest efforts to build out Cosmos infrastructure, and, as we look to the future of the ecosystem, we've also been reflecting on our history growing up in the Cosmos.

Growing up in the Cosmos

ICS represents a massive undertaking for the Cosmos community, and a significant innovation in launching new blockchains. But this is just the latest in a long line of innovation from the Cosmos ecosystem.

Take, for example, Proof-of-Stake consensus. While Ethereum transitioned only a few months ago to a Proof-of-Stake mechanism, Cosmos blockchains have been trialing Proof-of-Stake for years. Back in 2017, the early Cosmos Hub team convened a working group of infrastructure providers to explore how to operate a sustainable Proof-of-Stake network. This set the stage for a number of blockchain infrastructure projects that have grown significantly in the years since—Chainflow included. Our Founder, Chris Remus, launched the organization on the back of participating in this original working group.

In 2019, the Cosmos held a pioneering Proof-of-Stake testnet program called the "Game of Stakes” (the prequel, in a sense, to Game of Chains). Alongside the other participants, we battle-tested many of the ideas, like staking incentives and validator rewards, that have now spread across the Proof-of-Stake ecosystem to networks like Ethereum, Solana, and others. You can see some of our early feedback on the experience, here.

Game of Stakes was one of our most formative experiences as an enterprise-grade validator operator. Just as we’re earning rewards from the Game of Chains program, we were a Game of Stakes “winner," and, as a reward, we earned some initial grant tokens that helped us kickstart our operations. Our Cosmos Hub validator was our first mainnet launch, and remains our longest running validator in a portfolio that now includes 16 (and counting!) mainnets.

As an active participant on the backend of the program, we got to work with an incredible community developers and infrastructure builders who shared our values around making the digital economy more accessible and inclusive. And, perhaps most importantly, our experiences in these early years of the Cosmos showed where Chainflow could help to contribute to the broader movement for decentralizing the Web.

Here are just a few of the trends we saw first in the Cosmos, and our ongoing efforts to respond to them:

• Running a successful testnet is the key to a successful mainnet: We've advised the teams behind newer Proof-of-Stake protocols, like Regen Network and Solana, on how to run their own successful testnets (get in touch at hello@chainflow.io if you'd like us to do the same for your team!).
• Validator operators lack standard resources to support their work: We've built tools, like Cosmos Validator Mission Control to help make it easier for other teams to operate validators of their own.
• Governing a Proof-of-Stake protocol democratically demands a literate, engaged community: We've remained active participants in governance across our protocols, offering feedback and sharing our thoughts on different proposals (the latest which you can see at our Governance Page).
• Infrastructure operators are often siloed away from other teams: We've co-founded partnerships, like the Staking Defense League and the Validator Commons to hold space for indie infrastructure operators to share resources and support one another.
• Centralization is a trend that threatens the whole point of crypto: We've written extensively over the years (here on our blog and elsewhere) to help educate around decentralization, and launched, earlier this year, Nakaflow, a tool that helps to track and compare the decentralization of stake across more than a dozen of the leading Proof-of-Stake networks.
• Community is at the core of decentralization: We’ve sponsored events and gatherings, including this year’s Nebular Paris and ATOM Lisbon, to help support the kinds of value-aligned community that the movement for decentralization demands.

It's clear, in reflecting on these efforts, just how influential the Cosmos has been in our growth as a team. And, as we continue to grow into the new year, the Cosmos remains one of our major focuses. We're operating infrastructure on eight IBC-compatible mainnets today, and we're still getting into the dirt with new testnets.

With Game of Chains, we’re closing out 2022 as a banner year in our long history in the Cosmos. We can’t wait to see what 2023 has in store.

Eyes Peeled

Here are a few threads we’ll be keeping our eyes on over the coming weeks:

How Is the FTX Blowup Affecting Staking on Solana? ⛵

News of FTX collapsing sent the fiat price of SOL, Solana's native token, crashing. How did that crash affect staking dynamics on the network? Our friends at Staking Rewards, one of the best aggregators of data in the staking economy, shed some light on how stake has moved since November.

Also of note: in our own tracking on Nakaflow, we've seen Solana's Nakamoto Coefficient by stake, a measurement of how decentralized control of stake is across the network, hold steadily near the top of our charts throughout the FTX developments.

Crypto ❤️'s AI

With the recent launch of ChatGPT, likely the most advanced text-generating AI ever available to the public, tech discourse is, once again, buzzing about the possibilities for AI. While the current media hype-cycle around it will surely die down, AI is no doubt only going to become a bigger part of the conversation moving forward. One of the most interesting parts of that conversation is the opportunity for crypto to power the infrastructure behind future AI systems. To wit:

Akash is a protocol (which we operate on, here) that facilitates access to decentralized cloud computing. While the network's offering has to-date focused primarily on CPU-based computing power, Akash founder, and cloud-computing veteran, Greg Osuri has been previewing the protocol's forthcoming expansion into GPU-based computing power. You know what requires GPU-based computing power? AI. Some quotes from Osuri here, here, here, here, and here. That’s quite a lot of foreshadowing.

Livepeer, another protocol (which we also operate on, here) that facilitates decentralized cloud computing, has long offered GPU-based compute, primarily for streaming video applications. Livepeer CTO Eric Tang has been previewing AI on the protocol for years.

There's a running joke that capital and talent are fleeing crypto for AI, but it'll be interesting to see how these two fields can reinforce, rather than cannibalize, each other.

The Graph Turns Two 🎂

The Graph is a protocol that allows for the decentralized structuring and querying of data from blockchains, like Ethereum. This month marks the 2nd birthday for The Graph's mainnet (which we've been operating on since it first launched; find us here), and it's exciting to see the remarkable growth the network has had in that time. The Graph put together a highlight reel from different corners of the ecosystem to celebrate.

The big question on our minds heading into 2023 is: how will the protocol's transition next quarter from its centralized "hosted service" to its fully-decentralized offering go?

Liquid Staking Enters the Cosmos 🏄‍♂️

This month, we joined dozens of other validator operators in launching the mainnet for Quicksilver (find us, here), a new IBC network that enables "Liquid Staking" in the Cosmos.

What's Liquid Staking? Let's say a user wants to stake their tokens with a validator operator like Chainflow. In "Traditional Staking," the user will delegate their tokens directly to the validator. While those tokens are staked, they're effectively "locked" with the validator, and the user can't do anything with them. The tokens are, in other words, "illiquid," since they can't move while staked.

In Liquid Staking, the user doesn't delegate their tokens directly to a validator—instead, they delegate their tokens to a Liquid Staking protocol, which in turn does two things. First, it passes those tokens onto one or more validators, based the rules of the protocol (some use algorithms to select which validators receive stake, while others use hand-picked whitelists). Second, it creates what's called a "liquid staking derivative" (LSD) of the user's staked tokens. This LSD is a new type of token which acts—in theory, at least—as a claim to redeem the original tokens that the user staked. The major difference is that the LSD is "liquid," meaning it can be traded around while the original tokens remain locked in the staking protocol.

You can imagine how this might get complicated: can the LSD be used anywhere a normal token can? What happens if something breaks with the Liquid Staking protocol while your tokens are locked in it? Quite a few Liquid Staking projects have sprung up over the past couple of years, and, with the launch of Quicksilver, this emerging field has now entered The Cosmos.

Like some other Liquid Staking protocols, Quicksilver uses an algorithmic system to decide where staked tokens go. One of the considerations in that algorithm is the decentralization of stake, meaning that Quicksilver should—in theory, at least—distribute stake more evenly across all active validators over time, helping to improve decentralization in The Cosmos. While we're supporting the project out of optimism for that impact, we'll keep you posted on how things play out.

Chainflow Operations Note

'Tis the season: Chainflow will be taking a programming break from December 24th, 2022 through January 1st, 2023. We'll still be monitoring our infrastructure operations during that time and will be prepared to respond to any emergency issues, but we'll be a bit quieter on our other channels while the team takes a break after a busy year.

As always, we're sincerely grateful for your support, and wish you and yours all the best. See you in the new year.

On Progress and Voting No

Chainflow's excited to see the attention that Cosmos is beginning to attract. It's  been a long time coming. Still, we believe things develop on their own time  for their own reasons.

We attended Cosmoverse 2022 and have followed the Atom 2.0 discussions since then. We've followed the online discussions to the extent we feel they've been constructive.

We also had recent discussions at the Cosmos Lisbon meetup, within the Validator Commons and with our friend, Sacha Saint-Leger.

At this time we choose to vote "No" on Cosmos Proposals 81, 82 and 83.

This post will explain why.

Broad, Fast and Forward

These proposals, particularly 82 and 83, represent diverse viewpoints, strongly presented by various humans. They each cover a very broad range of topics and concepts.

Because they're so broad, we're not able to accept either in its entirety. This is why we're voting "No" on both.

We're  also concerned that a "Yes" vote for either charts course down an irrevocable and unwavering path for Cosmos. Time has shown that for decisions that become this politically and emotionally charged, a "Yes" vote typically sends the  "winner" sprinting out of the starting gate, racing toward a point on the horizon described in the "winning" proposal.

We believe this  type of pursuit can become counterproductive. There's only so much we  know now. Circumstances change fast. There's a good chance that the  desination should change or at least be adjusted over time. However it's  very hard to change direction when sprinting.

Fewer than two  months have passed since the original Atom 2.0 paper was released. It's  been amended since then. Time gets compressed when emotions run high.

The decision presented by proposals 82 and 83 needs time to be discussed without artificially imposed deadlines, i.e. by a proposal voting  period. We feel more time is needed to plot a course with repercussions of this magnitude. We need an incremental approach, to take smaller steps and recalibrate along the way.

So it's for these reasons we voted "No" on proposals 82 and 83.

Regarding  proposal 81, it appears to be an attempt to override the current on-chain governance process. While the idea itself may have merit, we feel that a relevant proposal would propose changing the on-chain  governance process, rather than overriding it. It's for this reason  we'll vote "No" on proposal 81.

This is Our Chance to do Better

Our  world is more polarized than ever before. While we share a common humanity, society increasingly focuses on our differences, prodded by those in power, who then exploit the rifts. The Cosmos community has a chance to do better than this.

However, it will be a messy process and take time. It will take more time that the current proposals provide.

We  believe these trade-offs are worth it, to not replicate the polarizing issues so prevalent in today's society and demonstrate that we're  capable of existing in a healthier way, to build a stronger, more  cohesive and resilient community.

We remain more excited than ever about Cosmos' prospects and plan to be here to support it long into the future.

Decentralization takes many forms. This is true in the broader crypto/Web3 world, and especially so in the growing Proof-of-Stake (or, simply, “staking”) economy.

Plenty of people in the staking economy talk the talk of decentralization, but it’s clear, when you look beneath the surface, that far fewer actually walk the walk. Various forces are causing Proof-of-Stake networks to centralize into top heavy oligarchies, but participants don’t seem to notice. Why?

Big-money interests are engaging in a kind of “decentralization theater” in order to deflect attention away from their accumulation of power in the staking economy. Instead of a crypto revolution, we’re staring down centralization by another name.

There’s a disconnect here—one that threatens everything we’re working toward in Web3. In order to address it, and preserve the promise of the staking economy, we need a shared movement to recognize and better understand centralization on Proof-of-Stake networks.

This piece takes a step forward in that movement by defining a simple framework that we can use to identify—and, ultimately, address—the sources of centralization across the staking economy.

The Layers of Decentralization

Rather than thinking of the different forms of decentralization in the staking economy as separate things, we can understand them as the connected layers of a “decentralization stack.”

Those layers include the following:

• Infrastructure layer
  • Technical Sub-Layer
  • Operator Sub-Layer
• Capital Layer
  • Owner Sub-Layer
  • Consolidation Sub-Layer
  • Custodian Sub-Layer

The Infrastructure Layer is the foundation of the staking economy; it defines where and how a Proof-of-Stake network runs. On top of the Infrastructure Layer is the Capital Layer, which defines the capital required to make the network run.

For a network to be truly decentralized, it must be decentralized at both the Infrastructure Layer and the Capital Layer. Infrastructure needs to be diverse enough to provide security and resilience, and Capital must be distributed among enough entities to ensure that a small number of them can’t collude, or be coerced, to censor or otherwise manipulate the network.

We need to understand these layers and the mechanics at work within them in order to identify the threats posed by different centralization vectors. All of these vectors pose risks, but some represent a more urgent threat than others. We’ll see shortly that, while infrastructure represents the foundation of any network, it’s Capital that captures the real power.

Infrastructure, the Foundation

On a Proof-of-Stake network, a layer of validator infrastructure makes the network run and secures it. That infrastructure layer is complex, and we’ll break it down into the following sub-layers:

• Infrastructure layer
  • Technical Sub-Layer
  • Operator Sub-Layer

The Technical Sub-Layer defines the client software, physical servers, data centers, and networks that comprise the chain’s validator infrastructure. The Operator Sub-Layer defines who operates the validators themselves.

(For simplicity’s sake, let’s assume that the same entity runs collectively the servers, data centers, and networks. In this way, the Technical Sub-Layer can be used as a proxy for cloud service providers, such as AWS and GCP. In reality, this can also be broken down further, but that’s beyond the scope of this piece.)

The centralization vectors across these sub-layers may not be readily apparent—but, to see them, just follow the money.

The Technical Sub-Layer generates revenue by providing server, data center, and network services to validator operators. As a result, it’s not uncommon for any one provider of such services to sell these services to many different customers from the Operator Sub-Layer.

You can see where this is going: the same server (in the case of virtualization) and/or data center may house multiple validator operators; and many operators may ride the same network connections, both from the data center to the network backbone and within the network backbone itself. In this way, heavy infrastructure deployments on market-leading cloud providers are a major vector for Infrastructure Sub-Layer centralization.

The Operator Sub-Layer, on the other hand, generates revenue by providing staking services to capital owners (whom we’ll get to in the next section). These operators may work on behalf of their own capital, and they may also sell staking services to third-party capital owners. Operators in the latter case are commonly referred to as “staking-as-a-service” (StAAS) providers.

These mechanics are rarely clear to the average user. Block explorers—the window through which most participants view a network’s validator set—typically display only the capital owner behind a validator. In some instances they don’t even do that, displaying only a crypto address as the validator identifier.

This lack of insight masks the centralization that happens at both the Technical and Operator Sub-Layers. (This makes it all the more refreshing to see a project like validators.app, an example of the Solana network community increasing Infrastructure Layer transparency.)

A StAAS company’s typical customer is a large, and usually institutional, capital owner. In pursuing these customers, StAAS businesses operate according to the typical high-growth, VC-funded playbook: they raise large rounds of funding at huge valuations—some achieving the dubious “unicorn” status of being valued at greater than $1 billion—and chase growth to both justify and raise their valuations even higher.

To fuel this growth, StAAS companies must capture as much market share as possible, by selling staking services to as many capital owners as possible. These growth motives lead to further centralization.

In a perfectly decentralized Infrastructure Layer, stake would be equally distributed across providers at both the Technical and Operator Sub-Layers. In practice, however, the mechanics above cause stake to centralize among a very small number of very large infrastructure providers and validator operators.

Troubling as it may be, centralization in the Infrastructure Layer is often overlooked because most staking network analyses focus on the Capital Layer. But, as we’ll see in the next section, we must indeed be concerned about the centralization of capital.

King Capital

Like the Infrastructure Layer of the staking economy, the Capital Layer is complex. In this framework, we’ll break it down into three sub-layers:

• Capital Layer
  • Owner Sub-Layer
  • Consolidation Sub-Layer
  • Custodian Sub-Layer

The Owner Sub-Layer defines the individual to whom capital, in the form of network tokens, ultimately belongs. The Consolidation Sub-Layer defines the groups—like institutions, funds, and exchanges—that control and consolidate capital from different capital Owners. The Custodian Sub-Layer defines the third parties that hold capital on behalf of many different Owners and Consolidators.

Owners, Consolidators, and Custodians deploy capital, in the form of stake, to validator infrastructure to run and secure Proof-of-Stake networks. How, exactly, does that work?

Validators need to hold a minimum amount of staked capital to operate in the network’s mainnet set of active validators (sometimes referred to in shorthand as “the active set”). Thus, it’s the combination of capital and infrastructure that makes a Proof-of-Stake network run.

In this way, capital is intrinsically linked to power: more capital equates to more power, and vice versa. There is a direct correlation between the amount of capital a network participant holds, and the power they have to censor the network, stop it, and vote to influence its future direction.

Put simply: capital is king, whether we like it or not. Without decentralizing capital, true decentralization can’t exist.

As in the legacy economy, capital in the staking economy begets further capital. Validators on a Proof-of-Stake network earn returns, in the form of more capital, as a reward for securing the network. That return is proportional to the amount of capital that’s already staked to the validator. As such, capital compounds early and fast. So too does the power of the capital holder. Many justify this using the “skin in the game” argument, while brushing off the “rich get richer” problem.

In a perfectly decentralized Capital Layer, capital would be spread evenly across a wide range of individual capital Owners. These individual capital Owners would then stake their capital evenly to a spread of validator operators. This even distribution would create an equitable balance of power across the network infrastructure and within its governance process.

In practice, however, capital is increasingly accumulated by Consolidators, like institutions, and held by Custodians, like centralized exchanges. This causes large amounts of capital to centralize at each of the capital layer’s three sub-layers.

This further compounds centralization on the Infrastructure Layer since Consolidators and Custodians often deploy their capital to one of a few large infrastructure providers and/or operators. In some instances, an institution (owner), an exchange (consolidator), and a custodian may even be operated collectively by the same entity.

It’s worth noting that the capital which gets deployed onto Proof-of-Stake networks is often accumulated within the legacy economy before being deployed to staking networks. This creates a bridge of privilege into the Web3 world that only those with accumulated privilege can afford to cross.

These mechanics enable Consolidators and Custodians—especially institutions, funds, and exchanges—to accumulate considerable, and often outsized, control of the networks on which they hold large stakes. Their deployment to a small number of infrastructure providers and validator operators further increases infrastructure centralization, causing the networks, and ultimately the staking economy, to become more fragile.

Seeing the Truth behind Decentralization Theater

We’ve seen that centralization can occur at different points throughout both the Infrastructure and Capital Layers. But, where do we find the biggest threats to the staking economy?

Without capital, nothing else matters. Without capital, validators have nothing to do and a network simply won’t run. This means that points of capital accumulation and consolidation within the Capital Layer are ultimately the most powerful and dangerous vectors for centralization.

Not far behind, however, are third-party centralized infrastructure providers, like large StAAS companies. They actively work to accumulate as much capital as possible on their infrastructure, and this behavior causes them to operate as a primary centralizing force within the networks they operate on.

This is compounded by the fact that they’re pursuing the high-tech, VC-funded, Silicon Valley business models that require unlimited growth to justify huge fund-raising rounds. The business plans these providers follow are orthogonal to the true values of decentralization.

When asked (albeit rarely) about whether they’re centralization vectors, these large, third-party infrastructure providers often fall back to “decentralization theater”—the art of supporting decentralization while actually causing centralization.

A common example is that companies will claim to “decentralize themselves” by not running all of their systems on, say, AWS. From a technical perspective, that’s helpful if true. But, like much of decentralization theater, the reality may differ from the message. Exchanges, for instance, run almost 33% of Eth2 validators today, and deploy sometimes thousands of validators using a single Eth2 client implementation.

Regardless, these explanations don’t address—at all—the fact that capital still accumulates with these large, centralized companies. And remember, it’s the capital accumulation that really matters. Because capital holds the power, the efforts these large StAAS providers make to attract as much capital as possible more than cancel out any benefit we might feel from their efforts to decentralize their infrastructure.

Consider a common argument among larger operators: that they can’t control how much stake they attract. While this may be true technically, there are many steps they can take socially—like actively discouraging new stake while redirecting it to smaller operators.

Some StAAS providers claim to make staking more accessible. In reality, the prices these providers charge make staking more accessible only to the large capital holders who can afford it—rather than the individual token holders who can truly help to decentralize staking networks.

In the end, all of these arguments are smokescreens; they’re intended to deflect from the centralizing influence these providers have on the staking economy, and protect the business models that require them to operate this way. This type of behavior is decentralization theater in its truest sense: decentralization is reduced to nothing more than a platitude.

It’s only with a nuanced understanding of the layers of decentralization that we can work together to counter these centralizing forces. If we don’t, the staking economy will be no different from the legacy economy and the power structure it enables—controlled by a small number of wealthy stakeholders with an outsized influence.

In fact, due to the rapidly compounding economics of staking networks, the staking economy could end up being controlled by an even smaller number of even wealthier stakeholders. And if that’s all the results from the Web3 movement, then what’s the point of this crypto revolution anyway?

Special thanks to Mario Laul (@mlphresearch) for feedback throughout the development of this piece, and to Lucas Griffin (@GriffinLucas) for editing.  

For more resources and discussions around the forces shaping Web3 and the staking economy,  follow Chainflow on Twitter (@ChainflowPOS) or join us on Telegram (t.me/chainflowpos).

“Aligning money towards a life that lets you do what you want, when you want, with who you want, where you want, for as long as you want, has incredible return.”

“The highest form of wealth is the ability to wake up every morning and say, ‘I can do whatever I want today."

To me, the concept of freedom speaks through these two quotes.

Ewoki of Gitcoin adds another important perspective—to paraphrase: "Ethereum was not created to make you wealthy but to make you free."

I truly believe this, and carry this thought through to the general potential crypto holds to create a better world.

Adding everything together, the way I see it is that:

1. Freedom and happiness are very tightly linked.
2. In today's capitalism-run society, a certain amount of capital is required for humans to enjoy freedom.
3. Crypto or Web3, however you want to refer to it, is creating new opportunities for humanity to accumulate capital and, if done right, will cause this capital to be distributed more equitably than the current economy allows.

I feel grateful each day—even multiple times per day—that building Chainflow has allowed me to begin experiencing this freedom. I believe I'm a better version of me, for myself and those around me, as a result.

My primary motivation to continue growing Chainflow is to open the door for others to experience this freedom. That effort starts with the Chainflow organization: my intention is to manifest an organizational structure that allows those who work with Chainflow to experience this freedom.

We'll expand this further by building infrastructure that underpins an alternative to the current economy, and the power structure it enables. Our hope is that this alternative is more fair, equitable, and inclusive than the closed, inequitable, and exclusive power structure that has a stranglehold on the economy today.

We'll also do this by continuing to advocate for true decentralization in staking networks. Because, if all we're doing is rebuilding today's inequitable economy and power structure on new technology, well, then what's the point?

Sincerely,

Chris

Founder, Chainflow

P.S. - Would you like to join us? Drop us a line at hiring@chainflow.io, especially if you have devops or social media management and community building experience.

Here's why.

The working group's stated goal is to -

...represent all eth2 stakeholders. This includes (but is not limited to)  solo stakers, decentralized staking pools, staking providers,  infrastructure providers, exchanges, custodians, and others.

This is fantastic goal and sounds like a well-balanced group of validator operator types. Yet reviewing the original list of members (found here), there's some work required to achieve this vision.

The need for balance

The list of current members is a who's-who of the largest validator operating companies and large validator infrastructure providers. Most of the members already control large, centralizing stakes in the networks they validate on.

Infrastructure providers serve as a particularly strong centralization vector. For example, when Blockdaemon announced their participation, they highlight running "over 12,000 active Eth2 validators". They go on to call themselves "one of the world's largest Eth2 operators".

Well, that's wonderful if you're a big profit-driven company that needs big returns to satisfy big investors. Yet that's not so great for an Ethereum project, as decentralization is one of the Ethereum community's core values.

Bison Trails, in their Q&A, encourages companies and entities to apply to become members. They then suggest "small-scale or enthusiast validators" to "join the ETHStaker community to receive the benefits of Working Group membership."

This feels more than a little elitist and paternalistic to me.

Not to mention it conflicts with the working group's stated goal. And this comes from a participant who helped recruit the original members, which was done in a behind-the-scenes process.

Why are we doing this (and why doesn't Chainflow apply to join)?

It's for these reasons more representation from smaller, independent and self-funded validator operators is urgently needed. This participation is required so that the big interests don't, knowingly or unknowingly, cause Flashbots for Eth2 to be designed in way that compounds staking's rich get richer problem.

This problem already disproportionately benefits these large companies. Allowing them to benefit disproportionately from MEV extraction as well goes against the core mission of Flashbots, at least as I understand it.

Originally, I expressed interest in joining the group. However, Chainflow doesn't currently operate Eth2 validators. While we've been following the work as long as anyone (4+ years), we've been waiting for a way to meaningfully contribute to Eth2 staking, without adding to the centralization problem.

Operating validators for Rocket Pool is one activity we've considered. Another would be participation in this working group. If we did participate, we'd bring Eth2 validator infrastructure online to both testnets and mainnet.

Before doing this, I thought it made more sense to sponsor existing Eth2 validators to participate. Having bootstrapped and self-funded Chainflow from the outset and taken no outstide investment, I'm well-aware that smaller operators are strapped for time and resources.

(This is also why the large validator operators in infrastructure providers disproportionately dominate these discussions.)

The idea is that Chainflow will subsidize the time and attention smaller operators will spend participating in the Flashbots Eth2 working group. The details will depend on a specific operator's situation.

We're happy to be flexible in what the subsidy and sponsorship looks like. I'd be available to participate in the working group alongside you as well, if that would be of benefit. To clarify, my participation would be optional, not a mandatory condition of the sponsorship.

So if you're a smaller, independent and self-funded Eth2 validator operator, who cares deeply about decentralization (really) and wants to advocate for others like you, please get in touch.

We hope to hear from you!

#KeepStakeDecentralized 💪

Joining the Proof-of-Stake Community

I entered the broader crypto community through Ethereum. I was the project manager at ENS for three years, led the Aragon product team to their mainnet launch and helped other projects here and there too.

Proof of stake caught my attention in mid-2016. Joining the Cosmos validator working group in October 2017 was my “official” entry point into the staking economy.

This led to me founding Chainflow. Through Chainflow I’ve been fortunate to advise and support many staking networks.

Through Ethereum, I was fortunate to work with people like Nick Johnson, Alex Van de Sande, as well as many of the team members that left Aragon One earlier this year. Working on Ethereum projects also provided me with a broader network within the Ethereum community. I was able to attend and experience a couple Devcons too, to experience the community in real life.

Earlier this year I spoke to Abbey Titcomb of Radicle, a project built on Ethereum. Radicle is a project I’ve liked since learning about it a few years ago.

Speaking with Abbey reminded me how much I enjoyed interacting with the Ethereum community. I realized the experience was different from most of the day-to-day interactions I had working in the staking economy.

Values as Competitive Advantage

Ethereum supporters often see their community as a competitive advantage. I started taking this perspective more seriously after that conversation with Abbey.

Then I started asking myself why this conversation felt different than those I was having daily. This line of inquiry reminded me of attending NYC blockchain week 2019. Proof-of-stake was a popular topic that week, as Cosmos launched a couple months before it.

Many, if not most, of the people I met at the staking events were from the legacy financial industry. The suits and business casuals seemed to outnumber the jeans and t-shirts.

This wasn’t surprising, as the conference was happening in the belly of the legacy financial industry beast. The events also had an invite-only, exclusive feel to them.

What’s missing is an appreciation of values other than those in service of financial gain. And what loses out is decentralization, the value that underpins the goals that drive the crypto-first builders.

I began contrasting this experience with my Ethereum tenure. Doing so helped me realize that the majority of people within the Ethereum community entered it from a set of crypto-first values. These values understood and still understand the importance of decentralization.

In contrast, many that I met during blockchain week were entering the staking economy from a finance-first perspective. They saw the staking economy as another market to conquer, control, and extract an inequitable share of value from.

Two years later, these contrasting experiences help me understand where the staking economy is today. Stake is centralizing and many would rather not call attention to the problem.

Maximize Profitability

Validators are looking to maximize profitability by capturing as much stake, early, as possible. They know that early leads compound and are very difficult to surpass. They employ the usual venture-funded, customer acquisition and high-growth strategies revered in the startup world and often required by venture capitalists.

Delegators often choose validators based on greatest total stake and lowest fees. They’re looking to maximize their returns. They want to “set-it-and-forget-it” to earn passive income.

What’s missing is an appreciation of values other than those in service of financial gain. And what loses out is decentralization, the value that underpins the goals that drive the crypto-first builders.

The staking economy needs a more balanced view and appreciation of a well-rounded value set. This is essential in order for it to thrive and continue competing (or more hopefully, complementing) networks with strong crypto-first values like Ethereum.

That’s not to say Ethereum is immune from the centralization problems that early staking networks are experiencing. This chart shows that 33% of network stake is controlled by about only 7 entities.

Otherwise, the staking economy will continued trending toward centralization. This won’t result in an alternative to the current inequitable and unfair legacy financial system.

It will simply build a replica of it, but I’m guessing that’s OK, with many of the 2019 blockchain NYC attendees. This scenario makes it easy to maintain control and maximize profits.

Is Stake Doomed to Centralize?

Yet those of us who believe in the staking economy and are in this to build a fairer, more equitable and inclusive alternative to the legacy economy, can’t stand by and let this happen. We need to speak up and give voice to the importance of values other than the financial ones driving the staking economy today.

My earlier posts about the rich getting richer and a doomsday scenario may leave you thinking I believe centralization is inevitable. This isn’t the case. There are actions that can be taken to slow and even reverse stake centralization.

The first step toward changing anything is to bring awareness to what needs to be changed. The first thing we can do in service of this goal is to call attention to the centralization trends as they’re happening or when we believe certain decisions may strengthen the trends toward centralization. Make your crypto-first values known to the staking network communities you participate in.

Silicon Valley Model

This is what I’ve been trying to do since even before the Cosmos launch. It’s what I hope these posts and the Staking Defense podcast accomplish. Yet we need more voices to amplify these messages, lend them credibility and increase their urgency.

So when you see a trend toward centralization happening, speak up, call it out, bring attention to it. When you see others do the same, investigate the points and if you agree, support the observation. This goes for decisions, e.g. network proposals, that may increase, rather than decrease the trend toward centralization, too.

Secondly, we need to further educate delegators, particularly new entrants to the crypto community. We need to explain the importance of decentralization to them and help them understand how their choices play an important role in preventing stake centralization.

Delegators do at least a little research. Get to know your chosen validator operator. Or better yet, choose two to three to delegate to. This helps reduce your risk and decentralizes stake. Choose validators whose values align with your own. Hold them accountable for their actions and contributions, or lack thereof, to the communities of the networks they’re operating on. Understand their business model.

Are they pursuing a high-growth, Silicon Valley model that relies on them capturing as much market share as possible? These types of business models are directly at odds with the concept of decentralization in the first place. Instead, choose validators who don’t see the staking economy as a zero-sum game.

Finally, from a more tactical perspective, those building networks block explorers can help too. They can do this by highlighting validator performance, rather than total stake. The single biggest and probably the simplest thing you can do to counter stake centralization is default sort your validator list by performance or even alphabetically. DON’T default sort by stake, with the highest stake at the top of the list. Provide background information on the valiator and an area for delegators to review validators.

The Time Is Now

As I wrote above, I’ve experienced a heavier presence of crypto-first values in the Ethereum community than in most of the early staking networks. However, I know there are people in these communities who also hold strongly to these values.

These crypto-first voices need to become louder in these communities. And for Ethereum, it’s important that these values continue to remain front-and-center as the progression to Eth2 continues, in order to prevent centralization trends from taking root.

The time is now to take these actions. The longer a network runs with these centralization tendencies unchecked, the longer it will take for them to be reversed. And left unchecked for too long, they may become irreversible.

#KeepStakeDecentralized 💪

You can read the original version of this post, and more, on The Defiant.

This 24 hour window felt short. I'd suggest a period of 48-72 hours between publishing phase instructions and the phase's start. This would give enough time to ask and answer questions about the instructions, before the phase starts.

24 hours felt like just enough time to get our validator configured to try and meet the deadline. We were left with some unanswered questions. The 24 hour window didn't leave enough time to both come online and get questions answered.

It took a few attempts to launch the network. Part of me believes this might have been at least partially caused by the rushed nature of the start. That said, the validator set's response was exciting and encouraging to see.

Many believe that slashing for downtime is necessary to ensure an operational staking network. My experience over the past three years tells me this isn't necessarily true.

Validators, at least to-date, are generally a very dedicated group. We place great value on protecting our reputation. Limiting downtime is critical to protecting our reputation.

In addition to this, watching the validator group's determination to bring the network online further emphasizes this point to me. Next time you think slashing for downtime is required, drop into a validator channel during a launch. What you observe has a good chance of changing your mind.

P.S. Want to stake with Chainflow when Agoric's mainnet goes live? Contact us and let us know!

As a lead validator since the first testnet, I'm writing this to share the current plans as communicated to me by the team. The lead validators also contributed to this initial plan.

Note that the information in this post reflects the team's current thinking. We're happy to engage in constructive discussion and modify the strategy after launch.

Why 50?

The main reason the network will launch is 50 validators is sustainability. True to Regen's mission of fostering sustainable ecosystems, the team wants the initial validator set to be self-sustaining.

50 felt like a number that's sufficient to encourage decentralization, while also small enough to give the initial 50 validators a reasonable chance to cover their operational costs.

How are the initial 50 selected?

The initial 50 validators will be the 50 validators holding the largest delegations. These delegations are a combination of self-delegation and third-party delegation.

The intention is that long-term Regen supporters have acquired enough tokens to place in the top 50 at launch. However, the team recognizes that it's possible some supporters may get squeezed out by larger holders.

That's why foundation delegations will happen soon after launch. The foundation plans to publish their delegation guiding principles too.

These principles will focus on both objective criteria, such as validator performance, as well as subjective criteria, like values alignment.

These delegations will help level the playing field, regardless of validator operational and financial size. It's likely to take a few days for the initial 50 to settle and stabilize.

So if you're a long time supporter and not in the initial 50 at launch, don't despair. Chances are you'll find yourself in the active set when the launch dust settles. There will also be an appeal process if you believe you should qualify for a delegation yet don't receive one out of the gate.

How and when will the set grow?

A governance proposal will determine when the set will grow and to what number. Remember, because this is a decentralized network, anyone can submit this proposal.

It's not necessary to wait until the core team does it. It's preferable for the proposal to come from the community.

Consistent with the thinking behind selecting 50 as the initial number, validator sustainability will be key to determining whether the proposal passes. Validator sustainability is related to the amount of fees moving through the network. The amount of fees is tied directly to network utility.

So as network adoption and utility increases, fee volume increases too. Higher fee volumes can support a larger validator set. A proposal to increase the validator set should then be more likely to pass as the network's utility grows.

It's everyone's responsibility.

It can't be emphasized enough that it's the entire community's responsibility to make sure that the right validator set supports the network. Delegators make this happen by carefully choosing the validator or validators they delegate to. And remember, delegators also have the power to vote, independent of their selected validator.

Prospective validators play a role too. If you're not in the initial set, stay active.

Operate a full node, while keeping an eye on network utility and validator earnings. Don't be afraid to champion a proposal to increase the validator set size if the time looks right to you.

Let's work together to build a decentralized, effective, inclusive and supportive validator set, that's synchronized with the needs of the network and the utility it supports. This is our responsibility and together we can make it happen.

Here is a summary of the answers on  Agoric's Incentivized testnet AMA that took place at 1600 UTC, Thursday, March 25 in Chainflow's Telegram group.

1) So I guess we can start with a very brief intro of Agoric...

Agoric is an open-source development company launching a proof-of-stake chain in the Cosmos ecosystem. We're building a smart contract platform in (secure) JavaScript that is oriented towards security and composability... the goal is to be accessible to more developers and to let them build high quality applications quickly.

2) Could you touch on ‘secure’ JavaScript?

JS through a historical accident, is actually well-suited to separating authority from pure computation. That fits well with the object-capability (ocap) model we advocate. Members of the Agoric team have been on the ECMAScript standards committee getting in the features needed for strong isolation of JS programs.

3) Why did you choose to develop on Cosmos as opposed to other proof of stake chains.

A good question. Our platform and VM is essentially consensus-agnostic so we could've built on e.g., Substrate. The decision was made before my time here, but I believe there was a lot of alignment between our founders' vision and what the Cosmos team was doing with IBC

Also, Agoric was one of the core teams developing IBC!

4) How long (estimation) does this testnet will take?

We're expecting it to run to roughly the end of June

5 ) Substrate goes beyond polkadot ecosystem?

We were considering joining polkadot, but the permissionless nature of IBC was a better fit.

6) For how long Agoric team has been building the platform? Do you have any particular use case?

This is a difficult question to answer as some of the work leading up to the Agoric's platform builds on decades of work from many of our team members. The use case really is oriented on making smart contracting accessible to the millions of Javascript programmers, with what we believe is a better / more scalable model vs. e.g., Ethereum.

https://agoric.com/papers/#aos is the initial research by some of our team dating to 1988.

So it's been a long time in the making. The advent of blockchain made a lot of these ideas suddenly much more achievable.

Here's a great history insight too https://www.youtube.com/watch?v=j5SuqIrgRJU

7) What are the main motivations behind running the testnet and the ideal outcomes from it? Please describe the testnet structure and the thinking that went behind structuring it in five phases.

For main motivations - we really have two:

1. Start building the Agoric validating community. The testnet is a great way to see how the community can coordinate and come together on goals.
2. Test our chain! We want to validate our infrastructure and see where we might have bottlenecks. How do we operate in a production-like environment where we aren't in control of the validators.

The five phases (starting with onboarding and ending with the adversarial phase) were designed to ramp up gradually and to allow our team to integrate the things we learned in each phase.

The phases are about 1-week-on, then 2-weeks-off. So the commitment from the participants is spread out over time.

8) Nice, so about how long will all 5 phases take to complete?

We're expecting it to run to roughly the end of June.

9) What phase are we in now? I thought I might have read that it’s too late for new validators to join?

We just started our onboarding phase. Validators signed up over the last couple weeks.

10) Why was the participant set capped at 150 validators?

Is it possible for validators not in the original 150 to participate in later phases?

If so, how would that happen, under what circumstances.

If a validator is not in the original 150, what's the best way to increase their chances of participating in later phases?

Some people have completed KYC/AML but are still getting verified on our end (there is a manual step). But if you haven't been notified that you were accepted and done KYC/AML at this point then yes it's too late unfortunately.

We had 6,000+ applications for 150 spots (and as far as we could tell it wasn't mostly bots.

In addition to the 150 participants we took ~50 for the waitlist which we might use if current participants drop out for one reason or another.

The 150 limit is because the Tendermint Proof of Stake works well at that limit, and we want to give personal attention to all the participants.

11) If a validator is not in the original 150, what's the best way to increase their chances of participating in later phases?

The short answer is there isn't much you can specifically do at this point. We asked for a lot information in the applications they've already supplied and that's what we'll use if we need to

-Sounds good, so you'll reach out if slots open, is that right?

-definitely.

12) Talking about this. I read on discord that the waitlist validators are not going to access the testnet phase. Is that correct? In the event that a validator drops out in phase3 for example, how will the onboarding of a waitlist validator be processed?

A waitlist validator coming in late would need to set up their node later on and catch up, yeah. It's not really required that they go through the previous phases.

13) Do validators have the full week to complete the tasks of a particular phase?

Are rewards determined by how quickly a validator completes the tasks?

Validators have the full week (and even longer for onboarding), and the speed of completion is not a factor in rewards, since we want to be cognizant of people with limited work hours or different timezones.

There may be tasks in later phases that require some level of time coordination, but we're trying to avoid anything feeling like a race.

14) Will there be slashing in future phases to weed out weaker validations?

We'll be testing slashing dynamics in a later phase. If there are validators that aren't active then we likely would add in people from the waitlist at that point.

15) How will points earned in the testnet translate into the ability to operate on mainnet? Assuming a validator completes all tasks required of them, will the number of tokens earned be enough to operate in mainnet upon launch? Will testnet results be considered, assuming there will be foundation delegations shortly after launch?

The tl;dr to the above is "Will testnet participants most likely be able to participate on mainnet with their earnings? What protection would there be from getting squeezed out by whales that emerge from the depths, i.e. large funds, exchanges, etc."

Yes, participation on the mainnet will be permissionless. As of right now we think earnings from the testnet should cover any minimum self-stake we'd require to validate on mainnet.

But yes, the top 100 based on self-stake and delegations end up in the active set.

Some of our challenges in the testnet are geared towards making validating more accessible, and we also are looking at mechanics that might help even the playing field vs. e.g,. exchange validators.

16) What percentage of token supply is reserved for incentivized testnet?

Roughly 0.1% of the token supply. A billion tokens and 1m+ were reserved for incentivized testnet.

17) Total supply?

Billion: 1,000,000,000

18) What’s the timelines for mainnet?

This summer!

For information: validate.agoric.com

For live communication: agoric.com/discord  (testnet Announcements channel)

P.S. Want to stake with Chainflow when Agoric's mainnet goes live? Contact us and let us know!