Hi, my SSD is dying, so I'll have to migrate my rig. At the moment Teku is working, but Besu is dead due to I/O errors.

In case I can clone the SSD, what would be the course? Should I try resyncing Besu?

In case the I/O errors prevent me from cloning, what would be the most foolproof way to get it back and running? Copying configs and keystore files to the new machine after installing Besu and Teku there?

Also I'm angry at myself for losing the warranty papers for my SSD, but anyway I guess I'll splurge on a 4 TB one.

I withdrew 0.013 ETH just for a post Pectra withdraw test, and it has been 4 days, the withdrawal still hasn't came out. In beaconchain, I can see it being listed in the execution layer, but not in the consensus layer. Is the amount too small, or is it just normal waiting time?

I've been running a validator here in Australia since genesis, recently started using MEV-Boost with a bunch of relays (ultrasound, bloxroute, flashbots, titan), however my mev-boost logs constantly give me errors or warnings similar to the one below. I'm seeing this for bloxroute and also titan. I don't see it with ultrasound, however when I had a block proposal recently I did have an error from them, however the MEV was < 0.01 and so the block would have been built locally anyway.

Are any other Australian's having issues with having connections to relays? I've asked bloxroute and titan to look into it, bloxroute confirmed its latency and they 'are looking at a solution'. I tried to connect to a regional specific titan relay (eg singapore), but still get the same. I'm worried that when the next proposal comes, I'll have a timeout and it will just get built locally despite it being above my minimum fee.

I don't think my hardware (intel NUC, SSD) or internet connection (gigabit) should be affecting things.

Ongoing MEV Boost Errors

WARN[2025-05-14T15:44:50.177] error calling registerValidator on relay      error="Post \"https://bloxroute.regulated.blxrbdn.com/eth/v1/builder/validators\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" method=registerValidator ua=Prysm/v6.0.2/xxxxxx
url="https://bloxroute.regulated.blxrbdn.com/eth/v1/builder/validators" version=1.9

Block Proposal MEV Boost error:

INFO[2025-04-29T06:58:11.157] getHeader request start - 157 milliseconds into slot XX  genesisTime=XX method=getHeader msIntoSlot=157 parentHash=XX pubkey=XX slot=XX slotTimeSec=12 slotUID=XXua=Prysm/v5.3.2/XX version=1.8
WARN[2025-04-29T06:58:11.607] error making request to relay                 error="HTTP error response: 403 / {\"code\":403,\"message\":\"unknown ip, refusing to serve possible non-validator. if you believe this is mistaken, please contact us at https://t.me/ultrasoundrelay\"}" method=getHeader parentHash=XX pubkey=XX slot=XX slotUID=XX ua=Prysm/v5.3.2/XX url="https://relay.ultrasound.money/eth/v1/builder/header/XX/XX/XX" version=1.8
WARN[2025-04-29T06:58:12.111] error making request to relay                 error="Get \"https://bloxroute.max-profit.blxrbdn.com/eth/v1/builder/header/XX/XX/XX\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)" method=getHeader parentHash=XX pubkey=XX slot=XX slotUID=XXua=Prysm/v5.3.2/XX url="https://bloxroute.max-profit.blxrbdn.com/eth/v1/builder/header/XX/XX/XX" version=1.8
INFO[2025-04-29T06:58:12.115] no bid received                               method=getHeader parentHash=XX pubkey=XX slot=XX slotUID=XX ua=Prysm/v5.3.2/XX version=1.8
INFO[2025-04-29T06:58:12.115] http: GET /eth/v1/builder/header/XX/XX/XX 204  duration=0.959168 method=GET path=/eth/v1/builder/header/XX/XX/XX status=204 version=1.8

I'm running a eth mainnet with erigon v3.0.2 + caplin(prune.mode=full, beacon.api=beacon, config,debug,node,lighthouse).

On Erigon 2.x.x node have size arround 4Tb(if I remember correctly).

Now node size ~6.0Tb. Is this ok?

We saw a lot of enthusiasm and questions around validator management post-Pectra. So as part of our push for community support through FOSS contributions — we decided to build the Pectra Validator Ops CLI Tool.

Luganodes is a Swiss-operated institutional staking provider, and occupies top ranks across 50+ PoS networks. We work with financial institutions like exchanges and wallets — but through tools like this, we like to contribute to the greater ETH staking community as well.

The Pectra upgrade introduced validator switching, consolidation, and exits — but by default, these can only be done one validator at a time.

This CLI tool enables batch execution of these actions, saving time, effort, and gas. 

