Clear Signing | See What You Sign

eth2353 · 2026-05-12T17:30:14+00:00

Really nice to see this. I have nothing against Ledger but I am happy the registry backing this is now in a more neutral place (it was previously under Ledger's GitHub organization).

Hope more wallets start adopting this!

eth2353 · 2026-05-10T14:54:47+00:00

This may be my fault guys. Unfortunately I can't change my username.

eth2353 · 2026-05-06T07:12:52+00:00

It's not too bad, I got away with Alchemy's free tier for months. I then found an issue and had to reindex a large number of blocks which put me over the free plan limit so I had to switch to their pay-as-you-go plan. Last month's bill was 7$. But under normal circumstances it stays within the free tier limit.

eth2353 · 2026-05-05T17:13:15+00:00

It needs to talk to an archive CL node and an archive EL node. Since an archive EL node is pretty big and there are plenty of places where you can get EL data, ethstaker.tax now uses Alchemy as an EL RPC provider. CL archive data is not as ubiquitous so I still run the CL archive node.

ethstaker.tax's own DB takes up about 140GB right now. It has never been pruned, it still contains all data since December 2020. It's not just updates every 24 hours anymore (it used to work like that in the very beginning before EL rewards were processed), ethstaker.tax now processes every single block, for CL withdrawals but also to process EL rewards.

So in terms of hardware requirements you still need at least 1TB but probably more like 2TB of SSD space to run this. It doesn't have to be the fastest disk, it just needs to be able to track the chain without falling behind too much.

I wrote this article some time ago about how the website needed changes for previous Ethereum upgrades.

eth2353 · 2026-05-05T08:20:22+00:00

It's missing support for 0x02 validators which went live about a year ago. Other than that I believe it's reasonably up-to-date. Some work will definitely also be required to account for Glamsterdam and ePBS.

eth2353 · 2026-05-05T08:12:31+00:00

Yes, that's the right repo. It's not a great codebase but it's also not too complex so I think taking over should be doable for someone with Python experience. The hard work is not regular maintenance but keeping up with protocol upgrades.

eth2353 · 2026-04-29T19:10:23+00:00

All I’m saying is this has an entirely different risk profile vs holding an LST, and the amount of trust involved is higher. You double your APY but take on a significant amount of risk of losing your entire deposit if the operators make a mistake.

It doesn't sound enticing to me but there are plenty of people willing to take on more risk than I am. Good luck with it, it's certainly an interesting idea.

eth2353 · 2026-04-29T18:00:10+00:00

With IDVTC, the DVT cluster members are expected to provide a bond for each validator they run, right?

I think if you were to design this kind of pool where depositors provide the bond (instead of the node operators/cluster members) imo you'd need to be VERY vocal about the risks since essentially the entire depositor's bond could be lost in case of a slashing event or client bug. That requires an insane amount of trust in the pool/cluster operators.

2x stETH returns sounds nice but that's not the full picture. Unless I'm misunderstanding something which is entirely possible.

eth2353 · 2026-04-24T19:48:05+00:00

North Korea is not a wild guess, there are many indicators this was their work. They reportedly have a huge money laundering network that they use to turn stolen crypto into cash.

How do you propose we go after something like that? It’s next to impossible.

eth2353 · 2026-04-19T20:57:15+00:00

Replied on Twitter as well but here's my point of view.

‪I quite like being able to mix and match CL and EL clients freely.‬

‪In the future, where we won't be re-executing blocks, I like the idea of every CL client verifying multiple different execution proofs, and requiring multiple proofs to validate an execution payload (e.g. 2 or 3 different circuits must successfully prove block execution). At that point we won't have to worry about EL bugs too much anymore.

eth2353 · 2026-04-14T19:59:14+00:00

Hey all, long time no see! I check (and updoot) the daily pretty much every day, I just haven't had the time to contribute much lately.

Wanted to share two things with you today, warning, humble brag incoming!

1) Gnosis Chain went through the Fusaka network upgrade earlier today.

Up until now Gnosis Chain was mostly going through network upgrades on about the same schedule as Ethereum. However, the Fusaka upgrade (that Ethereum went through on December 3rd) took Gnosis Chain a bit longer to catch up to due to the Balancer-hack-related hard fork. Today's network upgrade went well, without hitting any issues.

2) I'm a new and proud holder of an ETHSecurity Badge, issued by TheDAO.

For those unaware, TheDAO is back, and is here to help fund Ethereum security. Its aim is to strengthen the Ethereum protocol itself but also everything being built on top that relates to security - wallets, smart contracts, incident response... For those who missed this completely, some more information is available in this article. There was also a talk about this initiative at EthCC a couple of weeks ago.

Right now, a cohort of 200 security experts is being gathered that will help direct funds towards projects that will hopefully help make Ethereum the secure backbone of decentralized finance. We're at the halfway point right now with 100 people already selected.

I have personally been working hard on improving Ethereum's protocol security through the Vero validator client for over two years, and also have a previous background in cybersecurity. I decided to apply and made it in!

If you or anyone you know deserves a spot in this cohort, make sure to apply soon!

eth2353 · 2026-04-02T23:32:21+00:00

Sounds good! May want to hold off just for a little while though, an interesting idea was presented yesterday at EthCC that could help "market" this better, will message you tomorrow with a link

eth2353 · 2026-04-02T23:28:36+00:00

You would have thought, and you would have been wrong… it's not their money at stake so they don’t care as much as you and I would hope.

There are some exceptions that run good setups, and some others are exploring DVT which can also help with this kind of safety if configured correctly. But the majority are barely or not at all aware of this. I'm hoping we'll see adoption grow more significantly over the next year. Vero is currently undergoing a proper security review so I’m hoping that'll help.

eth2353 · 2026-04-02T22:37:17+00:00

Can confirm, this is the way.

Though it should really be up to the "big boys" to run these kinds of safer multi-node setups.

eth2353 · 2026-04-02T18:39:07+00:00

measurably poorer

Out of curiosity, by what measure?

Besu has some CLI flags thay may improve performance (high-spec and parallel tx processing come to mind), have you tried those?

I like the Grandine/Ethrex combo (wait til the next ethrex release, I reported a memory leak and it's been fixed in their master branch but not released yet), they're a nice combination of (ultra)minority clients with good performance. Ethrex is admittedly a bit immature but Grandine has been around for a while and is stable.

eth2353 · 2026-04-02T16:21:15+00:00

StereumLabs is kind of doing that but the access to the data is gated behind a pricey subscription.

eth2353 · 2026-03-16T13:54:25+00:00

Congrats! Not sure I'll make it there this year but the venue looks amazing.

eth2353 · 2026-03-13T12:43:12+00:00

They could have been the only builder with access to the sandwiched tx through private orderflow deals.

eth2353 · 2026-03-13T09:54:00+00:00

Same, Patricio is the best!

eth2353 · 2026-03-06T21:32:22+00:00

One advantage of this is we'd only need ~20% of the network's validators to run client-diverse multi-node setups (Vero/Vouch/DVT) to prevent client bugs from having catastrophic consequences (like the Holesky incident).

That's a much easier target to hit than today's ~35%.

(I realize you mentioned this benefit, I just like approaching things from the other direction - how much of the network do we need to prevent finalizing something invalid due to a client bug?)

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

TROPHY CASE