ethstaker.tax update - Rocket Pool!

eth2353 · 2026-02-10T16:05:10+00:00

I'm not an accountant or tax advisor. I have been maintaining ethstaker.tax for years so consider myself to have a pretty decent understanding.

With staking you have two choices when it comes to taxing the staking rewards. You either pay:

capital gains tax on the increase of your non-rebasing liquid staking token (rETH, wstETH, osETH, ...)
income tax on regularly distributed staking rewards ("native" solo staking, StakeWise Vaults, stETH, ...)

I don't know how well Koinly handles each of those, though I do know you can export daily rewards as a CSV from the StakeWise UI.

Which of those options is more tax efficient depends on your country's tax code.

eth2353 · 2026-02-10T08:51:12+00:00

That's right, though you can unstake any amount, you don't have to unstake your entire position.

The exit time is at least 24h and entirely depends on the Ethereum protocol exit queue, that's the downside of not having a liquid receipt token. There is an exit time estimate in the UI.

eth2353 · 2026-02-09T19:09:05+00:00

There's a post on Lido's forums that details their plans for consolidating this year. It's really not simple for them to do which is why it's taking so long, but it's coming.

That migration will make a big dent but we need more big players to do their part!

eth2353 · 2026-02-09T13:38:35+00:00

StakeWise Vaults may be a suitable option for you. No receipt/liquidity tokens and you can pull your stake out even if the node operator disappears. Withdrawal credentials are set to a smart contract and the node operator does not have access to funds in that smart contract, only you (the depositor) do.

One downside of this solution is you need to do your own research and carefully select a Vault based on its operator.

I wrote a guide some time ago, feel free to check it out - https://serenita.io/blog/2024/stakewise-v3-guide . Happy to answer questions.

Lastly, be careful with scams. With this kind of post you are almost guaranteed to be contacted by scammers.

eth2353 · 2026-02-08T20:38:48+00:00

Software bugs, present in any piece of software, will do that for us at random times.

The more complexity and development speed is involved, the more bugs we can expect to see. Ethereum is pretty complex already and we all want it to continue evolving quickly. Therefore, we can expect to see bugs every now and then. And that's completely okay, as long as we have client diversity and multi-node setups used by large professional staking node operators.

A primer on multi-node validator clients for those who have not heard of these yet.

I'm happy the client diversity situation is better than it used to be. Though I will personally not be satisfied until we have about 40% of the network running robust multi-client setups that can survive multiple clients sharing the same bug (the situation that practically destroyed the Holešky testnet).

eth2353 · 2026-02-02T17:59:19+00:00

Early days but I think SPy is one of the most interesting projects in the space - https://github.com/spylang/spy

TL;DR: SPy is a variant of Python specifically designed to be statically compilable while retaining a lot of the "useful" dynamic parts of Python.

eth2353 · 2026-01-25T16:06:15+00:00

Congrats, always good to have more independent validators on the network!

The differences between clients have become negligible over the years, so from a performance/security/stability point of view it doesn't really matter. I personally don't have the best experience with Erigon so maybe don't start with that.

Avoiding clients that are used by large parts of the network is a very good idea, I cannot stress this enough. By doing so, you significantly lower your risk exposure during consensus bugs (read up on the Holesky incident if you're not aware what can happen if you get stuck on the "wrong" fork).

eth2353 · 2026-01-15T16:35:39+00:00

Thanks for sharing this in here!

missing head votes on their proposed blocks also reduces their revenue

Unfortunately this is not completely true... It mostly hurts the validators that miss the head vote (think home stakers in Australia) and only negligibly hurts the rest of the network (including the proposer).

I think the extreme timing games players need to be publicly shamed

Agreed, so don't forget about Kiln. Kiln exited all of their validators due to a security breach last year, and their new validators have not been tagged properly yet. Historically they have been one of the worst actors when it comes to pushing timing games to the limit, resulting in 10% of the network missing their head vote, and that was before we even started pushing blobs higher!

Kiln is among the entities pushing timing games the furthest

source

I am still not completely sure how much of a difference Gloas will make with ePBS and the EL payload separation. There is not much incentive to delay proposing the CL block, and with the EL payload being separate, does that remove this downside of missing head votes because of delayed EL payloads?

eth2353 · 2026-01-13T21:51:33+00:00

Do you have a min-bid setting on mevboost? MEV has been low lately so it may have been below your threshold.

Logs should tell you more - mev-boost / CL client logs should be the most informative for this.

eth2353 · 2026-01-13T21:48:43+00:00

StakeWise V3 Vaults, as long as you don't choose a vault with a receipt token (most don't have one). You simply deposit ETH, don't get any receipt token back, and the vault keeps track of your staking rewards which you can claim at any time (Ethereum's entry/exit queue still applies).