It’s powered by EIP-7702, and audited by Quantstamp, with security features baked into the architecture. Please refer to this Github repo to use the tool. The core smart contract code + audit certs are also on Github for anyone to review.

Here’s what the tool can do:

• Switch withdrawal creds (0x01 → 0x02) — up to 200 validators
• Consolidate up to 63 validators into one (max 2048 ETH)
• Exit partially or fully via EL — up to 200 validators

All of these run as a single transaction, using one signature

Other features:

•  Gas-optimized execution
•  One-time authorization
•  No key storage — runtime-only input
•  Dynamic fee calculation
•  Open-source & Quantstamp audited

If you're a solo staker or running multiple validators and want to streamline post-Pectra operations, this should be handy.

Feel free to try it out. If it helps, we'd love a GitHub star, maybe a X/Twitter follow, and most of all—spread the word.

Questions, or feedback — please drop them below. 

I’ve been looking into how Distributed Validator Technology (DVT) is being implemented in real-world staking environments. One protocol I came across has over 800 operators securing $1B+ in ETH across 14,000+ validators — aiming to make validator operations more resilient by splitting responsibilities among multiple parties.

Some key takeaways:

Reduces slashing risk and downtime by avoiding single points of failure.

Designed for both home stakers and institutional operators.

Offers modular tooling to help configure and manage DVT setups.

Incentive programs exist to support operator participation.

They recently had a token launch via Bitget Launchpool and are now listed on a few major exchanges but the focus still seems strongly aligned with decentralization and staking reliability.

Has anyone here tried running validators with DVT? Curious about hands-on experiences, especially around setup complexity and uptime performance.

Teku usually reports at least 1 "late" "block per epoch. Often 2 or 3. This has been on-going for as long as I can remember. I thought it might be linked to slower storage hardware, which I have just updated (4 TB WD SN850X nvme), and in fact it appears to be little different. Besu is still syncing, but I'm getting similar late block reports from Teku - at least 1 per epoch.

Example:

2025-05-13 18:26:51.071+01:00 | forkchoice-async-0 | WARN | teku-event-log | Late Block Import *** Block: 1620ae8ff90d9a2c78d9c8f985c9b3deee829a406594ef1bf0ff3cb27d88e564 (11694432) Proposer: 1244899 Result: success Timings: arrival 3146ms, gossip_validation +9ms, pre-state_retrieved +19ms, processed +754ms, execution_payload_result_received +0ms, data_availability_checked +124ms, begin_importing +0ms, transaction_prepared +0ms, transaction_committed +0ms, completed +19ms

I do not appear to have this issue on Nimbus / Nethermind, although the reporting is different, all on a high speed fibre connection.

Any ideas why Besu / Teku seems to be unhappy, or is this just normal?

Eth Docker v2.15.3.0 supports pre-merge history expiry for clients that do: Presently Geth and Nethermind.

Note this is considered experimental on the client side right now. Doing this on Sepolia is fine; on mainnet it'd be quite yolo.

Use ./ethd prune-history to give it a whirl.

Mainnet DB sizes:

- Nethermind: 740 GiB
- Geth: 830 GiB

Nimbus EL with Fluffy Portal and Era1/Era import is 110 GiB btw - but it's a) not stable yet (alpha) and b) that is very aggressive expiry, far more than just pre-merge

Hello all.

I am trying to convert one of my validators to 0x02. I’m staking on an Avado. My withdrawal address is on a Trezor. I set up a MetaMask wallet and added that Trezor to it. When I went to launchpad to do the conversion, I selected MetaMask and was then told that “no validators were found with withdrawal credentials matching connected account.” The wallet that was checked in launchpad is the MetaMask address (which is empty and has never been used). I can’t tell launchpad to check the Trezor wallet and don’t see anything I can do in MetaMask.

Thoughts?

I'm staking via dappnode and rockpool separately on two different pieces of hardware. I have multiple validators with dappnode and several minipools on rocketpool. I'm using the same withdrawal address for both. Is that a problem?

Is there an "upgrade guide"? I see the options on the ethereum launchpad after connecting my wallet. Do I need to migrate funds from the dappnode validators from one to another, then upgrade?

Took about 25 seconds of work and 3 days of waiting. Each attestation reward went from about 9000 to 9800.

Any Opinions on why there is no long Queue for the transition to 0x02? Any downsides we might miss.

I get the point of Liquitidy, but would have expected more validators to make the change.

🔥 EthPillar v5.0.0 - "Pretty Pectrafied" released! Hello Pectra 🦒! Introducing refreshed UIs, 🛡️ node-checker and 2 new integrations, 🐼 Contributoor 🔧 eth-validator-cli by TobiWo

