The security of Web3 projects is often synonymous with the robustness of their smart contracts, which reside on the blockchain. However, a significant portion of Web3 infrastructure operates off-chain, handling crucial data, computations, and user interactions.
These off-chain components, while less visible, are equally vital to a project’s integrity and are often overlooked in security audits. This article will explore the importance of auditing these off-chain elements, highlight scenarios where they are particularly critical, and identify key components that warrant thorough examination.
Why it matters?
While smart contracts are immutable and transparent, the off-chain components that interact with them are not and can introduce vulnerabilities if not properly secured. A breach in an off-chain system can lead to compromised user funds, data manipulation, or even a complete breakdown of the protocol.
Consider the following examples:
- Lido (or similar staking protocols): Staking protocols often involve off-chain operations for managing validator sets, distributing rewards, and – especially important – updating the protocol’s share rate.
If the off-chain infrastructure responsible for managing these processes is compromised, it could lead to incorrect reward distribution, unauthorized access to staked funds, loss of validator keys, or even the manipulation of the most important asset – the share rate. - Oracles: Oracles provide external data to smart contracts. If the off-chain processes that gather, verify, and transmit this data are not secure, a malicious actor could feed incorrect information to a smart contract, leading to devastating consequences for DeFi applications that rely on accurate pricing or event data.
- Bridges: Multi-chain bridges are frequent targets for attackers, due to the large amounts of locked value and their complex architecture. Exploits often leverage vulnerabilities in the off-chain components responsible for key management or validating transactions between chains. For instance, the Ronin Bridge hack (2022) saw attackers compromise the private keys of several nodes, enabling them to drain over $600 million in crypto assets.
- Decentralized Exchanges (DEXs) with off-chain order books: Some DEXs utilize off-chain order books for faster trading and lower gas fees before settling trades on-chain. If the security of this off-chain order book is compromised, it could lead to front-running, manipulation of trade prices, or even unauthorized trading activity.
What projects should especially focus on it?
While all Web3 projects should consider off-chain security, some types of projects have a heightened need for thorough off-chain audits:
- Staking and liquid staking protocols: As highlighted with Lido, these protocols rely heavily on secure off-chain operations for crucial parameters updates, validator management, and reward distribution.
- Oracles and data providers: The integrity of the data fed to smart contracts is paramount. Off-chain processes for data aggregation, validation, and delivery must be rigorously audited.
- Cross-chain bridges: These protocols facilitate asset transfers between different blockchains, often involving off-chain relayers and security mechanisms that are susceptible to attack if not properly secured.
- DeFi protocols: Projects involving significant financial value, such as lending platforms, decentralized exchanges, and yield aggregators, often have complex off-chain logic for risk management, liquidity provision, and user interfaces.
- Projects with complex front-ends or user interfaces: User interfaces are often the first point of interaction for users and can be vulnerable to phishing attacks or malicious code injection if not secured.
A few case studies on off-chain security
Gasbot V2 (Fast Bridge)
In our audit of Gasbot V2, a fast bridge facilitating asset transfers across multiple blockchains, we encountered a prime example of off-chain criticality. While the on-chain smart contracts were relatively straightforward, reflecting a highly centralized architecture, this centralization inherently shifted the security burden to the off-chain components.
A significant threat identified was the potential for unauthorized access to the private keys managing the bridge’s operations. A compromise of these keys, while not a present vulnerability, would grant an attacker the ability to drain funds from the associated contracts on all connected chains, highlighting the severe consequences of overlooking off-chain security in such a design.
Beyond this, during a focused penetration test of the project’s off-chain infrastructure, a critical vulnerability emerged. We attempted to submit a series of fake, non-existent transactions to the bridge’s off-chain component. Instead of rejecting these invalid transactions, the system continuously attempted to re-process them.
This led to a sustained loop of re-submissions, occurring every second for several days, which ultimately resulted in the significant depletion of the project’s operational credits due to repeated, failed transaction attempts on the underlying infrastructure.
This demonstrated a critical lack of robust input validation and error handling within the off-chain system, leading to financial impact.
Read full report here: Gasbot V2 Security Review Report
Research Portfolio
We have audited an online platform where researchers publish their work and raise support from the community. Each research page can show a “verified” badge to signal trust, and the site also displays how donations will be split among contributors.
While it uses blockchains behind the scenes, most trust signals (badges, splits, labels) are shown and controlled by the website itself – so weaknesses in the off-chain parts can mislead donors and creators.
The web app exposed a POST endpoint that flips a paper’s verification flag using attacker-supplied fields (myAddress, contractAddress, researchIdentifier, minter) – with no signature check or authenticated session binding. An attacker could open the paper’s page, copy all needed parameters from the GraphQL payload, then send a request with their own minter address.
After finding the appropriate values, it turns out that access control is most likely based on checking whether myAddress is a privileged (admin) address. The server returns a success message and the UI now marks the paper as verified – despite the attacker controlling the minter address. Donors see a “verified” asset and are primed to fund a scam.
After collecting funds assigned to the paper, the attacker mints all tokens to their address regardless of distribution, because they control the minting role. The tokens allow to claim the donated funds.
Read full report here: Research Portfolio Security Review Report
Lido Oracle
The great example of staking protocols is Lido, the biggest one. We have reviewed their most important off-chain component – the oracle.
A vulnerability was discovered in the off-chain ejector logic, which could lead to a denial of service for the entire off-chain report pipeline. The issue arose from a flaw in how the iterator processed exitable validators. Specifically, the iterator could attempt to “pop” a validator from an empty list.
Consider a scenario where a node operator has one truly exitable validator and two transient validators. If the force_exit_to threshold was set, the iterator would correctly eject the single exitable validator. However, it would then loop again, expecting another exitable validator, but the list would now be empty. This led to an IndexOutOfBounds-style error, which was uncaught, causing the ejection report to fail generation.
As a result, no data for that specific frame would be submitted on-chain, effectively creating a practical off-chain Denial of Service (DoS) attack.
Read full report here: Lido Oracle V5 Upgrade Security Review Report
Which components should be audited?
A comprehensive off-chain security audit should encompass a wide range of components. However, it is important to put the initial focus on those components that have any privileged role in the project and can influence the on-chain state. That could be:
- An EOA address that can mint tokens.
- A component that can update critical parameters (e.g. share rate).
- A component that is allowed to execute authorized operations such as withdrawing bridged tokens on the destination chain.
The next crucial components are those that store your most important assets, the private keys. The Key Management System – because you are not keeping them in plaintext, are you? – must be taken care of. Secure generation, storage, and usage of private keys, API keys, and other cryptographic secrets is a must.
Not necessarily a component but also crucial are the procedures that use those assets. A multisig is a standard now, but its configuration is as important. What if you have 3-of-3 and one person is missing (e.g. a victim of an accident)? What if you have 1-of-N and one person is attacked by thugs? Or simply what if you lose your devices? Explore all possibilities.
The last but not least important component is your front-end application. It may not be a privileged component that could directly change your on-chain state but it controls what your users are about to sign. In this case you are obliged to protect your users, not your protocol, but the protocol is rekt without users.
Excluding those above, here is a non-exclusive list of other components that should be addressed in your security roadmap:
| Component | Description |
|---|---|
| API Endpoints | Secure communication protocols, authentication, authorization, rate limiting, and input validation. |
| Databases | Secure storage, access controls, encryption, and regular backups of sensitive user data or protocol-critical information. |
| Backend Servers | Operating system security, network configuration, patch management, and intrusion detection. |
| Authentication and Authorization Systems | Robust user authentication mechanisms (e.g., multi-factor authentication), role-based access control, and secure session management. |
| Cloud Infrastructure | Secure configuration of cloud services (AWS, Azure, GCP), network security groups, and identity and access management. |
| Monitoring and Alerting Systems | Comprehensive logging, real-time threat detection, and effective alerting mechanisms for suspicious activities. |
| CI/CD Pipelines | Secure development practices, code review processes, automated testing, and secure deployment procedures. |
| Third-Party Integrations | Security assessment of any external services or APIs integrated into the project. |
| Internal Tools and Scripts | Any custom tools or scripts used for managing the protocol’s operations, even if not directly exposed to users. |
| Off-chain Workers/Bots | Security of any automated bots or workers that perform off-chain tasks, such as price feeding, transaction signing, or data aggregation. |
By meticulously auditing these off-chain components, Web3 projects can significantly enhance their overall security posture, protect user assets, and build greater trust within the decentralized ecosystem.
Meet Composable Security
Get throughly tested by the creators of Smart Contract Security Verification Standard
