At Firstset, we’ve been operating a fleet of Fogo validators and backup nodes as part of the multilocal consensus architecture, and we built something we believe will make life easier for everyone running on Fogo.

We’re open-sourcing the Fogo Community Ansible Collection: a fully-featured set of automation playbooks to deploy, configure, and maintain Fogo validator nodes with production-grade security and consistency.

You can also find it on Ansible Galaxy here: firstset.fogo_community

Why We Built It

Running a Fogo validator isn’t just about spinning up a single server — the network’s multilocal consensus model requires many nodes working in sync, across geographies.
Manually configuring and updating each one quickly becomes error-prone and time-consuming.

We wanted to make it easier for validators — whether independent operators or institutional participants — to deploy nodes with best-practice configurations, secure defaults, and repeatable automation.

The collection we’re releasing is the same exact framework we’ve been using internally to manage our validator fleet. With this release, we’re opening it up to the broader community so that anyone can benefit from our experience and contribute back improvements.

What It Does

The collection provides two main roles:

1. Node Bootstrapping. Everything you need to securely prepare a fresh machine .

2. Validator Service Deployment. A fully automated and optimized Firedancer-based validator setup.

3. Validator Service Updates / Upgrades. A centralized and automated process for performing binary upgrades and configuration updates.

Together, these make it possible to go from bare metal to a running, monitored validator with a single playbook.

Why It Matters

Fogo’s validator topology is geographically redundant by design. As the network expands to more geographies, each operator will need to manage multiple nodes efficiently.

By adopting this Ansible collection, operators gain:

• Consistency across nodes and environments

• Security with hardened defaults and controlled access

• Automation for repeatable deployments and safe upgrades

• Transparency through open-source code that the community can audit and improve

This is an important step toward building a more resilient, decentralized validator ecosystem as Fogo moves into mainnet.

Get Started

Install from Ansible Galaxy:

ansible-galaxy collection install firstset.fogo_community

Then try the sample playbooks in the GitHub repository to bootstrap or deploy your first validator node.

All documentation, variables, and configuration examples are included in the repo and Galaxy listing.

Contribute and Collaborate

This is an open-source project under the MIT license.
We welcome feedback, issues, and pull requests from the validator community.

Special thanks to ASXN for contributing the first external improvements — we look forward to more community involvement as Fogo’s ecosystem grows.

👉 Contribute on GitHub

• configure the validator as a systemd service

• create a cronjob that collects the validator service’s logs every week as we are required to submit them to the foundation

Validator Systemd Service

The last step mentioned in the documentation is Running the node, where we use the following command to start the validator service:

./bin/genlayernode run -c $(pwd)/configs/node/config.yaml --password "your secret password"

As a systemd service config is visible to all the users, we recommend saving this value into a .env file so that the permission can be restricted to the service user later on.

# create a .env file that holds the password and HEURISTKEY value required by Heurist mode
echo "GENLAYERNODE_PASS=<the_password>" >> ~/.env
echo "HEURISTKEY=<your_llm_provider_api_key>" >> ~/.env

# restrict the access of this file
chmod 600 ~/.env

Then we create a systemd service for the validator. Note that this should be done by a sudo user. In our setup, we have created a dedicated user genlayer to run the genlayernode service. You need to change the name in the service definition accordingly if this is not your case.

sudo vim /etc/systemd/system/genlayer-validator.service

[Unit]
Description=Genlayer Validator Node
After=network-online.target

[Service]
User=genlayer
WorkingDirectory=/home/genlayer/genlayer-node-linux-amd64
ExecStart=/bin/bash -c '/home/genlayer/genlayer-node-linux-amd64/bin/genlayernode run -c /home/genlayer/genlayer-node-linux-amd64/configs/node/config.yaml --password "$GENLAYERNODE_PASS"'
Restart=always
RestartSec=3
EnvironmentFile=/home/genlayer/.env

[Install]
WantedBy=multi-user.target

# reload the daemon and start the service
sudo systemctl daemon-reload
sudo systemctl enable --now genlayer-validator.service

Cronjob for Log Collection

As now the validator service is running as a systemd service, you can use journalctl to check the logs. For examples:

# show the latest 100 lines of logs and tail the new logs
sudo journalctl -n 100 -f -u genlayer-validator.service
# show today's logs
sudo journalctl --since="today" -u genlayer-validator.service
# show the logs from 2025-04-30 00:00:00 to 2025-05-06 23:59:59
sudo journalctl --since="2025-04-30" --until="2025-05-06" --no-pager -u genlayer-validator.service

As mentioned in the Google doc: “For the first few weeks please keep a copy of the stdout logs and send them once a week to the GenLayer Foundation until we have better tools for metrics and monitoring”. We can create a cronjob that exports the logs as a tar file so that we can easily scp and submit it.

Create a bash file with the following content, for example, vim ~/export-validator-logs.sh.

#!/bin/bash

# Configuration
SERVICE_NAME="genlayer-validator.service"
BASE_DIR="/tmp"
OWNER_AND_GROUP="root:root"

# Calculate date range (excluding today)
# xxx_ISO format is used for journalctl commands while the other pair is used for folder and tar file names
END_DAY_ISO=$(date -d "yesterday" +%Y-%m-%d)
START_DAY_ISO=$(date -d "$END_DAY_ISO - 6 days" +%Y-%m-%d)
END_DAY=$(date -d "yesterday" +%Y%m%d)
START_DAY=$(date -d "$END_DAY_ISO - 6 days" +%Y%m%d)

# Temporary directory for logs
TEMP_DIR="$BASE_DIR/validator-logs-$START_DAY-$END_DAY"

# Check if the temporary directory exists, and remove it if it does
if [ -d "$TEMP_DIR" ]; then
  echo "Removing existing temporary directory: $TEMP_DIR"
  rm -rf "$TEMP_DIR"
fi

# Create the temporary directory
mkdir -p "$TEMP_DIR"

# Extract the logs for each day (excluding today)
for ((i=0; i<=6; i++)); do
    LOG_DATE_ISO=$(date -d "$START_DAY_ISO + $i days" +%Y-%m-%d)
    journalctl -u "$SERVICE_NAME" --since "$LOG_DATE_ISO 00:00:00" --until "$LOG_DATE_ISO 23:59:59" > "$TEMP_DIR/$(date -d "$START_DAY + $i days" +%Y%m%d).log"
    if [ $? -ne 0 ]; then
        echo "Failed to extract logs for $LOG_DATE"
        exit 1
    fi
done

