At the forefront of Web3 security, our team has developed a robust and multi-faceted approach to safeguarding the industry’s largest projects. A prime example of this is our now long term partnership with Lido Finance, where we conducted multiple in-depth security reviews of their Oracle – a critical component for the platform’s integrity and user trust. Our methodology extends far beyond conventional audits, focusing on proactive collaboration, exhaustive analysis, and continuous learning to identify and mitigate potential vulnerabilities.
Partnering with Lido: Securing the Liquid Staking Protocol
Lido takes security very seriously, which clearly translates into user trust. Over the years, they have transparently built internal policies, methodologies, tools and established partnerships with the best specialists – this is a must, especially since the responsibility they bear continues to grow.
Protocol upgrades go through not only threat analysis and strict peer reviews, but also multiple external audits. At the beginning of 2025, we were given the opportunity to demonstrate our expertise in an audit of their core off-chain component. Not so many companies conducting smart contract audits pay attention to off-chain components. These are often overlooked and cause damage when least expected. Since then, we heard that we are one of the strongest in this area and we have already collaborated on four different projects.
Throughout our engagement, our rigorous security reviews successfully identified a total of 22 distinct findings: three high-severity vulnerabilities, eight medium-severity vulnerabilities, eleven low-severity vulnerabilities, and nine recommendations.
This impressive outcome is particularly noteworthy considering the exceptional experience and deep technical expertise of the Lido Finance team. They are a great and security-oriented team that builds extensive test suites, ensuring as few issues as possible can be found in their code.
We are pleased to report that all these findings have been thoroughly addressed by the Lido Finance team, with all highs and mediums fixed, bringing up to a total of 87% of the identified issues being fully fixed and the remaining 13% acknowledged for future implementation or accepted.
In addition, we also conducted two dedicated reviews of fixes for issues that were submitted externally. These reviews were crucial to ensure that the proposed solutions effectively mitigated the identified risks without introducing any new vulnerabilities, thereby maintaining the highest level of security for the project.
Core Principles for Web3 Security Audits
Our approach is built upon several key pillars, ensuring a thorough and insightful security assessment.
Collaborative Consultations
We believe that effective security is a continuous process and shared ideas. Our process involves numerous consultations with the project team. These discussions are not merely formal meetings but rather dynamic sessions where we collectively dissect the system’s architecture and operational flows.
These consultations aren’t confined to the audit period itself; they extend both before the official start, to thoroughly understand the project’s foundational elements and objectives, and long after its completion, to provide ongoing support and address any new concerns. This continuous engagement solidifies our role not just as auditors, but as long-term security partners dedicated to the project’s sustained integrity.
Live Scenario Analysis and Brainstorming
To truly understand potential attack vectors, we engage in live scenario analysis sessions. During these, we collaboratively explore various hypothetical attack scenarios, pushing the boundaries of conventional thinking to uncover even the most obscure vulnerabilities. We actively brainstorm diverse scenarios together, ensuring a comprehensive view of potential risks.
We don’t just present our findings; we actively share interesting scenarios and potential attack vectors with the client during the audit. This collaborative exchange serves a dual purpose: to collect their invaluable feedback and to gain even deeper insights into the project’s intricacies.
We often find that these discussions organically lead to the exchange of hand-written diagrams, which are then used to present complex scenarios for further discussion with the team. Here is an example.
Sometimes clients initially dismiss certain scenarios as impossible due to countermeasures we might not yet be aware of, these discussions often serve as a springboard for even more profound explorations, frequently unearthing additional issues, even those that lie beyond the initial scope of the audit. That was the case of another issue in the Gasbot V2 project, described in this article: Top 7 off-chain findings.
Beyond the Scope: A Deeper Dive
Our team dedicates time to analyzing and thoroughly understanding the project’s underlying mechanisms. This sometimes leads to going beyond the defined scope of an audit and means we don’t just check off boxes; we immerse ourselves in the project’s ecosystem, understanding its dependencies, integrations, and broader implications.
This deeper understanding often proves invaluable, as it allows us to uncover critical vulnerabilities that might reside within the broader business logic of the project, even if those specific areas fall outside the initial, narrowly defined audit scope. Examples of such discoveries can be found in the Auditing off-chain components article.
In the specific case of the Lido Oracle, one illustrative example of a critical calculation is the protocol’s Annual Percentage Rate (APR). The formula for this calculation consistently incorporated the Lido fees basis points. These basis points represent a portion of the rewards that are distributed and, crucially, do not contribute to an increase in the value of stETH.
Looking more broadly at the Lido protocol, it’s evident from the smart contracts that these fees are not always minted. In scenarios where fees are not minted, the APR calculation would be mistakenly inflated, leading to an inaccurate representation of returns for users.
The Power of “Stupid Questions”
No question is too trivial when it comes to security. We actively encourage and ask “stupid questions” to clarify assumptions and ensure a complete understanding of the project’s intentions and functionalities. This can sometimes make you feel like you don’t know what you’re talking about, but it’s worth it if you keep digging and uncover hidden logical flaws or misunderstandings that could lead to critical vulnerabilities.
Tip: Sometimes the client claims we’re wrong. But we don’t always trust them and delve deeper. This is normal, because we all live in our own bubbles – just like the client’s developers who assume their code works as intended. There’s nothing wrong with that.
Analysing existing findings
We actively analyze findings from other security teams and rigorously explore variations of these findings within the codebase we are auditing. This approach allows us to anticipate and prevent vulnerabilities that might have been overlooked due to isolated analysis.
Continuous Improvement through Checklist Expansion
Security is an evolving landscape. After each audit, we rigorously expand our internal checklist, incorporating new attack vectors, best practices, and lessons learned. This enhanced checklist is then applied to subsequent audits, ensuring that our methodology continually adapts to emerging threats.
Additionally, for projects aiming to integrate with the audited one, we sometimes develop a tailored integration checklist. This resource, often published as a dedicated article, serves to guide other projects through the secure and efficient integration process, sharing best practices and potential pitfalls to avoid.
Analyzing EIPs and Their Impact
Our analysis extends beyond the code itself to include a thorough examination of Ethereum Improvement Proposals (EIPs) and their potential impact on the project’s security posture. Understanding the broader architectural and protocol-level changes within the Ethereum ecosystem is crucial for identifying forward-looking vulnerabilities.
This deep understanding is not only important for the smart contracts and their future security but also for projects that rely on events external to the Execution Layer (e.g., those coming from the Consensus Layer) and base their logic on them.
A notable instance of a Consensus Layer attack vector impacting the Execution Layer within Lido Finance involved a vulnerability that could bypass the mass-slashing protection mechanism. This attack centered around the withdrawal queue’s calculation of a “safe border,” which dictated when withdrawals would be blocked.
A malicious node operator could exit their validator before a mass-slashing event began (a publicly observable action). Subsequently, once the safe border was activated, they could then slash this exited validator, effectively moving the safe border to a later epoch. This manipulation would then unlock withdrawals that were previously blocked by the safe border mechanism, undermining the protocol’s security.
Illustrative Finding from Our Audits
In the first engagement we were asked to review the current source code of the Oracle, an extensively audited and critical off-chain component for Lido protocol.
Among these were two medium-severity issues that, if exploited, could have led to a Denial of Service (DoS) for the Oracle and allowed for the bypass of critical mass-slashing protections, potentially jeopardizing the security and stability of the entire Lido protocol.
The latter one was described in the previous section, while the first issue arises when the Node Operator is forced to exit validators and has some transient ones (already deposited but not yet registered in Consensus Layer). Here is the scenario:
- The Node Operator has 1 exitable validator and 2 transient validators and no force_exit_to limit set.
- The force_exit_to limit is adjusted to 1, necessitating the exit of 2 operators while leaving one.
- The Oracle’s ejector module calculates the number of predictable validators as 3.
- The difference between the predictable validators and the limit results in 3 – 1 = 2.
- The first (and only) validator from the exitable operators is ejected.
- In the next iteration of the while loop, the difference becomes 2 – 1 = 1.
- The ejector module needs to eject another validator, but when it attempts to remove the first element from the now-empty exitable_validators list, an uncaught exception is raised, interrupting the report processing.
For detailed descriptions of these findings and more, see this article Top 7 off-chain findings and the “findings” category on our blog.
These findings highlight our ability to identify subtle yet significant vulnerabilities that could impact the integrity and reliability of the Oracle data.
Conclusion
Securing systems at this scale is a huge responsibility. It needs full focus and no distractions. In practice, that means treating off-chain components as first-class citizens in the threat model; they’re critical to overall security and must be reviewed with the same rigor as on-chain code, as our work on Lido’s Oracle made clear.
Just as important, the path to strong security runs through transparency and communication. The most effective audits are genuine collaborations: fast feedback loops, open diagrams and “what-if” sessions, and shared context that lets everyone reason about edge cases together. When the client understands why this matters and provides detailed answers, the results speak for themselves – Lido did a great job here.
Working with such an experienced team is a pleasure. We’re grateful for the trust placed in us and for the opportunity to contribute to the security of one of Ethereum’s flagship projects. We’ll keep bringing deep, end-to-end analysis. On-chain and off-chain, paired with candid communication, because that’s how you build resilient systems and long-term user trust.
Meet Composable Security
Get throughly tested by the creators of Smart Contract Security Verification Standard
