Emergency rotation of compromised Chorus One oracle

Proposals
1

TL;DR — One of the Lido Oracle addresses, managed and operated by Chorus One, is to be rotated, as there is evidence that the address was compromised. Lido DAO contributors are initiating an emergency DAO vote to rotate this key in the HashConsensus contracts for the Accounting Oracle, Validators Exit Bus Oracle, and CS Fee Oracle.

Stakers are not affected. The protocol remains secure and fully operational. The oracle system is robust by design, with a 5/9 quorum, and all other participants remain safe.
:check_mark: Oracle ops functioning, no sign of issue in oracle software or reports
:check_mark: Other eight oracles checked and no signs of compromise
:check_mark: No signs of broader Chorus One compromise

Broader infrastructure review is underway.

Incident Summary

On May 10, the Lido Oracle address operated by Chorus One oracle appears to have been compromised and its ETH balanced drained (etherscan).

A compromise of an oracle key was detected by a Lido Contributor upon investigating a low-balance alert for the address; the key is related to the Lido Oracle operated by Chorus One. The key, created in 2021 and in use since, was drained overnight and the issue surfaced after the alert was noticed. The exact source of compromise has not yet been traced, but there’s currently no evidence that this is due to direct or ongoing infrastructure compromise, and most likely related due to leakage of a hot wallet private key at a point in the past.

Lido contributors contacted the oracle operator to confirm the compromise and began an investigation. A response group was formed to assess the scope of the compromise (e.g. to assess whether it’s a compromised limit to the specific machine, a wider infrastructure issue, key material, or the oracle software supply chain), confirm that other oracle keys remained unaffected, and evaluate potential root causes.

In parallel, oracle report delays occurred on May 10th, 2025 (the lack of quorum was due to separate and unrelated node issues encountered by 4 of the other oracle operators, 2 of which are related to a minor Prysm bug post-pectra that is to be fixed soon). The delays were troubleshooted separately and addressed, and operations resumed.

Oracle operations digest for May 10:

  • Accounting Oracle (AO) report was delivered with ~1 hour delay at 14:06 UTC
  • ValidatorsExitBusOracle (VEBO) report delivered with ~2 hour delay at 14:40 UTC

Contributors began investigating the source of the key compromise in collaboration with Chorus One’s engineering and security personnel, and the integrity of the affected oracle set.

Immediate Mitigation Steps

Single Oracle key confirmed compromised — the wallet was drained; the issue appears isolated to a single key

All other oracles were checked — no signs of compromise in other oracle balances or keys

Software integrity was checked — Oracle software was double-checked for possible compromise (incl. in dependencies), and no signs of compromise were noted

Preparation for on-chain vote to rotate Chorus One Oracle key started

Investigation

Chorus One engineers and Lido contributors are actively reviewing:

  • Whether any other parts of Chorus One infrastructure were affected
  • Security controls and potential vectors of compromise

Proposed DAO Vote

The immediate mitigation step is to rotate (swap the affected key UPD: 0x140Bd8FbDc884f48dA7cb1c09bE8A2fAdfea776E with a new one 0x285f8537e1dAeEdaf617e96C742F2Cf36d63CcfB ) the affected oracle across the following oracle contracts:

  • AccountingOracle HashConsensus 0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288
  • ValidatorsExitBusOracle HashConsensus 0x7FaDB6358950c5fAA66Cb5EB8eE5147De3df355a
  • CSFeeOracle HashConsensus 0x71093efF8D8599b5fA340D665Ad60fA7C80688e4

The vote will update each relevant contract.

Next Steps

  1. Emergency on-chain vote to rotate the compromised oracle — launching ASAP.
    The vote will run for 72h main phase followed by a 48h objection phase.

  2. Full post-mortem will be published after the investigation is concluded.

Questions and comments welcome below.

11 Likes
2

Chorus One is updating the the address associated with the Lido Oracle set.

Oracle Set Address Rotation:

Old Address: 0x140Bd8FbDc884f48dA7cb1c09bE8A2fAdfea776E (signature)
New Address: 0x285f8537e1dAeEdaf617e96C742F2Cf36d63CcfB (signature)
Tweet announcement: https://x.com/ChorusOne/status/1921501112806301952

We are investigating the incident. At this point we have no evidence of an ongoing or recent compromise of our infrastructure; an isolated leak of this hot wallet key at a point in the past looks more likely. Out of an abundance of caution, we are setting up a brand new machine to run the oracle, which will not run any other workloads.

5 Likes
3

Standing by to vote as soon as the vote is published.

Thanks @ChorusOne for explaining the measures taken - changing to a new machine.
It isn’t very reassuring though that the hot wallet could be leaked. You mention “at a point in the past” - kind of suggesting that it was because of circumstances that are not in effect currently. Nevertheless, if you don’t know how it happened, how can you know it won’t happen again or that these circumstances aren’t present now? Would you mind detailing the measures you are taking so the new key won’t be vulnerable? What if it’s the developer’s machine that is compromised?

I don’t doubt you will take the best possible course of action, but transparency in these circumstances is very much appreciated :slight_smile:

4 Likes
4

Those are good questions that we’ve been looking into since we became aware of the leak. Investigation on all fronts is still ongoing; we will share a full postmortem after we conclude the investigation, but we also don’t want to start speculating, or jump to conclusions prematurely.

We audited the machine where the oracle was running, logs of critical services, and our infrastructure more generally, and so far we found no evidence of compromise of our infrastructure, and hot wallets similar to the compromised one remain unaffected. Activity of the exploiter points towards an automated system, rather than a targeted attack. Our team, infrastructure, and policies have evolved since 2021, when the compromised key was generated. It’s hard to definitively rule out anything for a key that has been in use for this long, but we can say that some classes of compromise look unlikely, based on accounts that are not affected.

3 Likes
5

Vote is launched: Lido DAO Voting UI

To check the vote items it’s recommended to use this guide: How to check the Lido DAO onchain vote #185 - HackMD

The main phase ends on
May 11, 12:15 UTC.

Please, cast your votes!

4 Likes
6

Rotating the single compromised key immediately while the rest of the 5/9 quorum stays intact preserves continuity of reporting and keeps stakers fully protected. Want to call out that the team’s thorough checks (all other eight oracles, software integrity, no wider Chorus One infrastructure issues) give confidence that this was an isolated hot-wallet leak rather than an ongoing breach. Ccommitting to a full post-mortem all show a mature, security-first response. No red flags here—this is exactly how a robust oracle set should handle an unexpected key compromise.

3 Likes
7

Reviewed and voted: YES

2 Likes
8

Thank you for your prompt response to the incident

I hope that Chorus One will investigate this hack soon to avoid the same situation in the future

Without a doubt, I vote for

3 Likes