# Create a compressed tar file
TAR_FILE="$BASE_DIR/validator-logs-$START_DAY-$END_DAY.tar.gz"
tar -czf "$TAR_FILE" -C "$BASE_DIR" "validator-logs-$START_DAY-$END_DAY"

# Cleanup
if [ $? -eq 0 ]; then
    echo "Logs archived successfully: $TAR_FILE"
    chown -R $OWNER_AND_GROUP $TEMP_DIR
    chown $OWNER_AND_GROUP $TAR_FILE
    echo "Changing the generated files ownership to $OWNER_AND_GROUP"
else
    echo "Failed to create tar file"
    exit 1
fi

Change the mod of this script and then add it to the root user’s cronjob list (because journalctl requires sudo access).

chmod +x ~/export-validator-logs.sh
sudo cronjob -e

# execute the script at 01:00 on Friday, adjust the time if you need
0 1 * * 5 /absolute/path/to/export-validator-logs.sh

You can also run the script directly to generate the log collection tar file when you need:

sudo ./export-validator-logs.sh
# output:
Logs archived successfully: /home/genlayer/validator-logs-20250507-20250513.tar.gz
Changing the generated files ownership to genlayer:genlayer

ls validator*
# output:
validator-logs-20250507-20250513.tar.gz

validator-logs-20250507-20250513:
20250507.log  20250508.log  20250509.log  20250510.log  20250511.log  20250512.log  20250513.log

We are big fans of Tenderduty but have noticed opportunities of improvement, which we started working on earlier this year. When we were about to merge our improvements upstream, we realized the original repository was archived. As we heavily rely on it (among additional lines of defense to proactively detect performance issues - redundancy is key!), we have decided to pick up the baton and start maintaining our own version of the project.

For now, we have added two new features:

1. Governance monitoring.

2. Enhanced Namada support.

Governance monitoring

Validator governance participation is paramount to the well functioning of a blockchain. Sadly, the current state of affairs in most blockchain's governance is to communicate proposals and open votes through Discord channels and Forums, without any reliable process to systematically ensure validators don't miss votes. This is stressful for validators who want to deliver on their duties because they have to constantly sift through many channels across several Discords to ensure no proposal falls through the cracks.

We decided to take action by adding the following features to Tenderduty:

1. Unvoted proposal alerts. Receive notifications via those channels set up for "warning" level alerts.

2. Unvoted proposal dashboard reporting. View the number of unvoted open proposals per chain in your Tenderduty dashboard.

3. Unvoted proposal Prometheus metric. Scrape the number of unvoted open proposals per chain via Prometheus.

This is an example of a governance alert which got resolved after we promptly voted:

Enhanced Namada support

If you're a Tenderduty user who is validating on Namada, you'll have noticed certain information is missing in the Tenderduty dashboard. Whether the moniker, uptime data or slashing threshold. We couldn't find this information through the usual ABCI querying method, so instead this feature relies on Namada indexers, which can be configured in your config.yml.

This is how it looks for us now:

Wrapping up

The repository can be found at https://github.com/Firstset/tenderduty. If you want to contribute to it, we'd rather you open an issue first, but PRs are also welcome.

And if you have any feedback or feature requests, let us know.

Key insights covered in this report:

• $15B+ in annual rewards (2024). Staking is already a massive yield source.

• $200B+ in assets staked (Q1 2025). With ETH and SOL leading the charge.

• ETH and SOL now generate ~50% of total staking rewards. Up from ~30% just a few years ago.

• Validator economics = volume x pricing power x retention. And not all sources of stake are created equal.

• CEXs are best positioned. Massive retail reach, low price sensitivity, and the ability to monetize passive holders.

• Coinbase made $705M from staking in 2024, up 113% YoY. And charges up to a 35% commission.

• Success isn’t about infra alone. It’s a game of attracting and retaining stake from the right sources: institutions, foundations, CEX users, and liquid staking protocols.

• Governance power is consolidating. Top validators now influence major network decisions (see: SIMD-228).

• Staking will power more than L1s. Expect adoption across L2s and DeFi protocols, blending yield and governance.

The report is structured across:

• Staking 101. A quick primer on staking, how it works, and why it's central to PoS blockchain security and yields.

• Historical context. The evolution of staking across three phases: Past (emergence), Present (maturity), and Future (yield, governance, and value capture).

• Succeeding as a staking business. A look at the core levers that determine validator performance: volume, pricing power, and stake retention.

• Competitive landscape. A taxonomy of staking players (CEXs, custodians, professionals, community validators), highlighting their differences in positioning.

• Business case: Coinbase. A deep dive into Coinbase’s staking revenues, user strategy, governance moves, and validator operations.

• Generalizing the playbook. A summary of the key steps for institutions or fintechs entering the staking market, based on observed patterns.

A blockchain reaches agreement using a consensus mechanism. Proof of Stake (PoS), today's dominant consensus model, lets users pledge collateral (stake) to validators who propose and vote on blocks. These blockchains gain security from staking, as greater stake raises the cost of network attacks. Stakers receive rewards—a mix of inflation and fees—in return.

Staking unlocks yield for major crypto assets, effectively risk-free. It suits long-term holders seeking extra gains with minimal risk.

Running a validator and attracting stake lets one share in the network's success as its Real Economic Value (REV = MEV + fees) grows.

The staking industry took off with the transition of Ethereum to PoS, and its consolidation as a major blockchain. Since then, it has been growing and maturing with the proliferation of new chains, most notably Solana.

In our view, there’s three distinct periods that characterize the staking industry:

• Past: from the inception of PoS in the mid 2010s until 2023.

• Present: from 2024 until today (2025).

• Future: a gradual transition from today onwards.

PoS chains started seeing traction and value appreciation during the 2020-21 hype cycle, thereby giving rise to the staking industry.

By 2023, Staking had shown it was here to stay:

1. One major PoS asset: ETH.

2. Next-gen PoS entrants start emerging: SOL, BNB, SUI.

3. Annual rewards cross $1bn in 2020, peaking beyond $15b during the 2021 bubble.

Today, most of the major assets can be staked. This includes even Bitcoin, which can be staked via Babylon. The total value staked from the top 20 staked assets in 2024 already surpassed $200bn:

This translates to nearly $15bn in annual rewards, not too far from the 2021 cycle peak. Approximately, $1.5-3bn of that went to staking providers.

The distribution and composition of top staked assets between 2021 and 2024 also changed significantly:

1. ETH + SOL have gone from 30% to 50% of the total rewards.

2. Next-gen chains have replaced many of the top 20 assets by $ rewards volume.

We expect all new chains to be PoS based, with non-PoS chains supporting staking in one way or another, as we have seen with Bitcoin and Babylon.

