Home stake your ETH

When operating your own node you should spend some time learning how to use the software you've chosen. This involves reading relevant documentation and being attune to communication channels of those dev teams.

The more you understand about the software you're running and how proof-of-stake works, the less risky it will be as a staker, and the easier it will be to fix any issues that may arise along the way as a node operator.

Node setup requires a reasonable comfort level when working with computers, although new tools are making this easier over time. Understanding of the command-line interface is helpful, but no longer strictly required.

It also requires very basic hardware setup, and some understanding of minimum recommended specs.

Current community guidance for validator hardware and bandwidth is maintained in the hardware and bandwidth recommendations (EIP-7870) (opens in a new tab). As a rough guide, plan for a 4 TB NVMe SSD, 64 GB of RAM (less can work, but this is the recommended headroom), a solid modern multi-core CPU, and an internet connection of around 50 Mbps download / 25 Mbps upload.

Since the Fusaka upgrade introduced PeerDAS, a staking node only needs to store and download a fraction of the network's blob data, significantly reducing disk and bandwidth requirements for home stakers.

Just like how private keys secure your Ethereum address, you will need to generate keys specifically for your validator. You must understand how to keep any seed phrases or private keys safe and secure.

Ethereum security and scam prevention

Different from inactivity penalties for being offline, slashing is a much more serious penalty reserved for malicious offenses. By running a minority client with your keys loaded on only one machine at time, your risk of being slashed is minimized. That being said, all stakers must be aware of the risks of slashing.

Yes. A validator with compounding (0x02) withdrawal credentials can hold an effective balance of up to 2048 ETH, while the minimum to activate remains 32 ETH. Rewards on a compounding validator are added to its stake automatically, and it earns rewards on every whole ETH above the 32 ETH minimum, so you can stake amounts that aren't multiples of 32. See Compounding and the 2048 ETH maximum.

Validators with regular withdrawals (0x01) credentials remain capped at an effective balance of 32 ETH, with any balance above that automatically swept to the withdrawal address every few days.

For a compounding validator, only balance above the 2048 ETH maximum is swept automatically. To withdraw anything below that, you trigger a partial withdrawal from your withdrawal address (a transaction that costs gas), which can draw down any balance above the 32 ETH minimum. If you run multiple validators, you can also consolidate them into a single compounding validator without exiting the network.

More on staking withdrawals

Going offline when the network is finalizing properly will NOT result in slashing. Small inactivity penalties are incurred if your validator is not available to attest for a given epoch (each 6.4 minutes long), but this is very different to slashing. These penalties are slightly less than the reward you would have earned had the validator been available to attest, and losses can be earned back with approximately an equal amount of time back online again.

Note that penalties for inactivity are proportional to how many validators are offline at the same time. In cases where a large portion of the network is all offline at once, the penalties for each of these validators will be greater than when a single validator is unavailable.

In extreme cases if the network stops finalizing as a result of more than a third of the validators being offline, these users will suffer what is known as a quadratic inactivity leak, which is an exponential drain of ETH from offline validator accounts. This enables the network to eventually self-heal by burning the ETH of inactive validators until their balance reaches 16 ETH, at which point they will be automatically ejected from the validator pool. The remaining online validators will eventually comprise over 2/3 the network again, satisfying the supermajority needed to once again finalize the chain.

In short, this can never be fully guaranteed, but if you act in good faith, run a minority client and only keep your signing keys on one machine at a time, the risk of getting slashed is nearly zero.

There are only a few specific ways that can result in a validator getting slashed and ejected from the network. At time of writing, the slashings that have occurred have been exclusively a product of redundant hardware setups where signing keys are stored on two separate machines at once. This can inadvertently result in a double vote from your keys, which is a slashable offense.

Running a supermajority client (any client used by over 2/3 the network) also holds the risk of potential slashing in the event this client has a bug that results in a chain fork. This can result in a faulty fork that gets finalized. To correct back to the intended chain would require submitting a surround vote by trying to undo a finalized block. This is also a slashable offense and can be avoided simply by running a minority client instead.

Equivalent bugs in a minority client would never finalize and thus would never result in a surround vote, and would simply result in inactivity penalties, not slashing.

• Learn more about the importance of running a minority client.
• Learn more about rewards, penalties, and slashing

Individual clients may vary slightly in terms of performance and user interface, as each are developed by different teams using a variety of programming languages. That being said, none of them are "best." All production clients are excellent pieces of software, that all perform the same core functions to sync and interact with the blockchain.

Since all production clients provide the same basic functionality, it is actually very important that you choose a minority client, meaning any client that is NOT currently being used by a majority of validators on the network. This may sound counterintuitive, but running a majority or supermajority client puts you at an increased risk of slashing in the event of a bug in that client. Running a minority client drastically limits these risks.

Although a virtual private server (VPS) can be used as a replacement to home hardware, the physical access and location of your validator client does matter. Centralized cloud solutions such as Amazon Web Services or Digital Ocean allow the convenience of not having to obtain and operate hardware, at the expense of centralizing the network.

The more validator clients running on a single centralized cloud storage solution, the more dangerous it becomes for these users. Any event that takes these providers offline, whether by an attack, regulatory demands, or just power/internet outages, will result in every validator client that relies on this server to go offline at the same time.

Offline penalties are proportional to how many others are offline at the same time. Using a VPS greatly increases the risk that offline penalties will be more severe, and increases your risk of quadratic leaking or slashing in the event the outage is large enough. To minimize your own risk, and the risk to the network, users are strongly encouraged to obtain and operate their own hardware.

Every withdrawal requires your validator to have a withdrawal address set. New stakers set this at time of key generation and deposit. Stakers from the network's early days who have not yet set a withdrawal address will need to update their withdrawal credentials before withdrawing.

For validators with regular withdrawals (0x01) credentials, reward payments (accumulated ETH over the initial 32) are periodically distributed to the withdrawal address automatically. For compounding (0x02) validators, rewards remain staked and compound automatically. You can withdraw any balance above 32 ETH by triggering a partial withdrawal from your withdrawal address.

To unlock and receive your entire balance back you must exit your validator. You can do this using your validator signing keys, or trigger it directly from your withdrawal address with an execution layer transaction, meaning your funds remain recoverable even if your signing keys are lost.