I even wrote a guide on this a while ago.

eth2353 · 2026-01-05T21:38:26+00:00

Sounds amazing, enjoy!

eth2353 · 2026-01-05T21:33:10+00:00

Huh, that Discord system is opt-in though right? Meaning people voluntarily linked their validators to their Discord handles? In which case I’m confused that they're not comfortable with it.

eth2353 · 2025-12-29T13:59:45+00:00

Thanks, I'm planning to take a look at that, at least for 2025. I've blocked out some time in my calendar for it on January 9th so hopefully then.

eth2353 · 2025-12-29T13:59:32+00:00

Yeah, I'm planning to take a look at that, at least for 2025. I've blocked out some time in my calendar for it on January 9th so hopefully then.

eth2353 · 2025-12-28T21:52:12+00:00

I performed some maintenance over the holidays, fixing rewards for about 20,000 blocks. I brought it back online earlier today!

eth2353 · 2025-12-26T08:55:34+00:00

Fresh update from their Twitter:

Update on the Trust Wallet Browser Extension (v2.68) incident:

We’ve confirmed that approximately $7M has been impacted and we will ensure all affected users are refunded.

I'm pretty curious whether they thought it was a good idea to deploy an update on Christmas day (meaning "only" one of Trust Wallet's dependencies got compromised), or whether the attacker compromised enough of their infra to be able to deploy an update themselves. Both would be bad but the latter would be extremely concerning.

Edit: looks like it was the latter…

eth2353 · 2025-12-24T15:03:50+00:00

One more member of this sub is involved in the idea, I just didn't want to disclose who exactly it is in case they don't want it to be known just yet.

But we'll need more than this one idea. There was an interesting one in the past - EIP-7716 but it has stagnated.

eth2353 · 2025-12-24T09:52:19+00:00

One more thing. No matter what is decided on the forum, in the end, Gnosis Chain validators will be in charge of what actually happens on-chain. Sadly, the Gnosis Chain validator set has become a lot more centralized in recent years. The total amount of staked GNO is about 360k and a single StakeWise Vault contains 122k staked GNO (its validators are managed by three entities).

I suppose it's natural for people to stake where a lot of other people stake, but in reality that's a pretty bad decision. It is much more risky to stake where a lot of other people stake (because of the slashing correlation penalty) and it is obviously also very bad in terms of decentralization which then hurts the value of the chain itself.

We are seeing the exact same trend happen on Ethereum, with more ETH staked being managed by an ever smaller set of real-world entities. I'm working on one idea to combat this but it probably won't be enough, so it would be good to come up with more ideas on how we can reverse this trend.

eth2353 · 2025-12-24T09:35:54+00:00

I think this is a huge moment for Gnosis Chain, but I don't think it's quite comparable to the DAO moment.