As more economic value shifts onchain, real rewards will increase, in the native denomination but even more so in $ terms as the underlying fundamentals improve. Solana’s rise during 2024 and Q1 2025 gives us a glimpse of this phenomenon, with REV fueled staking revenue driving an expansion of yield:

We also expect staking to become a more prevalent mechanism in crypto to incentivize governance and reward long term token holding not only with L1s, but also with L2s and protocols (e.g. Starknet , Aave respectively).

Finally, accruing governance power will become increasingly important (i.e. see the recent SIMD-228 vote controversy), akin to holding a vote for the new Internet, and strategic to many players in the crypto ecosystem.

Staking is a winner-takes-some competition, enabling a rich ecosystem of thriving staking operations. Running a validator is a necessary but insufficient condition to build a successful staking operation. Most importantly, one must be able to attract stake, which may come from various sources:

• Foundations. Each Blockchain has a foundation which delegates tokens to incentivize and reward validators operated by teams that contribute to the network.

• Institutions. Large holders of tokens, directly or through custodians.

• Retail (CEX). Individuals who interface with crypto in a limited fashion through centralized exchanges.

• Retail (onchain). Individuals who hold assets in their own wallet and interact with blockchains to perform actions.

• LSTs. Liquid staking tokens, which represent liquid staked positions underpinned by a limited set of validators.

To understand the quality of each source of stake, it’s important to realize that staking is a volume, pricing power & retention game:

1. Volume. Validator revenue margins typically range between 4% and 0.5% of AUM p.a. Opex is usually constant regardless of stake size. So it’s all about stake volume.

2. Pricing power. Some sources of stake tolerate higher commissions than others. Mostly a matter of competition and switching costs.

3. Retention. Stickiness matters. It is a function of time horizons, risk appetite, savviness, among other things.

The relationship between each source of stake and their key dimensions can be summarized as:

The staking market is composed of a few different categories of players. The table below shows our perspective on the main archetypes along their likely sources of stake:

We conclude that the biggest opportunity in the current adoption cycle is for CEX entities (or Fintechs with a retail crypto custody component) to enter the staking market.

In their Q4 ‘24 letter, Coinbase reported $705m in staking revenues during 2024, up from $331m in 2023, $275m in 2022 and $223m in 2021.

As of 13th March, we estimate that Coinbase has:

1. 3.8M ETH ($7.5B) staked, generating $230M in annual staking yield.

2. 14.3M SOL ($1.8B) staked, generating $180M in annual staking yield.

In terms of their historical performance, and that of their CEX peers, their generated staking rewards have largely been growing consistently. For instance, this is for ETH + SOL:

If we aggregate the data above with a 12 month rolling window to project their generated annual rewards over time, we generally see a constant uptrend:

The chart below shows their ETH rewards month-over-month in USD terms, which have been dampened in the recent months by poor price action:

And their corresponding SOL rewards:

Coinbase’s standard commission on staking rewards is 35%. For comparison, most foundations require commissions below 10%, and in some cases 5%.

Coinbase can afford setting higher commissions due to its unsophisticated retail user base with high switching costs. Their take-rate on sophisticated users / institutions is lower, ranging from 25% to 10%.

Staking is not only complementary to the core business, but also higher LTV than trading fees for casual spot users with low trade frequency and long time holding horizons.

Additionally, Coinbase creates “hodlers” via their Learn To Earn program as a customer acquisition strategy (CEX version of Galxe, Layer3) subsidized by protocols, who pay for the campaign (CEX fee + tokens). These new token holders can stake their tokens and potentially buy more once educated.

By accumulating the network’s native token, Coinbase has amassed considerable governance power, which they can exert to demonstrate alignment and potentially sway the network in their best interest. For instance, they were the 4th largest voter in Solana’s highly controversial SIMD-228, and have been leveraging their participation for marketing purposes or to protect their interests.

Kraken is another example of a CEX commanding a significant stake and using it in key governance votes.

Piecing together public information, we think this timeline roughly reflects Coinbase’s progress in the staking sector:

1. 2019: Launched staking

   1. First offered staking services on March 29, 2019 – initially through its institutional arm, Coinbase Custody. Later that year, shipped to all users.

   2. Internal team, one single asset (Tezos).

2. 2020: Partnered with Bison Trails

   1. Leverage a third party to offer Polkadot staking.

3. 2020: Adding more assets

   1. After introducing Tezos in 2019, announces support for Cosmos and Ethereum staking.

4. 2021: Acquired Bison Trails: $450m

   1. Acquired for the team and distribution as well as technical know-how.

5. 2021: Acquired Unit410

   1. Acquired Unit410, a staking infrastructure lab known for their cutting edge research and open source contributions.

   2. This allows them to support strategic chains, and similar to Governance work, can be leveraged as a marketing tool through their open source contributions.

6. 2022: Coinbase Developer Platform

   1. Created to be the AWS of crypto, offering a suite of services towards third party applications, including staking.

   2. Unlocks additional sources of stake outside of Coinbase. Example: Alluvial integration.

7. 2022: LST launch

   1. Coinbase announces their first LST, on Ethereum.

   2. 146k ETH, roughly 5% of their staked ETH (as of March 2025).

8. 2023: Partner with Kiln as third party provider

   1. Offer native ETH staking via Kiln on Coinbase Wallet.

   2. As of 2025, >10% of their ETH is staked with partners.

Prospective CEX’s and Fintechs may be questioning how applicable the Coinbase benchmark is to their business. A more abstract way to model and project staking revenues is simply as a function of AUM staked, commission (i.e. take-rate) and reward rate (i.e. yield APR)

The table below summarizes the relationship between the key factors, expressed in millions of dollars ($M):

In our view, this is the high level playbook that a new CEX or Fintech wanting to enter the staking business should be considering:

1. Launch limited staking offering

   1. Initially support one or very few asset(s), whichever most critical.

   2. Potentially partnering with a staking business that is already operational to accelerate roll out while de-risking launch.

2. Expand staking offering

   1. Improve internal support for key assets, eliminating third party dependencies to reduce counterparty risk and increase profit margins.

   2. Increase asset coverage, if needed through external partners.

3. Grow staker user-base

   1. Improve product offering to create new sources of stake, whether through “learn to earn” programs, dedicated LSTs, developer API / SDKs or own wallet.

   2. Build external presence, grow community goodwill and increase brand value via governance participation, potentially also ‘public good’ contributions (publishing analyses and research, open source development).

That said, the devil is in the details. There are many aspects that are a lot more particular to each business which we left out of this report’s scope, but are always open to discuss. Reach out to hi@firstset.xyz if you have any questions.

