Author: @IsdrsP (Lido Validator Node Supervisor)
Compilation: Nicky, Foresight News
On May 10 at dawn, 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, security audits indicate that this isolated incident had limited impact, as the wallet in question was designed for lightweight operational use.
The attack on an oracle does sound terrible. However, the architectural design of Lido, the value concept of stakeholders, and the security-oriented culture of contributors mean that the impact of such events is extremely limited — even if the oracle is completely compromised, it will not lead to catastrophic consequences.
So, what is unique about Lido?
Thoughtful design and layered protection mechanisms
Lido's oracles are responsible for transmitting information from the consensus layer to the execution layer and reporting protocol dynamics. They do not control user funds. A single faulty oracle will only cause minor inconveniences, and even if the arbitration process (quorum) is compromised, it will not lead to catastrophic consequences.
What malicious actions might a compromised oracle attempt?
A) Submit malicious reports (but will be ignored by honest oracles);
B) Exhausting the ETH balance of that specific oracle address (which is only used for operational transactions and does not hold staker funds).
What responsibilities do oracles ultimately bear?
Lido's oracles are essentially a distributed mechanism composed of 9 independent participants (requiring a 5/9 consensus), primarily responsible for protocol state reporting, with current core functions including:
• Token inflation reward distribution (rebase)
• Withdrawal process handling
• Validator exit and performance monitoring for CSM (Community Security Module) reference
These oracles will submit their observed state 'reports' 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, the Lido oracle is different from what people typically understand as 'multi-signature'. Oracles cannot access staker and protocol funds, cannot control upgrades to any protocol contracts, and cannot upgrade or manage their own membership. Instead, the Lido DAO maintains the oracle list through voting.
The functions of oracles are very limited — they can only perform the following operations: submit reports that strictly adhere to deterministic, audited, and open-source algorithms designed for different protocol goals; execute transactions to implement report results under specific circumstances (e.g., the protocol's daily rebase operations).
What would happen if 5 out of 9 oracles were compromised? In that case, the compromised oracles might collude to submit malicious reports, but any report must pass the on-chain enforced protocol rationality checks.
If a report violates these rationality checks, its processing time will be extended (or may never be 'settled') because the values in the report must conform to the allowed value change range over a specific period (days or weeks).
In the worst-case scenario, this could mean that a rebase similar to stETH (whether positive or negative) takes longer to take effect, which would affect stETH holders, but the impact on most holders would be minimal unless someone uses stETH in a leveraged manner in DeFi.
There are also other possibilities: If a malicious oracle and its accomplices possess certain information or have the ability to impose significant penalties on the consensus layer (such as large-scale confiscation), they may exploit delays in the execution layer's stETH updates to gain economic benefits.
For example, if a large-scale confiscation occurs, some individuals may sell part of their stETH on decentralized exchanges (DEX) before the negative rebase takes effect. However, this will not affect users initiating withdrawal operations directly through Lido, as the protocol's 'emergency mode' (bunker mode) will activate to ensure the fair execution of the withdrawal process.
Instant and thorough transparency
From start to finish, all participants in the Lido ecosystem — whether contributors, node operators, or oracle operators — have always prioritized transparency and goodwill, ensuring the rights of stakers and the healthy development of the entire ecosystem.
Whether actively releasing detailed post-analysis reports, compensating for staking losses caused by infrastructure downtime, proactively exiting validation nodes for preventive reasons, or quickly issuing comprehensive incident reports, these participants always regard transparency as paramount.
Continuous iteration and upgrading
Lido is always at the forefront of technological development, committed to using zero-knowledge proof (ZK) technology to enhance the security and trustlessness of the oracle mechanism. Early on, the team invested over $200,000 in special funds to support trustless verification of consensus layer data through zero-knowledge proof technology.
These explorations of technology eventually led to the development of the SP1 zero-knowledge oracle 'double-check' mechanism by the SuccinctLabs team, which is set to officially launch within the year. This mechanism provides an additional layer of security verification for potential negative rebase operations through verifiable consensus layer data.
Currently, this type of zero-knowledge technology is still in the development stage. The related zero-knowledge virtual machine (zkVM) needs to undergo real-world testing and has limitations such as slow computation speed and high computational costs, making it unable to completely replace trusted oracles. However, in the long run, such solutions are expected to become a trust-minimized alternative to existing oracles.
Oracle technology is very complex and its application scenarios in the DeFi field vary. In the Lido protocol, oracles are core components that have been meticulously designed to significantly reduce the impact scope of potential risks through effective decentralized architecture, separation of responsibilities, and a multi-layer verification system.
Content source: https://x.com/IsdrsP/status/1921616790599135318
