I run Dappnode with Nimbus. My fee recipient is set to Lido EL Rewards Vault (0x388C…) in the Web3signer, but since the last update there seems to be an issue with the fee recipient being set to the one specified in the client config instead of the ones from the Web3signer.
This resulted in my validators proposing two blocks with the wrong fee recipient address:
Block 21361349 and 21363403
@dgusakov reached out and the CSM committee proposed me to return the wrongly acquired EL rewards without additional penalties by sending them to the EL Rewards Vault: 0x388C818CA8B9251b393131C08a736A67ccB19297
The total acquired rewards are:
0.047682469603249899 + 0.137639774862815918 = 0.18532224446606582 ETH
They have already been returned to the EL Rewards Vault via the following Txn Hash:
0xb602ef9bd6e59dabaca3f2b60d26482b2b20a2a4b8748358019a1a9a235b1084
Since there is no straightforward fix to this issue in Dappnode, I’m awaiting an update from Dappnode team and will return any additional block rewards if they happen in the meanwhile.
I wasn’t able to set the global CL feeRecipient to Lido EL vault since I run a mixed setup in Dappnode with other validator aside from the CSM validators, so I rely in the Web3signer fee recipient specified for each one.
Thank you for the report @0x9a9e. I’m one of the signers in the CSM Committee and can confirm that the funds were sent to the Lido Execution Layer Rewards Vault.
Given this is not @0x9a9e’s fault and is a known issue in Dappnode, and because he seems to have been responsive and diligent with this matter, I’ll voice my support to not process any additional penalty fine.
Thanks for the explanation. Although I’m not a CSM Committee member, I want to emphasize that rewards misdirection happens due to a DAppNode issue (that I hope will be fixed soon). @0x9a9e immediately responded to my request and helped with the resolution.
As one of the authors of the MEV Stealing protection mechanism is CSM, I want to point out that the additional MEV stealing fine was introduced to protect from intentional malicious actions or irresponsible configuration of the validation node. None of those apply to the current case. Hence, I think that no additional penalty should be used in this particular and pretty unique case.
As additional update, and in case it helps anybody with the same issue, I’ve switched to Prysm client in the meantime as suggested by Dappnode support while they work on the fix, as they haven’t witnessed this issue in other clients than Nimbus. Hopefully this should prevent any more blocks being proposed with wrong fee recipient from my side.
Since this happened due to an issue with Dappnode, and given the fact that you were proactive in addressing it and immediately returned the correct amount to the protocol, as a member of the CSM committee, I do believe this case does not warrant a penalty.
Thank you @0x9a9e for being so proactive with this!
We (at Dappnode) are chasing down the bug… we are still not sure why only Nimbus has ended up like this. Needless to say this is a huge priority and we want to try to avoid this happening again. Current recommendation is to switch to another client. With checkpoint sync, it should be a matter of minutes if not seconds.
As I can attest that this is a known bug that seems to affect Dappnode users with Nimbus, and given the proactivity of @0x9a9e , I recommend and consider that the penalty is waved.
Thanks for the prompt report and action @0x9a9e. I am one of the Lido Community Lifeguards and I voice my support to not impose any MEV Stealing penalties for this case.
@0x9a9e’s actions were not malicious nor negligent and any other honest + responsible operator with the same setup could have faced the same issue.
Since we have been unable to replicate this (but the bug might be latent - it’s just that those who have it have not proposed blocks yet), I have set up my CSM setup in the same way and tested that the fee recipient is the correct one.
I have nonetheless left the setup as is, without trying to modify anything after a regular user update. Hopefully my CSM validators won’t replicate the issue, but trying to get to the bottom of this.
Quick update - we have noticed that despite MEV Boost being installed, after the last client update, the consensus client wasn’t picking up that MEV Boost was activated.
This does not fully explain why the consensus client picked 0x00 and not the web3signer’s set address, but is a hint towards the direction of the investigation.
The issue is persistent. I was contacted by Lido about a wrong Fee Recipient, even though I’m sure I set the correct address from the start, and it’s indeed the right Lido address in my Web3signer. I was running Dappnode / Nimbus. I switched to Prysm, but it seems that Prysm is also not retrieving my Fee Recipient address from Web3signer…
What is the best way of contacting you? Please DM me through the discourse DM platform with your TG or Discord contact to share logs with our devs and help with debugging and troubleshooting.
Rest assured, if the problem comes from Dappnode we will cover the lost fee