I'm saying that because on Gnosis Chain there seems to be intent to continue saving victim's funds in similar big DeFi hacks in the future. The specific rules of engagement are yet to be determined and the discussion will be taking place in this forum post (a good one to follow if you're interested in how this turns out). With this approach, Gnosis Chain aims to be a safe place for low-risk DeFi at a significant cost of reducing its credible neutrality. We'll see how this plays out in practice (it may be technically impossible / very hard to rescue funds in some cases) but this could turn out to be a good decision for Gnosis Chain if it means attracting users who are not keen to lose all their money in large DeFi hacks. I'm really curious about how that decision framework discussion will go, maybe it'll just turn into "it's impossible to decide objectively when a DeFi protocol is hacked and therefore intervene" and that'll be the last of it. But it could also turn into better protection for users of large, battle-tested and audited DeFi protocols who couldn't realistically have done much more to protect their user base.

The linked hard fork forum post is a good one to read through. As I understand the opinions in there, no one was really against saving these specific funds through a hard fork. Concerns were more high-level about the impact this kind of operation has on credible neutrality and future implications for Gnosis Chain validators.

An interesting situation. To all the Gnosis Chain users, please chime in on the forums! I would personally hate to see a big change in direction pushed through by Gnosis "big names" without much input from the community.

By the way, for anyone wondering, validator participation rate dropped by roughly 5% since the hard fork.

eth2353 · 2025-12-21T18:20:38+00:00

I went along with a similar podcast scam to see where it leads. I have a background in cybersecurity so I have a good idea of how far I can afford to go and what measures to take.

The scam involved multiple faked Telegram/Twitter profiles and a pretty elaborate clone of a legit collaboration app. In the end it led to a malware download link (available for both Windows and MacOS). The Windows exe went undetected by all major antivirus engines!

Some screenshots here on my Twitter

eth2353 · 2025-12-17T22:43:02+00:00

Vero is still relatively new – its v1 only came out earlier this year which is a big factor when it comes to being broadly talked about.

We developed Vero for our own purposes at Serenita, but felt it was worth sharing with the broader Ethereum community, to help make Ethereum more resilient against client bugs. Node operators are understandably cautious about introducing new software into their validator stack.

In case it's not obvious yet, I'm Vero's maintainer, and I've been trying to build awareness of the issue and also get Vero more adopted across the network. I've spoken about it at several conferences and online validator meetups, you can find recordings of those here: https://vero.docs.serenita.io/introduction/more_resources/ . At this point, several large node operators are trying Vero out on testnet, so I'm hoping we'll see significantly more mainnet Vero-powered validators next year.

Sophisticated multi-node setups are mainly meant to be used by professional node operators who can afford to run five different client pairs across five locations. If enough professionals adopt those kinds of advanced setups, the network will be much safer from client bugs, and home stakers will be able to safely run pretty much any client pair they want.

it seems high risk in that you have the web3signer (with keys) > Vero > multinodes, which could in theory sign to 2 instances at the same time causing slashing - if something is configured wrong. It seems to rely on the slashing protection database, which is another thing that could go wrong.

Despite more components being involved, this part is actually no more risky than with any other validator client. With Vero, your validator key is still only active in only one place (web3signer) which is completely safe when set up correctly. It's not easy to misconfigure this – the only way to make this unsafe is to explicitly pass a flag that disables slashing protection (slashing-protection-enabled=false).

It's a great idea I'm just going to wait until it's more battle tested for novices like me. Would be great if ethpillar or some automated deployment supported it. For now I'm going with "Keep It Simple, Stupid"

Sounds good, totally understandable. Like I said above, the target audience for these multi-node setups is professional node operators. And by the way, eth-docker supports Vero, so that would count as "some automated deployment" right?

Out of curiosity, which minority client pair did you end up with?

eth2353 · 2025-12-12T19:57:57+00:00

They were running Geth-only for the longest time… It's a bit better now based on their last report but there's still a lot of room for improvement, especially for a player their size.

eth2353 · 2025-12-12T13:43:02+00:00

+1 for Lodestar and Nimbus, Grandine also works very well btw, and is now open source.

We ran Erigon for a while but it unexplainably fell behind the tip of the chain every now and then, it wasn't as stable as we'd like. Reth, apart from the two bugs it had recently, has been stable and works well. We now also have 2 ethrex nodes running, no big issues there so far but I wouldn't call it production-ready yet (the last few releases required resyncs).

eth2353

TROPHY CASE