We are a crypto native staking firm focused on supporting the blockchains of tomorrow, primarily through validation services. We currently manage $20M in staked assets across several chains, most notably Ethereum, Solana and Babylon.

Sometimes we also publish research (e.g. SIMD-228 explainer and impact analysis, Lido CSM analysis) and contribute open source software (e.g. Lido CSM CLI, Tenderduty).

Solana’s economic model relies on proof-of-stake (PoS), where the SOL token is issued at a rate determined by a time-based schedule that decreases over time, distributing rewards to validators and delegators. Two new Solana Improvement Documents (SIMDs), SIMD-0228 (Market-Based Emission Mechanism) and SIMD-0123 (Block Revenue Sharing), propose significant changes to how SOL is issued, how fees are distributed, and how validators, stakers, and the broader ecosystem are incentivized. These proposals aim to fine-tune Solana’s tokenomics for long-term sustainability, balancing lower inflation with robust security and fairer reward distribution.

1. SIMD-0228 introduces a dynamic, stake-based inflation schedule to replace the current declining but fixed issuance. When more of the total SOL supply is staked, inflation goes down; when stake participation drops, inflation rises automatically to incentivize increased staking. This ensures Solana only inflates as needed to secure the network.

2. SIMD-0123 allows an in-protocol distribution of transaction fees (primarily priority fees) to delegators, not just validators. The protocol automatically divvies up block revenue between validators (as commission) and their delegators, replacing manual or third-party distribution mechanisms.

The combined goal is to reduce unnecessary inflation, reward active participation, and more fairly allocate network revenue. Below is a summarized analysis of each SIMD’s direct and second-order effects on SOL holders, stakers, validators, and DeFi usage, referencing relevant comparisons to Bitcoin, Ethereum, and existing Solana structures only where beneficial.

Under the current schedule, Solana’s inflation started high (~8%) and decays ~15% annually until hitting a floor of ~1.5%, regardless of network conditions. This was useful for bootstrapping the network, but over time Solana has grown a large, active set of validators and substantial off-chain revenue (like MEV tips). The network is potentially overpaying for security.

SIMD-0228 replaces the fixed time-based model with a formula that reduces or increases the issuance rate depending on the total percentage of SOL staked (s). If s is high (e.g., 65–70%), inflation drops near or below 1%. If s falls, the protocol boosts inflation to attract more stake. This approach aims to keep inflation at the “lowest necessary” level for adequate security, preventing excessive dilution for SOL holders.

• Lower Inflation: With Q1 2025 data showing staking yields trending between 7-12% the network might not need as much inflation to keep stakers incentivized. As more stake accumulates, inflation ratchets down automatically.

• Reduced Dilution: A lower inflation rate lets SOL holders maintain more of their purchasing power. Stakers face less pressure to sell rewards for taxes in high-inflation scenarios.

• Responsive Security Model: If many unstake, the system raises issuance to boost APY, nudging stakers back. This helps preserve network security without requiring ad-hoc governance changes.

• Potential Price Stability: Less inflation can diminish the perpetual selling pressure from stakers covering costs or taxes, potentially supporting SOL’s price.

• Stimulus for DeFi: When inflation is high, stakers earn easy yields, which can reduce SOL’s use in lending and other DeFi. Cutting inflation lowers the baseline “risk-free” rate, making DeFi yields more competitive.

• Market Perception: Adopting a dynamic, market-informed model might bolster investor confidence that Solana can adapt to actual security needs rather than sticking to a legacy schedule.

• Variable Rewards: Staking APR will fluctuate with network-wide participation. Higher stake → lower APR from inflation; lower stake → higher APR.

• Better Long-Term Accumulation: Even if nominal APYs dip, a low-inflation environment can mean better real returns for dedicated stakers, whose share of total supply grows more meaningfully.

• Second-Order Effect: If inflation shrinks significantly, some stakers may consider alternative DeFi strategies, but the protocol’s design can lift inflation if stake drops too low, balancing security.

• Lower Subsidies: Validators currently relying heavily on inflationary rewards see a drop in total issuance. The volume of SOL matters more here than fiat price, because validator expenses (e.g., voting fees) are also in SOL.

• Dependency on Fees & MEV: As inflation declines, validators lean more on priority fees, Jito MEV tips, and other revenue. Smaller validators or newcomers could struggle if overall block rewards shrink too far, potentially encouraging consolidation.

• Centralization Risk: Tighter margins might push less efficient validators out, benefitting larger or more professional operators who can handle overhead more cheaply.

• Balancing DeFi Usage: A moderate staking rate and stable low inflation could free up more SOL for lending, liquidity pools, etc.

• Potential Security Concerns: If macro conditions cause a severe drop in staking, inflation can jump. This might be jarring during market downturns, but it’s intended as an automated safety net.

• Validator Churn: Marginal validators might exit if net rewards in SOL become too slim, creating centralization worries unless more efficient or mission-driven validators fill the gap.

SIMD-0123 proposes protocol-level sharing of priority fee revenue among delegators. Currently, off-chain revenue arrangements exist where the fees are partially redistributed, but that process can be trust-based or limited. SIMD-0123 automates fee distribution for priority fees. A validator can set a commission rate on these block fees, and the remainder is paid pro rata to stakers.

• Aligns Delegators and Validators: Delegators no longer miss out on priority fees. This more fairly rewards everyone whose stake contributes to block production.

• Stronger Staking Incentive: With stakers now earning part of the fee revenue, the total staking yield increases, even if inflation is reduced under 0228.

• Transparency & Protocol Enforcement: Instead of relying on out-of-protocol solutions, fee sharing becomes trustless. Delegators can see on-chain what commission they’ll pay.

• Increased Staking Participation: As stakers also get fee rewards, more SOL could end up staked, potentially reducing liquid supply.

• No Additional Inflation: Block revenue is redistributive; it doesn’t inflate the token supply. The shift from burning to distributing fees might marginally boost supply retention, but if stakers hold rewards, effective circulation could still be restrained.

• DeFi Dynamics: If staking yields rise from fee sharing, some capital might move from DeFi back to staking unless DeFi protocols offer competitive yields. Liquid staking tokens (e.g., Jito SOL) help keep SOL liquid for usage.

• Boosted Returns: Combining inflation-based rewards plus a share of block fees grows total APY. Q1 2025 data indicates that LSTs yield around 7-8% with a portion of the MEV. Including priority fees might stabilize or modestly increase those yields, compensating for a lower inflation schedule.

• Minimal Overhead: It’s handled by the core protocol, so stakers don’t need to rely on validator-run scripts or external programs.

