In the early morning, a hacker invaded one address in the Lido oracle's multi-signature wallet, exposing their whereabouts after stealing 1.4 ETH. Will this theft have a substantial impact on Lido?
Written by: @IsdrsP (Lido Validator Node Manager)
Compiled by: Nicky, Foresight News
On the morning of May 10, oracle service provider Chorus One disclosed that a hot wallet of the Lido oracle was hacked, resulting in the theft of 1.46 ETH. However, according to security audits, this isolated incident has limited impact, as the involved wallet was originally designed solely for lightweight operational purposes.
An oracle attack indeed sounds terrible. However, Lido's architectural design, stakeholder value concepts, and security-oriented contributor culture mean that the impact of such incidents is extremely limited - even if the oracle is completely compromised, it would not cause catastrophic consequences.
So, what makes Lido unique?
Thoughtful Design and Layered Protection Mechanisms
Lido's oracles are responsible for transmitting consensus layer information to the execution layer and reporting protocol dynamics. They do not control user funds. A single faulty oracle will only cause minor inconvenience, and even if the quorum is breached, it will not result in catastrophic consequences.
What malicious actions might a single compromised oracle attempt?
A) Submit malicious reports (which will be ignored by honest oracles);
B) Deplete the ETH balance of that specific oracle address (which is only used for operational transactions and does not hold stakers' funds).
What responsibilities do oracles actually bear?
Lido's oracles are essentially a distributed mechanism composed of 9 independent participants (requiring 5/9 consensus), primarily responsible for protocol state reporting, with current core functions including:
• Token inflation reward distribution (rebase)
• Withdrawal process handling
• Validator node exit and performance monitoring, for CSM (Community Security Module) reference
These oracles submit "reports" of the states they observe to the protocol. These reports are used to calculate daily cumulative rewards or penalties, update stETH balances, process and finalize withdrawal requests, calculate validator exit applications, and measure validator performance.
Essentially, Lido's oracles differ from what people typically understand as "multi-signature". Oracles cannot access stakers' or protocol funds, cannot control any protocol contract upgrades, and cannot upgrade themselves or manage membership. Instead, Lido DAO maintains the oracle list through voting.
The oracle's functionality is extremely limited - they can only submit reports that strictly follow deterministic, audited, and open-source algorithms designed for different protocol objectives; execute transactions under specific circumstances to implement report results (such as the protocol's daily rebase operation).
What's the worst-case scenario if 5 out of 9 oracles are compromised? In this case, compromised oracles might collude to submit malicious reports, but any report must pass on-chain protocol reasonableness checks.
If a report violates these reasonableness checks, its processing time will be extended (or may never be "settled"), as the values in the report must conform to the allowable range of value changes within a specific time period (days or weeks).
In the worst-case scenario, this might mean that stETH rebase (whether positive or negative) would take longer to take effect, which would impact stETH holders, but would be minimal for most holders, unless someone uses stETH with leverage in DeFi.
Other possibilities exist: if malicious oracles and their accomplices possess certain information or have the ability to impose large-scale penalties at the consensus layer, they might seek economic benefits by exploiting delays in stETH updates on the execution layer.
For example, in case of large-scale slashing, some might sell part of their stETH on decentralized exchanges (DEX) before the negative rebase takes effect. However, this would not affect withdrawals initiated directly through Lido, as the protocol's "bunker mode" would activate to ensure fair withdrawal execution.
Immediate and Comprehensive Transparency
Throughout, all participants in the Lido ecosystem - whether contributors, node operators, or oracle operators - have always prioritized transparency and goodwill, focusing on protecting stakers' rights and the ecosystem's healthy development.
Whether actively publishing detailed post-event analysis reports, compensating for staking losses due to infrastructure downtime, proactively exiting validator nodes for preventive reasons, or quickly releasing comprehensive incident reports, these participants have always viewed transparency as paramount.
Continuous Iterative Upgrades
Lido always stands at the forefront of technological R&D, committed to enhancing oracle mechanism security and trustlessness using zero-knowledge proof (ZK) technology. Early on, the team invested over $200,000 in specialized funds to support trustless verification of consensus layer data through zero-knowledge proof technology.
These technological explorations ultimately led to the upcoming launch of the SP1 zero-knowledge oracle "double verification" mechanism developed by the SuccinctLabs team this year. This mechanism provides an additional security verification layer for potential negative rebase operations through verifiable consensus layer data.
Currently, such zero-knowledge technologies are still in development, and related zero-knowledge virtual machines (zkVM) not only need real-world testing but also face limitations such as slow computational speed and high computing costs, unable to completely replace trusted oracles. However, in the long term, these solutions may become trust-minimized alternatives to existing oracles.
Oracle technology is highly complex with diverse application scenarios in DeFi. In the Lido protocol, oracles as a core component are carefully designed, significantly reducing the impact of potential risks through effective decentralized architecture, responsibility separation mechanisms, and multi-layer verification systems.
Content source: https://x.com/IsdrsP/status/1921616790599135318
