# Emergency rotation of compromised Chorus One oracle **URL:** https://research.lido.fi/t/emergency-rotation-of-compromised-chorus-one-oracle/10037 **Category:** Proposals **Created:** [May 11, 2025, 9:56am UTC](https://research.lido.fi/t/emergency-rotation-of-compromised-chorus-one-oracle/10037 "2025-05-11T09:56:03Z") **Posts on this page:** 1 **Showing post:** 1
### Author: ![kadmil](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/kadmil/32/1958_2.png) [@kadmil](https://research.lido.fi/u/kadmil) #### Post date: [May 11, 2025, 9:56am UTC](https://research.lido.fi/t/emergency-rotation-of-compromised-chorus-one-oracle/10037/1 "2025-05-11T09:56:03Z")
**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. ✔ Oracle ops functioning, no sign of issue in oracle software or reports ✔ Other eight oracles checked and no signs of compromise ✔ 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](https://etherscan.io/tx/0xd081065af4621af128f24ec9ef10d4a023c2366c2626dccabbe16334d5232c3d)). 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](https://etherscan.io/tx/0xd081065af4621af128f24ec9ef10d4a023c2366c2626dccabbe16334d5232c3d) 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. --- _[View the full topic](https://research.lido.fi/t/emergency-rotation-of-compromised-chorus-one-oracle/10037)._