• Reduced Fee Retention: Validators no longer keep 100% of block fees. They’ll only retain their commission portion. This could intensify competition on commission rates if larger pools run at 0%, pushing overall commissions lower (“race to the bottom”).

• Potential Centralization Pressure: As inflation declines and fee revenue must be shared, smaller validators may face thinner margins. Some might consolidate or exit if they can’t remain profitable in SOL terms, leading to fewer, more capitalized validators.

• No Direct Change to Fee Accrual Mechanics: Validators still accrue fees only when they produce a block. Larger validators still produce more blocks overall. Thus volatility in fee-based revenue remains tied to how many slots a validator wins.

• Interaction with 0228’s Reduced Inflation: Lower inflation means less guaranteed SOL issuance for validators. With fee sharing, delegators also gain more, which might help maintain high stake participation. However, smaller validators could be squeezed if both inflation decreases and fees get divided.

• Further Decentralization or Concentration?: The outcome depends on whether the new fee-sharing model encourages delegators to spread stake or if big 0% commission pools like Jito overshadow smaller operators.

• Economic Efficiency: Over time, if the network’s fee volume grows, stakers can rely more on “real” usage-derived yields. This shift parallels other PoS chains that rely heavily on usage fees rather than large inflation subsidies.

Critics point out that:

1. Lower Inflation Squeezes Margins: High-quality infrastructure and node costs (denominated in SOL) remain, but rewards in SOL might shrink. If validators cannot keep up, they drop out, potentially boosting the stake of bigger or more efficient validators.

2. Race to 0% Commission: Validators in the Jito set have decreased their commission to 0% for competitiveness. Other validators might feel forced to lower commissions, reducing their revenue and possibly driving some out of business.

3. Big Operators Advantage: Larger validators with economies of scale can handle low commission better. This could gradually centralize stake unless delegators actively spread out.

Hence, while fee sharing and dynamic issuance improve overall network efficiency, they also raise the bar for validator viability, potentially concentrating stake with major pools or professional operators. This tension remains a core challenge, requiring active community governance to prevent excessive centralization.

SIMD-0228 and SIMD-0123 constitute a major update to Solana’s economic design. 0228 ensures issuance adapts to staking participation, reducing inflation when stake is high and boosting it if stake falls. 0123 implements an in-protocol framework so delegators also receive a share of priority fees, not just newly minted SOL.

For SOL itself, these proposals can:

• Lower Long-Term Inflation, improving its appeal for holders.

• Tie Staking Rewards More Closely to Usage, giving delegators upside from transaction fees.

• Potentially Pressure Validator Profitability, leading to either consolidation or more efficient operators.

While these measures make SOL’s economics more sustainable by linking rewards to real network conditions, they also risk intensifying centralization. A vibrant ecosystem with broad validator participation and diversified delegations is crucial for preserving security and decentralization. Close monitoring and potential parameter adjustments may be required to preserve a healthy validator ecosystem.

Overall, the changes reflect Solana’s continued effort to refine incentives, reduce dilution, and align rewards with actual network activity, aiming to secure the network more efficiently over the long run.

Support our work by staking with our Solana validator.

We are excited to introduce the Lido CSM Validator Manager, an open-source tool we've developed to streamline the deployment, monitoring, and management of Lido CSM validators at scale. At Firstset, we've successfully used it to run over 100 validators during the CSM testnet process, and we believe it can benefit other node operators facing similar challenges.

Deploy Validators

• Automated Key Generation and Deployment: Create and deploy new validator keys to both your validator client and the Lido CSM seamlessly.

• Node Operator Registration: Automatically register a new CSM Node Operator if needed.

• Duplicate Key Checks: Prevent issues by checking for duplicate validator keys across your validator client, remote signer, and the CSM.

• Remote Signer Support: Optionally upload keystores to a remote signer setup, such as Web3Signer.

Manage Validator Keys

• State Consistency Checks: Identify inconsistencies between keys registered in the validator client, remote signer, and the CSM.

• Inconsistency Resolution: Roll back inconsistent states to maintain a reliable validator setup.

Exit Validators

• Manual Exits: Exit validators individually using their public keys.

• Automated Exits: Monitor the Lido Validator Exit Bus Oracle and automatically action exit requests for your node operator IDs.

• Notifications: Receive Telegram notifications for detected exit requests to stay informed in real-time.

Additional Support

• Remote Signer Setups: Full support for remote signer configurations, enhancing security for your validator keys.

The Lido CSM Validator Manager relies on one external process and several APIs to function effectively:

• Staking Deposit CLI: Used for generating the keystores and deposit data required for validator creation.

• Lido Keys API: Checks if any of the generated keys have been previously uploaded to prevent duplication.

  Note: This is a critical step as uploading duplicate keys to the Lido CSM is possible, which could lead to submitting a bond for a validator that will never be activated.

• Validator Client Keymanager API: Allows remote loading of keystores into the validator client.

  Note: Since the Keymanager API is typically offered over plain HTTP, the Validator Manager securely wraps the connection over an SSH tunnel to enhance security.

• Ethereum JSON-RPC API: Interacts with the Lido CSM contracts for reading data and submitting transactions.

The interaction flow is as follows:

1. Key Generation: The Staking Deposit CLI generates the validator keys and deposit data.

2. Duplicate Key Check: The Lido Keys API is consulted to ensure that the generated keys have not been previously uploaded.

3. Keystore Upload: The keystores are securely uploaded to the validator client using the Keymanager API over an SSH tunnel.

4. CSM Registration: The Ethereum JSON-RPC API is used to interact with the Lido CSM contracts, registering the validator keys and, if necessary, the node operator.

This design ensures a streamlined and secure process for deploying and managing validators within the Lido CSM ecosystem.

Due to the distributed nature of validator operations and non-transactional behavior, inconsistencies may arise from failures or interruptions. The Lido CSM Validator Manager helps mitigate these issues by providing state checks to find discrepancies and the ability to resolve them in one command.

As a node operator, it's essential to ensure that:

• For each validator keystore loaded in your validator client or remote signer, there is a corresponding public key registered in the Lido CSM contracts.

• For each public key registered in the Lido CSM contracts, there is a corresponding keystore loaded in your validator client or remote signer.

If inconsistencies occur (e.g., the tool is interrupted during key deployment), use the state-check functionality to identify and resolve them.

To get started with the Lido CSM Validator Manager, visit the GitHub repository. The repository contains detailed instructions on setup, configuration, and usage.

Introduction

The CSM Testnet performance evaluation concluded on September 30, 2024, shortly followed by the publication of the CSM Mainnet Early Adoption (EA) list. One pathway to EA list inclusion was through participation as a node operator in the testnet, maintaining both good performance and sufficient participation time.