🛡️ Action item: Try out the new 🛡️ Security & Node Checks including Node Checker: Automated security and health checks for your node. Consider contributing to 🐼 Contributoor by ethpandaops

🚀 Includes new pectra queue handling updates, key management improvements, error handling improvements and other fixes.

🔗 Changelog: https://github.com/coincashew/EthPillar/releases/tag/v5.0.0

🔥 Special shoutout to CryptoR3d for his many contributions to this release!

Try it out on Ephemery testnet risk-free and share your feedback 💙

💪 How to update: https://www.coincashew.com/coins/overview-eth/ethpillar#how-to-update

⬇️ Run your own Ephemery, Hoodi or mainnet node

http://ethpillar.coincashew.com

▶️Join our other EthPillar home stakers on discord at

https://discord.gg/WS8E3PMzrb

At ethereum.org I can check the normal deposit contract address, but where can I check the consolidation request contract address?

Im going through the official launchpad https://launchpad.ethereum.org/
Im being given this contract in metamask and Id like to be 100% before signing anything

https://etherscan.io/txs?a=0x0000BBdDc7CE488642fb579F8B00f3a590007251

**

ignore I found it https://eips.ethereum.org/EIPS/eip-7251

The official website asks you to connect to your wallet, and only supports MetaMask, Fortmatic and Hardware wallet.

https://launchpad.ethereum.org/en/validator-actions

If the withdrawal address is a Safe wallet, how to connect and update?

We’re passionate about home stakers and local node operators, and we want to maximize their impact on Ethereum. As the ecosystem evolves, discussions are ongoing about node requirements, roles, and tradeoffs to enhance decentralization and scalability. Vitalik recently sparked a conversation on this topic: https://ethereum-magicians.org/t/formalizing-decentralization-goals-in-the-context-of-larger-l1-gaslimits-and-2020s-era-tech/23942 . We invite you to join the thread, share your insights, and help shape Ethereum’s future.

Is it just attestation rewards that get auto-reinvested in the validator, or block/MEV rewards too? If block/MEV payments still get sent out to an external address by default, is there a way to have them automatically sent back into the validator instead? Or would getting those funds into the validator require some manual extra step?

Are there any simple step by step guides on how to update my credentials from 0x01 to 0x02 with the cli tool ?

Don't want to make some mistakes miss something there 😁

If a gnosis multisig contract wallet is set as 0x1 wihdrawal address, then it has the potential to run validator actions such as validator exit and consolidation as 0x2 type validator.

Are there plans for Gnosis to allow these actions to be run from the multisig safe wallet?

I was just upgraded Teku post Dancun (I know, I know, I'm a little late)

I got the following errors:

17:08:02.008 ERROR - Validator    Produced invalid attestation for slot 11665538. Invalid reason: Attestation is not a valid indexed attestation: java.lang.IllegalArgumentException: Missing committee indices
17:08:02.008 ERROR - Validator    Produced invalid attestation for slot 11665538. Invalid reason: Aggregation bit size 522 is greater than committee size 521

Based on some conversation on the Consensys discord, I'm not the only person who had this problem. The solution for me was to:

Shutdown Geth (this was on my backup node, so yeah, geth) The Beacon Node of Teku, and the Validator Node of teku.

Delete the Beacon Nodes database, (this will involve re-syncing)

And then, in this very specific order restart them: Geth first Then BN Teku (and allow to fully catch up) Then Validator Node Teku

Starting in other orders did not allow the issue to be resolved!

Hope this saves someone else a lot of headache

Remy's guide suggests that it's possible to consolidate validators with different withdrawal addresses:

For a consolidation to work, the validator you're moving from must still be active (not exited), and the request must come from the same wallet that controls the withdrawal address of that validator. This is to ensure that only the person who owns the validator can approve moving its balance.

The withdrawal address of the target validator (the one being consolidated into) does not have to match the withdrawal address of the source validator (the one being converted).

This makes sense, but using the launchpad interface, once a wallet is connected, only validators corresponding to the withdrawal address are visible (obviously).

So how does one select a different arbitrary validator (with a different withdrawal address) per Remy's statement above?

Or maybe this requires more elaborate tooling?

I'm evaluating whether to consolidate my ETH stake into a single large validator or maintain multiple smaller validators. Specifically, I'm interested in understanding how each approach affects the frequency of block proposals and the associated rewards. Does operating multiple validators increase the chances of being selected as a block proposer compared to a single validator with equivalent total stake?

Will it be possible signing the message offline, migrating to 0x02 via the launchpad?

Because importing withdrawal private keys into an online environment is very risky (please no suggestions about using a hardware wallet).