• Performance was measured as the percentage of successfully completed duties out of total assigned duties. Good performance was defined as exceeding 86.60%.

• Sufficient participation time was set at exceeding 6750 epochs, i.e. 28 days.

Performance data was published by Lido, alongside detailed CSM performance criteria.

This post offers a brief descriptive analysis of node operators' performance in CSM's Testnet based on the aforementioned performance data. You can find all the source charts referenced in this post in this dashboard.

A total of 2,649 node operators participated, registering 8,086 validators. This averages to about 3 validators per operator. However, as we'll demonstrate later, the distribution is highly skewed.

Let's first examine how many operators achieved both good performance and sufficient participation time.

Of the 2,649 node operators:
• 2,440 (92.11%) achieved both good performance and sufficient participation time
• 123 (4.64%) did not achieve sufficient participation time
• 86 (3.24%) did not achieve good enough performance

When we disaggregate the data by validator count, the proportions differ significantly.

Of the 8,086 validators:
• 4,056 (50.16%) achieved both good performance and sufficient participation time
• 3,237 (40.03%) did not achieve sufficient participation time
• 793 (9.80%) did not achieve good enough performance

This shift in distribution is primarily due to two outlier node operators who managed 3,000 validators but didn't participate long enough to achieve sufficient participation time.

The following figures illustrate the significant skew in the validator-per-node-operator distribution:

Now, let's examine the participation time data. Recall that the sufficient participation time was set at 6,750 epochs.

The figure shows that most node operators participated for 8,400 to 11,400 epochs, thus achieving sufficient participation time.

Finally, let's analyze the performance numbers. Remember, the performance threshold was set at 86.60% of successful duties out of all assigned duties.

In this figure, we observe a heavily skewed distribution towards 100% performance. Notably, there are 33 operators with zero participation.

Zooming into the 90–100% performance range, we see the distribution remains heavily skewed towards excellent performance—99% and above.

Further focusing on node operators with 99–100% performance, we find that most achieved between 99.9% and 99.98%. Remarkably, 16 node operators attained perfect 100% performance.

• 2,649 node operators participated in the CSM Testnet, managing 8,086 validators.

• 92.11% of node operators achieved both good performance (>86.60%) and sufficient participation time (>6,750 epochs).

• The distribution of validators per node operator was highly skewed, with two outliers managing a combined 3,000 validators.

• Most node operators participated for 4,410 to 5,985 epochs, exceeding the sufficient participation time threshold.

• Performance was heavily skewed towards excellence, with many operators achieving 99% and above.

• 16 node operators achieved perfect 100% performance.

• The high level of competence demonstrated by node operators suggests a promising outlook for the CSM mainnet launch.

You can look at all the aggregated data in our Dune dashboard.

In conclusion, the CSM Testnet analysis reveals a highly successful and promising foundation for the upcoming Mainnet launch. The overwhelming majority of node operators demonstrated exceptional performance and commitment, with over 92% meeting or exceeding the stringent criteria set for good performance and sufficient participation time. This level of excellence bodes well for the future of the Lido ecosystem, suggesting a robust, reliable, and efficient network that can support the growing demands of decentralized finance.

The high performance across a diverse range of operators, indicates a healthy and resilient network. The fact that many operators achieved near-perfect or perfect performance scores is particularly encouraging, as it suggests a strong dedication to maintaining optimal system functionality.

As the CSM moves towards its Mainnet launch, these results provide confidence in the system's ability to handle real-world challenges and maintain high standards of operation. The Lido community can look forward to a stable, secure, and efficient staking solution that leverages the collective strength of its well-prepared node operators.

We commit our intellectual, social and computational capital to help bootstrap the cryptoeconomic networks of tomorrow. We are an independent team of crypto-native node operators and builders with a mission to support emerging chains and other kinds of decentralized networks from day one.

We began this series of posts by highlighting the potential dangers associated with node operators becoming excessively large and exacerbating centralization issues within Liquid Staking Protocols (LSPs). As we continue this series, we provide insights and strategies for smaller Node Operators (NOs) to grow and establish themselves in the network. At first glance, this might seem contradictory. However, it's important to understand that by empowering new entities to become NOs, fostering their growth, and encouraging open discussions about operational strategies, we are actually working towards reducing the reliance on large node operators within LSPs.

This is the second part of a series about the current state and possibilities of node operation on Ethereum’s LSPs. You can find the first part here.

In the first part we discussed the motivation for NO decentralization in the LSP landscape, and listed the most relevant permissionless LSPs and their specifics.

In the second part of this series, we discuss the same permissionless LSPs in the context of starting as a NO, and point out what we gather to be the most relevant option. Furthermore, we discuss what we believe to be the best path for aspiring small- and medium-scale node operators to approach node operation.

Let’s recall the most relevant points of the LSPs described in the previous post. We do so from the NO perspective and focus on trust mechanisms. Keep in mind that Lido CSM is in testnet, and the mainnet configuration parameters are still not decided, and might change.

Lido CSM, has a reasonably low bond, and it can get even lower with an increasing number of validators. The main argument against CSM is centralization. Lido already controls a very large portion of stake, which makes Lido’s smart contract infrastructure a single point of failure.

Ether.fi offers a path to run a node operator without any bond, however you need to commit to run the validator for at least 2 years, and surrender your personal information. Furthermore, there is a 2 week test period, where you need to run a validator on testnet, so it is not truly permissionless.

Rocket Pool and Stader have both more complex setups, and higher ETH requirements. First you need to provide self stake of 8 and 4 ETH respctively; and an extra collateral in the protocols’ own tokens. Keep in mind that the amount of collateral required is measured in ETH, so that if the collateral that you provide depreciates, you need to provide more in order to keep earning the validation rewards.

Puffer also has a relatively complex mechanism where the node operator must pay one Validator Token per validator each day. While this is a great incentive to prevent “lazy” node operators, the price of the validator token dictates the final reward.

Diva provides a lower bond for entry, however participation in the relatively large DVT cluster dilutes the validation rewards.

In summary, all protocols have some sort of bond requirements, which as mentioned previously, boil down to a matter of economic trust between the LSPs and the aspiring node operators.

Lido CSM: The Most Accessible Option for Aspiring Node Operators

Among the available options, we believe that Lido CSM stands out as the most accessible for several reasons:

• Simplified bonding mechanism: No complex processes involving additional tokens

• Comprehensive documentation and support: Facilitates easier onboarding for new operators

• Strategy to reduce centralization: Moving stake from curated NOs to smaller, independent ones

This shift in Lido's strategy offers two key benefits:

• Decreased protocol centralization

• Improved physical infrastructure decentralization (fewer validators per node)

It's important to note that while Lido CSM was primarily designed for solo stakers, it presents an opportunity for aspiring node operators of various backgrounds. To manage this transition, Lido CSM will implement a permissioned Early Adoption period, preventing an influx of professional node operators.

Ultimately, when Lido CSM becomes permissionless, it will serve as a valuable entry point for new node operators to gain experience and establish their reputation within the Ethereum ecosystem.

For NOs looking for validation as a reliable source of income, the current trust mechanisms are not ideal. In particular, current bond requirements do not scale.

Consider this: running 300 validators requires an investment of approximately 390 ETH for bonds plus operation costs. With an optimistic annual return of about 28 ETH, node operation is not realistically sustainable.

To grow as an NO, one must secure bonding for far more than 300 validators. This necessitates addressing the trust issue from a different perspective. We envision two potential solutions:

1. Building sufficient reputation could lead to lowered—or even eliminated—bond requirements, as liquid staking protocols develop trust in the operator.

2. Accumulating comprehensive performance metrics over time could allow for quantification of inefficiency and slashing risks, potentially enabling the provision of bonds through insurance for a precise amount of ETH.

It's crucial that reputation claims are supported by publicly disclosed data. The key to trust lies in meticulous, accurate, and transparent performance tracking, coupled with continuous sharing of engineering practices.

Node operators should aim to build a strong and provable reputation of technical proficiency. Ideally, we want to build it in a cost-effective way.

Public Disclosure of Technical Aspects of Operation

Transparency is a cornerstone of building trust in the node operation ecosystem. It is imperative that all technical aspects of operations, except sensitive information, are comprehensively disclosed to the community. This level of openness not only demonstrates a commitment to accountability but also allows for peer review and continuous improvement. By sharing detailed information about their infrastructure, processes, and performance metrics, node operators can establish credibility and foster a culture of collaboration within the Ethereum network.

Tools

Tools developed in-house should be made available as open-source software, allowing for thorough community review and potential contributions. This practice demonstrates transparency and also fosters collaboration and continuous improvement within the ecosystem. By sharing their custom-built tools, NOs can showcase their technical expertise and commitment to the broader community.

The use of outsourced tools should be clearly and transparently disclosed. Node operators should provide detailed information about any third-party software or services they utilize in their operations. This transparency extends to specifying the versions, configurations, and any customization made to these tools. By doing so, node operators demonstrate their commitment to openness and allow for a comprehensive understanding of their technological stack.

Additionally, node operators should maintain up-to-date documentation on their tooling choices, and any planned changes or upgrades. This level of detail provides valuable insights for other operators.

Performance Metrics

Ethereum validators have a few well-defined duties, each of which can be successfully completed or failed. While the RAVER metric is useful, a more detailed breakdown is preferable:

• Block attestation rate, including inclusion delay

• Block proposal rate

• Sync committee participation

It's also crucial to report certain aspects of the infrastructure:

• Execution/Consensus/Validator client composition

• Node location setup, if relevant.

Risk Management and Operational Excellence

Providing regular, detailed updates about engineering practices is crucial for building trust and demonstrating operational competence. These updates should encompass a wide range of critical aspects:

• Slashing protection strategies: Detailed explanations of implemented measures to prevent slashing events, including redundancy systems and monitoring tools.

• Downtime response plans: Documentation on procedures to minimize downtime caused by unexpected reasons.

• Maintenance and upgrade procedures: Step-by-step documentation of processes for routine maintenance and software upgrades, including downtime management and rollback protocols.

• Key management protocols: In-depth overview of secure key generation, storage, and rotation practices, emphasizing multi-layer security measures and access controls.

• Incident response plans: Outline of procedures for handling various potential issues, from minor performance hiccups to major security breaches.

• Continuous improvement initiatives: Regular reports on efforts to enhance operational efficiency, security, and overall performance based on industry best practices and lessons learned.

The purpose of this second part of the series is twofold: we want to openly discuss opportunities for smaller players in the NO space and also contribute to the overall health and decentralization of the Ethereum network. By providing pointers for growth and success to smaller operators, we hope to help create a more diverse and robust network of validators. This diversity is crucial in mitigating the risks associated with having a small number of large operators controlling a significant portion of the network's stake.

Furthermore, as more entities enter the NO space and grow their capabilities, it naturally leads to a more competitive and innovative environment. This competition can drive improvements in operational efficiency, security practices, and overall network performance. It also provides LSPs with a wider pool of reliable operators to choose from, reducing their dependence on a select few large operators and thereby enhancing the network's resilience against potential points of failure or centralization.

In the next part of this series, we'll dive into a more technical aspect of node operation, and showcase one of our tools designed to automate validator management on the Lido CSM protocol.

We commit our intellectual, social and computational capital to help bootstrap the cryptoeconomic networks of tomorrow. We are a team of crypto-native node operators and builders with a mission to support emerging chains and other kinds of decentralized networks from day one.

TLDR

• The combination of capital and technical barrier of entry has pushed the solo staker category to represent between 1% and 6.5% of the total ETH staked, based on Dune Analytics and Rated estimates

• Rated reports that almost 50% of all staked ETH is handled through the top 4 staking entities, which either run their own centralized validators, or delegate to a limited set of established Node Operators (NOs).

• This concentration of both stake and infrastructure by a handful of entities is against Ethereum’s vision of decentralization, and more concretely a risk for Liquid Staking Protocols (LSPs)

• LSPs have become aware of this situation and are opening up to increasingly permissionless models for NOs, with the aim of reducing the share of the established node operators.

• The biggest challenge for new NOs is to build trust among LSPs

• In consequence, each of these protocols have devised their own way of establishing trust with unknown NOs, as well as different reward mechanisms to attract new potential NOs and compete with other LSPs.

• Firstset has created a table summarizing the most relevant protocols’ key points ranging from Liquid staking, Lido CSM, Ether.fi, Rocketpool as well as others such as Stader and Puffer

• In this post we have given an overview of the most relevant liquid staking protocols from the perspective of aspiring node operators. This includes collecting information on their requirements and reward mechanisms, as well as some of their particularities.

• In the second part of this series, we will discuss the pros and cons of these protocols, and point out what we gather to be the most attractive option. Furthermore, we will discuss what we believe to be the best path for aspiring small- and medium-scale Node Operators to approach permissionless operation.

This is a series about the current state and possibilities of node operation on Ethereum’s Liquid Staking Protocols (LSPs).

It is aimed for people or entities interested in entering the node operation arena at small- or medium-scale, and using LSPs. We assume the reader knows the basics around running an Ethereum node, and participation in the proof-of-stake consensus mechanism.

The first part aims to give an overview of the most relevant LSPs allowing permissionless participation, describing their requirements and particularities. We believe that this information is valuable for potential node operators, and will help users to decide which path is more aligned with their specific interests.

In the second part of this series we take this information and discuss what we believe to be the best path for aspiring small- and medium-scale node operators (NOs).

Macro overview of stake ETH

Up until recently, the only way to actively participate and earn yield in the Ethereum proof-of-stake protocol was to join as a solo staker. Doing so entails several requirements. From those, the most difficult to meet is the required stake of 32 ETH, a prohibitive amount for most.

Despite the fact that the Ethereum Foundation deemed that solo staking is the best staking option for securing Ethereum, the combination of capital and technical barrier at entry has pushed the solo staker category to represent only 1% to 6.5% of the total stake, based on Dune Analytics and Rated estimation.

In other words, between 94.5% and 99% of staked ETH is managed by non-solo stakers.

LSPs are an answer

It has been possible for < 32 ETH holders to participate in a passive manner via Liquid Staking Protocols (LSPs): Pools that receive and accumulate ETH from stakers; and delegate operation of validators to NOs. In this model, the liquid staking protocols (and their NOs) get a cut of the stakers’ yield in exchange for their service.

Generally, participation as a NO in the most relevant LSPs has been restricted to a handful of teams, which have the reputation and means to do so at scale. For example, Kiln, the largest NO according to Rated, has close to 47,000 active validators, corresponding to ~1,504,000 in staked ETH, or ~$3.7bn at today’s price(at ETH: $2.5k) and equivalent ~4% of all staked ETH. 🤯. Most of this of this amount is not directly owned by Kiln, but it’s delegation received from LSPs.

Rated reports that almost 50% of all staked ETH is handled through the top 4 staking entities, which either run their own centralized validators, or delegate to a limited set of established Node Operators (NOs).

Risk of current staking ecosystem

This concentration of both stake and infrastructure by a handful of entities is against Ethereum’s vision of decentralization, and more concretely a risk for LSPs. Imagine a scenario where a subset of the largest NOs stops working —either because of an attack, failure of underlying infrastructure, or even willingly— with a specific LSP, this could result in significant financial loss for both the affected protocol, and their stakers. Such scenario however unlikely, is not impossible.

In simple terms, liquid staking is a convenient option for <32 ETH holders that want to stake in Ethereum. Yet, this convenience has resulted in actual node operation and PoS validation to become very much centralized.

Luckily, LSPs have become aware of this situation and are opening up to increasingly permissionless models for NOs, with the aim of reducing the share of the established node operators.

However, to participate as a NO for an LSP, one needs to acquire a certain amount of trust. After all, the LSP is entrusting unknown NOs with their ETH, at the risk of inefficiency, or worse, slashing.

In consequence, each of these protocols have devised their own way of establishing trust with unknown NOs, as well as different reward mechanisms to attract new potential NOs and compete with other LSPs.

The following table summarizes the most relevant protocols’ key points. Liquid Staking and Solo Staking are included as baselines for comparison:

*Example operation cost on dedicated server on Hertzner, per node. You can run many validators per node, but you need at least one node to run one validator. The operation cost does not scale linearly with number of validators, as the count of validators increases, more automation and monitoring tools are needed.

• Lido CSM

  • Currently testnet only. Mainnet deployment will be voted by the end of 2024

  • The NO has to provide a bond as collateral for slashing events. The bond for the first validator is 2.4 ETH, and 1.3 ETH for each subsequent validator.

• Ether.fi

  • The NO has to provide a 2 ETH bond as collateral for slashing events.

  • To be able to participate as a NO with no bond, the operator must commit to run the node for 2 years.

  • The nodes will be run as part of an Obol DVT cluster.

  • The operator can receive initially up to 96 ETH.

  • 2 week testnet trial-period before allocation of stake.

• Rocket Pool

  • Requires both ETH self-stake, and collateral in RPL tokens. The RPL requirement is at least 10% and up to 150% of the borrowed ETH amount in RPL token. This is an ongoing requirement, meaning that if the price of RPL drops with respect to ETH, the node operator must supplement the collateral until at least 10% is reached again.

  • The deposited RPL collateral also generates rewards.

• Stader

  • Requires both ETH self-stake, and collateral in SD tokens. SD is Stader’s own token.

  • SD collateral goes from 0.4 to 8 ETH in SD token. The specific percentage is chosen by the node operator. similar to Rocket Pool, this is an ongoing requirement.

  • SD deposit also generates rewards.

• Puffer

  • Bond is 2 ETH, but can be reduced to 1 ETH if executing Secure-Signer software, which requires specific hardware and configuration for Trusted Execution Environments (e.g. Intel SGX)

  • All PoS rewards are given to the node operators. However, node operators must pay upfront for the “right” to validate, with one Validation Token (VT) per day. The cost of one VT is ~90% of the daily rewards of a single validator. The price of the VT token is set by Puffer, and greatly influences the APR of the node operator.

• Diva

  • The node is to be operated as part of a 16-participant DVT cluster, where each participant holds a key share.

  • Requires a 1 ETH Bond per key share. This causes the node operator reward to be very diluted.

The table considers running only a single validator. However, hundreds of validators can be run within a single node, thus the operational costs of running nodes get reduced in proportion to the total amount of validators per node. One validator manages 32 ETH of stake, so a single node could manage tens of thousands of ETH. However, too much stake on top of a single node is not a very good idea in terms of fault-tolerance.

• Distributing validators over several nodes with tech like Vouch or DVT solutions give effective fault-tolerance.

All node operation options require roughly the same amount of tech expertise. This includes running nodes, setting up the validators, monitoring, and maintenance.

All node operation options give freedom to the operator to choose their preferred stack, and geographical location. This is potentially beneficial as diversity is fundamental for systemic resilience of Ethereum.

In this post we have given an overview of the most relevant liquid staking protocols from the perspective of aspiring node operators. This includes collecting information on their requirements and reward mechanisms, as well as some of their particularities.

In the second part of this series, we will discuss the pros and cons of these protocols, and point out what we gather to be the most attractive option. Furthermore, we will discuss what we believe to be the best path for aspiring small- and medium-scale Node Operators to approach permissionless operation.

We commit our intellectual, social and computational capital to help bootstrap the cryptoeconomic networks of tomorrow. We are a team of crypto-native node operators and builders with a mission to support emerging chains and other kinds of decentralized networks from day one.